Hi all, I've been trying to build GCC 4.6.x on Mac OS X to no avail (with 0 < x < 3). For easier understanding and pasting, I'd like to cross-link this thread with http://trac.macports.org/ticket/27237 . Please note, that I will give you links to the specific output snippets. When building GCC 4.6.x, bootstrapping seems to work fine. However, building libssp with the new xgcc (i.e. the one compiled with the bootstrapped xgcc), configure is failing. Note that where exactly it fails is not that important, but rather why. Please have a look at the first paste in http://trac.macports.org/ticket/27237#comment:13 . Clearly, the linker ld is crashing. The second paste reveals, that it actually crashes while running the delete operator on a basic_string and in turn using free() on the given pointer. I debugged this using gdb (replaced ld with a script calling ld.orig and sending SIGSTOP immediatly in order to be able to attach gdb), finding out, that the given pointer __p is null/0x0. As the first paste in http://trac.macports.org/ticket/27237#comment:14 suggests (extracted from new_allocator.h:98), __p should be permitted to be a null pointer.. which... well, is clearly not the case here for some reason. I then tried recreating the problem manually. In the second paste you can see the used conftest.c file and the third paste is denoting the used command line for compiling conftest. However, when running it as-is, everything works beautifully. Having a look at the ld binary, it's obvious that Apple compiled it using clang and it's dynamically linking to the system libstdc++.dylib (see paste four.) Now, due to the fact that running xgcc/ld without any modifications works fine and ld doesn't crash, maybe the build system tries to preload the recently built new libstdc++. Trying that using the command line given in the fifth paste, I was able to make ld crash at exactly the same point. My assumption is that the build system is preloading and using the newly built libstdc++ instead of the system library. Interestingly, building GCC 4.5.x and lower works fine and is not showing any of these problems. However, preloading the 4.5.3 libstdc++ leads to the same problem, as can be seen in http://trac.macports.org/ticket/27237#comment:16 . Both GCC versions are configured with --enable-fully-dynamic-strings. The Apple libc should be using the same feature. I was searching for what could change linking/preload libraries in the build system and figured out ltmain.sh does something like this. Also, there is a testsuite file which messes with that, but ssd on Freenode/#gcc pointed out that this is only used when running "make check". Diffing the ltmain.sh of GCC 4.5.3 and 4.6.2 is not helpful either: --- /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc45/gcc45/work/gcc-4.5.3/ltmain.sh 2009-12-05 18:18:53.000000000 +0100 +++ ../../../gcc-4.6.2/ltmain.sh 2011-01-13 19:51:10.000000000 +0100 @@ -5928,7 +5928,7 @@ test "$hardcode_direct_absolute" = no; then add="$dir/$linklib" elif test "$hardcode_minus_L" = yes; then - add_dir="-L$dir" + add_dir="-L$absdir" # Try looking first in the location we're being installed to. if test -n "$inst_prefix_dir"; then case $libdir in I'm kinda running out of ideas here, what could set DYLD_LIBRARY_PATH to a bogus value and cause those problems and where? Please don't suggest GNU ld or gold, as those are ELF-only and not working on MACH-O systems like Mac OS X. ;) I hope somebody can help me (and for that matter pretty much all Mac OS X users.) Best regards, Mihai
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
