gcc46: checking for -exported_symbols_list linker flag... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

[ryandesign (Ryan Carsten Schmidt)]

gcc46 @4.6-20101106 does not build for me on Mac OS X 10.6.4. It fails with:

checking for -exported_symbols_list linker flag... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libssp] Error 1
make: *** [bootstrap] Error 2

Full log attached.

gcc46 @4.6-20100925_0+java built just fine on this Mac.

[ryandesign (Ryan Carsten Schmidt)]

log

[elswong@…]

I got the same problem with the recently updated gcc46 @4.6-20101113 on Mac OS X 10.6.5. It did however work on Mac OS X 10.5.

[blair (Blair Zajac)]

Ditto here, with 4.6-20101127.

Is there a port we're supposed to have installed or a port we're not supposed to?

I presume that this compiles for mww?

[blair (Blair Zajac)]

cc myself.

[branan@…]

This is still happening with gcc46 @4.6-20110219 on Mac OS X 10.6.5, with a fresh (no previously installed ports) MacPorts.

[branan@…]

Cc Me!

[elswong@…]

Anyone able to fix this problem?

I can build gcc46@4.6-20110325+gfortran on a Macbook Pro with Snow Leopard 10.6.7 but not on an iMac with Snow Leopard 10.6.7. The only difference I could think of is a different Xcode. The Macbook has Xcode 3.2.5, but the iMac had 3.2.6. I downgraded the iMac to Xcode 3.2 but still had the same error so maybe that isn't the problem.

[elswong@…]

Cc Me!

[jmroot (Joshua Root)]

Does this still happen with 4.6.1?

[elswong@…]

I modified the Portfile to enable only C and fortran, and it works fine. However when all languages are enabled by default, the error still occurs. I'm not sure which combination of languages causes the error. I'm on OSX 10.6.8. (No errors on 10.5.8 though)

[blair (Blair Zajac)]

Yes, last time I tried the portfile a few weeks ago it failed with the same error. I keep on trying each time there's a new gcc release :)

Do you need any more info? A list of all installed ports, maybe we have different ports installed?

Regards, Blair

[Ionic (Mihai Moldovan)]

Cc Me!

[Ionic (Mihai Moldovan)]

Just tried GCC 4.6.2 with the same portfile (BUMP! ;)) - still seeing the same error on 10.6.8. Btw, I also played with different compilers and neither CLANG (the current default) nor Apple-GCC-4.2 work.

[Ionic (Mihai Moldovan)]

Btw, does anyone of you use ccache?

As far as I can see, the problem is not coming from configure but actually the xgcc is failing:

/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin10/bin/ -B/opt/local/x86_64-apple-darwin10/lib/ -isystem /opt/local/x86_64-apple-darwin10/include -isystem /opt/local/x86_64-apple-darwin10/sys-include    -g -pipe -O2  -o libconftest.dylib -dynamiclib -Wl,-single_module conftest.c
collect2: ld terminated with signal 6 [Abort trap], core dumped
ld(55464) malloc: *** error for object 0x100282880: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
configure:7034: result: no
configure:7036: checking for -exported_symbols_list linker flag
configure:7046: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

I guess there is a way bigger underlaying problem. It may or may not stem from ccache. I'll rebuild without ccache for great justice.

I'll also have a look with gdb, this problem.

[0 running job(s)] {history#7052}  22:48:10 11-10-29
root@nopileos...rk/build/x86_64-apple-darwin10/libssp# gdb ld /cores/core.54693
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done

Reading symbols for shared libraries . done
Reading symbols for shared libraries ..... done
#0  0x00007fff824e40b6 in __kill ()
(gdb) bt full
#0  0x00007fff824e40b6 in __kill ()
No symbol table info available.
#1  0x00007fff825849f6 in abort ()
No symbol table info available.
#2  0x00007fff8249c195 in free ()
No symbol table info available.
#3  0x000000010021c2f9 in std::string::assign (this=0x101777fa8, __str=<value temporarily unavailable, due to optimizations>) at new_allocator.h:98
	__p = Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) where
#0  0x00007fff824e40b6 in __kill ()
#1  0x00007fff825849f6 in abort ()
#2  0x00007fff8249c195 in free ()
#3  0x000000010021c2f9 in std::string::assign (this=0x101777fa8, __str=<value temporarily unavailable, due to optimizations>) at new_allocator.h:98
(gdb)

Seems like to be linked to the fully dynamic string option... I'll pass -D_GLIBCXX_FULLY_DYNAMIC_STRING to CFLAGS too.

[Ionic (Mihai Moldovan)]

Nope, won't work, as _GLIBCXX_FULLY_DYNAMIC_STRING is set by --enable-fully-dynamic-string already.

Ok, some more information here.

For once, I found out through debugging that __p is null/0x0, although this shouldn't ever happen (at least the code says so in new_allocator.h:98:

      // __p is not permitted to be a null pointer.
      void
      deallocate(pointer __p, size_type)
      { ::operator delete(__p); }

Then, I tried to manually reproduce the problem with conftest3.c:

int foo(void){return 1;}

and this command line:

/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin10/bin/ -B/opt/local/x86_64-apple-darwin10/lib/ -isystem /opt/local/x86_64-apple-darwin10/include -isystem /opt/local/x86_64-apple-darwin10/sys-include    -g -pipe -O2  -o libconftest.dylib -dynamiclib -Wl,-single_module conftest3.c

This, however, worked fine and didn't crash. Having a look at otool -L /usr/bin/ld (which is crashing...) shows that...

/usr/bin/ld.orig:
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
	@executable_path/../lib/libLTO.dylib (compatibility version 1.0.0, current version 3135.0.0)

The ld binary actually dynamically links to the libstdc++. Now, as we build GCC 4.6 and for that matter also a newer libstdc++, the build system probably tried to use that new lib instead of the system library. We can "emulate" this by using the following command line (when PWD == /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/x86_64-apple-darwin10/libssp):

DYLD_LIBRARY_PATH="../libstdc++-v3/src/.libs/" /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin10/bin/ -B/opt/local/x86_64-apple-darwin10/lib/ -isystem /opt/local/x86_64-apple-darwin10/include -isystem /opt/local/x86_64-apple-darwin10/sys-include    -g -pipe -O2  -o libconftest.dylib -dynamiclib -Wl,-single_module conftest3.c

Gotcha, there we got the crash again. So it's definitely connected to the newly build libstdc++.

Now, I replaced /usr/bin/ld with a script that calls /usr/bin/ld.orig (the original binary) and sends a SIGSTOP immediatly, which also enabled me to attach gdb to the process. Have a look at this:

(gdb) break malloc_error_break
Breakpoint 2 at 0x3126e978c69499
(gdb) cont
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x00007fff5fc04f5f in __dyld__ZN4dyldL10loadPhase5EPKcRKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE ()
(gdb) cont
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x00007fff5fc219d6 in __dyld_stat64 ()
(gdb) cont
Continuing.
Reading symbols for shared libraries .+. done
Breakpoint 3 at 0x100219c34: file new_allocator.h, line 98.
Breakpoint 4 at 0x100219c64: file new_allocator.h, line 98.
Breakpoint 5 at 0x10021b084: file new_allocator.h, line 98.
Breakpoint 6 at 0x10021bab0: file new_allocator.h, line 98.
Breakpoint 7 at 0x10021bac0: file new_allocator.h, line 98.
Breakpoint 8 at 0x10021bc24: file new_allocator.h, line 98.
Breakpoint 9 at 0x10021c2f4: file new_allocator.h, line 98.
Breakpoint 10 at 0x10021cc3a: file new_allocator.h, line 98.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
Pending breakpoint 1 - "new_allocator.h:98" resolved

Program received signal SIGSTOP, Stopped (signal).
0x00007fff5fc0a2de in __dyld__ZL18gdb_image_notifier15dyld_image_modejPK15dyld_image_info ()
(gdb) cont
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x00007fff5fc1502f in __dyld__ZN26ImageLoaderMachOCompressed6rebaseERKN11ImageLoader11LinkContextE ()
(gdb) cont
Continuing.
Reading symbols for shared libraries . done

Breakpoint 9, std::string::assign (this=0x101777fa8, __str=<value temporarily unavailable, due to optimizations>) at new_allocator.h:98
98	      { ::operator delete(__p); }
(gdb) print __p
Cannot access memory at address 0x0

Something is really, really broken and upstream should fix that.

However, I'll rebuild gcc45 and try to use that libstdc++ as that's the last known good version to me. We'll see.

[Ionic (Mihai Moldovan)]

Oh yeah, and have fun looking at the ​diff from libstdc++3 4.5.3 to libstdc++3 4.6.2, it's about 3.5MB big.... :/

[Ionic (Mihai Moldovan)]

1 [0 running job(s)] {history#7417}  17:25:24 11-10-30
root@nopileos...rk/build/x86_64-apple-darwin10/libssp# DYLD_LIBRARY_PATH="/opt/local/lib/gcc45/" /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.rsync.ionic.de_release_ports_lang_gcc46/gcc46/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin10/bin/ -B/opt/local/x86_64-apple-darwin10/lib/ -isystem /opt/local/x86_64-apple-darwin10/include -isystem /opt/local/x86_64-apple-darwin10/sys-include    -g -pipe -O2  -o libconftest.dylib -dynamiclib -Wl,-single_module conftest3.c
collect2: ld terminated with signal 6 [Abort trap], core dumped
ld(39160) malloc: *** error for object 0x100285640: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Any questions? So, even when preloading the GCC 4.5.3 libstdc++, ld crashes. :( On the other hand, it seems like the gcc45 build system is *not* preloading the recently build lib, whilst gcc46 is. So the problems we see may stem from that... analyzing. :/

[wouter+macports@…]

This problem is caused by the newly-built libstdc++ having a different value for the _GLIBCXX_FULLY_DYNAMIC_STRING macro than the system libstdc++ (against which ld and friends are built), and during stage2 and further compilation the environment being set to prefer the newly-built libstdc++ as opposed to the system libstdc++, even for ld.

This causes the problem explained here:

​http://newartisans.com/2009/10/a-c-gotcha-on-snow-leopard/#comment-893

To add to the confusion, the conclusion made in the linked explanation above is wrong: on Snow Leopard, _GLIBCXX_FULLY_DYNAMIC_STRING is not defined:

$ grep FULLY_DYNAMIC_STRING /usr/include/c++/4.2.1/i686-apple-darwin10/bits/c++config.h 
/* #undef _GLIBCXX_FULLY_DYNAMIC_STRING */

Therefore, this problem is fixed by:

--- Portfile.orig	2011-11-19 22:09:53.000000000 +0100
+++ Portfile	2011-11-19 22:17:45.000000000 +0100
@@ -119,7 +119,6 @@
 	configure.args-append --with-dwarf2
 }
 platform darwin 10 {
-	configure.args-append --enable-fully-dynamic-string
 }
 
 platform darwin 11 {

With this change, gcc46 builds and installs successfully for me. I have no idea what should be done for Lion, as I have no access to such a system.

Hope that helps.

[wouter+macports@…]

Cc Me!

[drkp (Dan Ports)]

Sounds like #31171 is describing another manifestation of the same problem (on Lion)

[Ionic (Mihai Moldovan)]

Oh, sorry wouter, I totally forgot to report back here.

I've used the GCC mailinglist to shed some light on this bug.

X referencing ​http://gcc.gnu.org/ml/gcc-help/2011-10/msg00250.html now.

tl;dr: see below.

Yes, I can confirm that disabling the fully dynamic string setting seems to fix the problem (on SL.) Also, I can confirm that I have *no idea whatsoever* why

• it fucking works for GCC < 4.6
• it crashes badly for GCC >= 4.6

You probably are right that the base OS X system (including ld and such) have been built *without* this feature. We may have just gotten lucky with GCC 4.5 working, even though this feature was enabled.

Also, none of this answers how "JOHNW" or the people he's working with could fix their problem by enabling the fully dynamic string option. My best guess is that actually the boost building procedure is "broken" and produces libraries with this setting turned on by default, thus causing those kind of problems.

tl;dr: confirming that disabling the fully dynamic string option makes GCC build just fine on SL.

[drkp (Dan Ports)]

There's also some discussion of this in #31171 which might be worth looking at.

Replying to ionic@…:

You probably are right that the base OS X system (including ld and such) have been built *without* this feature. We may have just gotten lucky with GCC 4.5 working, even though this feature was enabled.

Yes, I agree, that does seem to be the case. I don't see any evidence that the system libstdc++ is built with fully dynamic strings. It doesn't appear that way on my Lion system, and it sounds like it isn't on SL either.

Also, none of this answers how "JOHNW" or the people he's working with could fix their problem by enabling the fully dynamic string option. My best guess is that actually the boost building procedure is "broken" and produces libraries with this setting turned on by default, thus causing those kind of problems.

I suspect the original problem was something else -- possibly related to _GLIBCXX_DEBUG.

Unless anyone can come up with a reason not to, and assuming a couple more tests pass, I'll remove the --enable-fully-dynamic-string option.

[Ionic (Mihai Moldovan)]

Oh don't get me started. Both _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC are broken on OS X and must always be disabled.

I had to learn the hard way through weird bugs and random crashes. Added "-U_GLIBCXX_DEBUG -U_GLIBCXX_DEBUG_PEDANTIC" as CXXFLAGS to my project and haven't had a problem like this since.

Yeah, a likely cause of trouble... I totally forgot about those two macros, sorry.

[jwiegley@…]

As the aforementioned "JOHNW", I'll add that the real problem for me seems indeed to have been the use of _GLIBCXX_DEBUG. Boost.Regex became unusable with gcc-4.6 and above on Snow Leopard and Lion, no matter what I tried with regard to fully dynamic string. So I'm all for removing that from the Portfile now. I'll update my blog entry to refer to this thread.

[drkp (Dan Ports)]

This should be fixed by r87835.

[cooljeanius (Eric Gallager)]

Cc Me!

[barracuda156]

Replying to Ionic:

ld(55464) malloc: *** error for object 0x100282880: pointer being freed was not allocated

This looks like related to: ​https://github.com/iains/darwin-toolchains-start-here/discussions/20