clang-3.4 build failure with gcc-4.2 on OS X 10.6.8

[RJVB (René Bertin)]

For some reason, clang-3.4 fails to build on my 10.6.8 macbookpro8,1 . This is not the same kind of failure as reported elsewhere (#42108), which indeed affects me too when I build with gcc-mp-4.8 . Instead, it suggests a code incompatibility.

[RJVB (René Bertin)]

log from port -s destroot clang-3.4

[jeremyhu (Jeremy Huddleston Sequoia)]

:info:build PrettyStackTrace.cpp:64: error: expected constructor, destructor, or type conversion before ‘struct’
:info:build PrettyStackTrace.cpp: In function ‘void CrashHandler(void*)’:
:info:build PrettyStackTrace.cpp:92: error: expected primary-expression before ‘void’
:info:build PrettyStackTrace.cpp:92: error: expected `)' before ‘void’
:info:build make[1]: *** [/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/lib/Support/Release+Debug+Asserts/PrettyStackTrace.o] Error 1

[jeremyhu (Jeremy Huddleston Sequoia)]

That's here:

#if defined (__APPLE__) && HAVE_CRASHREPORTERCLIENT_H
//  If any clients of llvm try to link to libCrashReporterClient.a themselves,
//  only one crash info struct will be used.
extern "C" {
CRASH_REPORTER_CLIENT_HIDDEN 
struct crashreporter_annotations_t gCRAnnotations  <---------  64
        __attribute__((section("__DATA," CRASHREPORTER_ANNOTATIONS_SECTION))) 
        = { CRASHREPORTER_ANNOTATIONS_VERSION, 0, 0, 0, 0, 0, 0 };
}
#elif defined (__APPLE__) && HAVE_CRASHREPORTER_INFO
static const char *__crashreporter_info__ = 0;
asm(".desc ___crashreporter_info__, 0x10");
#endif
...
#ifdef HAVE_CRASHREPORTERCLIENT_H
    // Cast to void to avoid warning.
    (void)CRSetCrashLogMessage(std::string(TmpStr.str()).c_str());   <-------- 92
#elif HAVE_CRASHREPORTER_INFO 
    __crashreporter_info__ = strdup(std::string(TmpStr.str()).c_str());
#endif

Why do you have HAVE_CRASHREPORTERCLIENT_H defined?

[jeremyhu (Jeremy Huddleston Sequoia)]

:info:configure checking CrashReporterClient.h usability... yes
:info:configure checking CrashReporterClient.h presence... yes
:info:configure checking for CrashReporterClient.h... yes
:info:configure checking __crashreporter_info__... no

Do you have CrashReporterClient.h somewhere on your system? What is in it?

[cooljeanius (Eric Gallager)]

Cc Me!

[RJVB (René Bertin)]

In fact indeed I do, and it's even in /usr/local/include despite the warning inside the file. It's possible I put it there when trying to build ... something.

Not the first time I've been bitten by something I installed in /usr/local. Is it possible to instruct MacPorts not to search there?

I removed the offending header, and rebuilt using only a single job ... still no luck.

[RJVB (René Bertin)]

port -s destroot clang-3.4 after removing the offending header file from /usr/local/include

[jeremyhu (Jeremy Huddleston Sequoia)]

clean and rebuild.

[RJVB (René Bertin)]

ok (but that 2nd log was obtained just like that!)

[jeremyhu (Jeremy Huddleston Sequoia)]

:info:configure checking CrashReporterClient.h usability... no
:info:configure checking CrashReporterClient.h presence... no
:info:configure checking for CrashReporterClient.h... no

And this issue was resolved. You're now seeing #42108.

Just keep retrying the build. I don't know what's going wrong, but it works upon retry (don't clean in between).

[RJVB (René Bertin)]

Ah... Any chances these entries in the kernel.log hint at the reason? They're clearly related:

Jan 14 17:33:07 portia kernel[0]: (default pager): [KERNEL]: Switching ON Emergency paging segment
Jan 14 17:33:10 portia kernel[0]: (default pager): [KERNEL]: System is out of paging space.
Jan 14 17:34:19 portia kernel[0]: (default pager): [KERNEL]: Recovered emergency paging segment

[ryandesign (Ryan Carsten Schmidt)]

Replying to rjvbertin@…:

Not the first time I've been bitten by something I installed in /usr/local. Is it possible to instruct MacPorts not to search there?

It's not MacPorts that's searching there; it's the compiler, and no, we don't know how to instruct it not to do that. That's why we don't support installing anything in /usr/local. wiki:FAQ#usrlocal

[RJVB (René Bertin)]

Update: I've never managed to get clang-3.4 to build with apple's gcc-4.2, not even after relaunching the build command multiple times in a row. As I had a working version, I let it slip, but I have to come back to that.

The latest llvm-3.4_1 update caused clang-3.4 to crash during compilation. As llvm-3.4 had been upgraded with upgrade outdated, I figured I'd reinstall it, ensuring that I'd be building with gcc-4.7 .

That worked, but now clang-3.4 will not rebuild, not even with macports-gcc-4.8 as it did before. The failure is the same as I observed with gcc-4.2. Moving into the build directory and invoking make by hand, I see

# make V=1
[...]

make[4]: Nothing to be done for `all'.
make[5]: Nothing to be done for `clang_darwin'.
 ARCHIVE:   clang_darwin_embedded/hard_static/armv7: /Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/hard_static/armv7/libcompiler_rt.a
make[5]: *** [/Volumes/Debian/MacPorts/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_lang_llvm-3.4/clang-3.4/work/llvm-3.4/tools/clang/runtime/compiler-rt/clang_darwin_embedded/hard_static/armv7/libcompiler_rt.a] Error 1
make[4]: *** [BuildRuntimeLibraries] Error 2
make[3]: *** [compiler-rt/.makeall] Error 2
make[2]: *** [all] Error 1
make[1]: *** [clang/.makeall] Error 2
make: *** [all] Error 1
Exit 2

Why is clang trying to build for armv7 - I never asked for that! Is there a way to deactivate support for that (and other cross-compiling) as I won't ever be using such features?

Let me know if I should open a new ticket for this.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to rjvbertin@…:

Update: I've never managed to get clang-3.4 to build with apple's gcc-4.2, not even after relaunching the build command multiple times in a row.

How many times did you try? I think I got it after 5-6.

As I had a working version, I let it slip, but I have to come back to that.

The latest llvm-3.4_1 update caused clang-3.4 to crash during compilation. As llvm-3.4 had been upgraded with upgrade outdated, I figured I'd reinstall it, ensuring that I'd be building with gcc-4.7 .

How did it crash? Do you have crash reporter logs?

That worked, but now clang-3.4 will not rebuild, not even with macports-gcc-4.8 as it did before.

This issue looks like a dependencies issue in the Makefiles for compiler_rt and does not seem at all related to what compiler is chosen.

The failure is the same as I observed with gcc-4.2. Moving into the build directory and invoking make by hand, I see

Yes, that is what I'd expect (ie, that's this bug).

Why is clang trying to build for armv7 - I never asked for that! Is there a way to deactivate support for that (and other cross-compiling) as I won't ever be using such features?

Do you have the +arm_runtime variant selected?

Let me know if I should open a new ticket for this.

No, this is the right ticket.

[RJVB (René Bertin)]

I probably tried 5-6 times or more, and the process always got stuck on the step shown above, i.e. linking or building an armv7 .

How did it crash? Do you have crash reporter logs?

Erm, hard? I didn't save any crash logs as I first wanted to be sure the upgraded llvm-3.4 was built with the compiler I'd tested the 3.4_0 version with.

No, I don't have the arm_runtime variant selected, not explicitly in any case. clang3.4 doesn't have any dependents on my system, so I presume that +arm_runtime variant cannot have been selected because of dependencies...

[ryandesign (Ryan Carsten Schmidt)]

Replying to rjvbertin@…:

No, I don't have the arm_runtime variant selected, not explicitly in any case. clang3.4 doesn't have any dependents on my system, so I presume that +arm_runtime variant cannot have been selected because of dependencies...

MacPorts doesn't have the capability to automatically select a variant of a dependency anyway.

[RJVB (René Bertin)]

I could have installed a +arm_runtime variant of a port using clang-3.4, in which case I presume clang would have been reinstalled with that variant. Thats what happened when I installed the universal variant of ffmpeg (= a good deal of my ports got reinstalled -rebuilt- in their universal variants).

So, if I don't have the armv7 variant selected manually, why is clang-3.4 trying to build arvm7 components?

[ryandesign (Ryan Carsten Schmidt)]

Replying to rjvbertin@…:

I could have installed a +arm_runtime variant of a port using clang-3.4, in which case I presume clang would have been reinstalled with that variant. Thats what happened when I installed the universal variant of ffmpeg (= a good deal of my ports got reinstalled -rebuilt- in their universal variants).

That is correct, in that case your variant selections would be propagated to any uninstalled dependencies. However the only ports that have a variant named arm_runtime are the clang ports:

$ port echo variants:arm_runtime
clang-2.9                       
clang-3.0                       
clang-3.1                       
clang-3.2                       
clang-3.3                       
clang-3.4                       
clang-3.5                       
eero-devel