Don't build gcc ports with --enable-fully-dynamic-string

[okpail@…]

--->  Computing dependencies for gcc46
--->  Building gcc46
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for gcc46 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc46/gcc46/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

[okpail@…]

Cc Me!

[skymoo (Adam Mercer)]

Don't forget WikiFormatting and to CC the maintainer

[skymoo (Adam Mercer)]

Cc Me!

[bradskins@…]

Cc Me!

[m214089]

Cc Me!

[mjhsieh@…]

Cc Me!

[gregorbrandt@…]

Cc Me!

[josh@…]

Cc Me!

[qpjevi@…]

Cc Me!

[fyu+macports@…]

Cc Me!

[david@…]

Cc Me!

[cdecoro@…]

Why hasn't more priority been placed on this? gcc is unarguably the most important port; if it doesn't work, then MacPorts is useless for a lot of people.

In any case, I've found a cumbersome manual workaround. The problem occurs when the makefile attempts to link libgcc_s. For some reason, ld has a problem with memory management. However, inexplicably, this only happens when attempting to build libgcc_s through the port system (probably because of some environment settings, but that's just a guess). If you go to the following directory (you should probably be root, btw):

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc46/gcc46/work/build/x86_64-apple-darwin11/libgcc

and run make, libgcc_s will build just fine (you will see some warnings from malloc, but no errors).

Ideally, you would then be able to run make from the top level directory:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc46/gcc46/work/build/

However, for some reason, the Makefile will attempt to rebuild libgcc_s no matter what. So you will need to comment out the line in Makefile that does that. Search for:

all-stage3-target-libgcc: configure-stage3-target-libgcc

which will be approximately on line 14830. The line to comment is a bit below that, and starts with:

cd $(TARGET_SUBDIR)/libgcc && \
	$(MAKE) $(BASE_FLAGS_TO_PASS) \

I may have also commented some things out under the target configure-stage3-target-libgcc, unfortunately I can't remember at this point, sorry.

Then run make again in the top-level directory. If you have the gfortran variant enabled, you will get a similar error when ld attempts to link libgfortran. You will need to go into the directory:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc46/gcc46/work/build/x86_64-apple-darwin11/libgfortran

and run make. Again, it will give warnings, but no errors. For whatever reason, you do not need to comment out the top-level makefile to have it avoid remaking this directory.

Now, run make from the top-level directory again, and it should finally build. Then run make install, and you should be all set. gcc46 appears to be working fine for me. Your mileage may vary, of course.

[larryv (Lawrence Velázquez)]

Cc Me!

[sygnet@…]

Cc Me!

[E.Kirk@…]

Cc Me!

[AlonzoQuixote@…]

Cc Me!

[lars.schreiner@…]

Hi!

I tried to make the libfortran, but I ran into link problems:

/usr/bin/ranlib: file: .libs/libgfortran.a(bessel_r10.o) has no symbols
libtool: link: /usr/bin/ranlib .libs/libgfortran.a
/usr/bin/ranlib: file: .libs/libgfortran.a(bessel_r10.o) has no symbols
libtool: link: ( cd ".libs" && rm -f "libgfortran.la" && ln -s "../libgfortran.la" "libgfortran.la" )
true  DO=all multi-do # make

Does anyone knows what I have to do, to get this linked?

Thanks.

Lars

[david.brockley@…]

Cc Me!

[arsenm2@…]

Cc Me!

[vincent.liegeois@…]

Cc Me!

[maehne (Torsten Maehne)]

Cc Me!

[maehne (Torsten Maehne)]

I can confirm the build error for the gcc46 port. After a port selfupdate, I tried to install the gcc46 port. The build stopped during the linking process of libgfortran. I see a lot of malloc errors reported by ld:

collect2: ld terminated with signal 6 [Abort trap: 6]
ld(30785) malloc: *** error for object 0x105c95880: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
make[3]: *** [libgfortran.la] Error 1

I attach the complete zipped build log. I hope this helps to find the origin of the build error to make gcc46 work on Lion soon.

[maehne (Torsten Maehne)]

gcc46 build log showing linker and malloc errors

[bosch@…]

Cc Me!

[Serge3leo (Serguei E. Leontiev)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #31976.

[alexander.bolodurin+macports@…]

Cc Me!

[vakeera@…]

Cc Me!

[vakeera@…]

I really think this ought to be elevated in priority. I am on Mac OSX 10.7.2, Xcode 4.1, MacPorts 2.0.3, and it fails to build, with the memory management problem shown above. I tried installing gcc46 (4.6.2) using Apple's LLVM GCC 4.2, Standard GCC 4.2, and Clang. All three gave the same result. It would be nice if I could at least figure out how to install GCC 4.6.1 in the mean time. I could not find any old port files on ​http://svn.macports.org/repository/macports/trunk/dports/lang/gcc46/

[vakeera@…]

gcc46 @4.6.2 error log

[bradskins@…]

I followed the directions on this post:

​http://solarianprogrammer.com/2011/09/20/compiling-gcc-4-6-1-on-mac-osx-lion/

With a couple changes:

1. I used gcc 4.6.2 instead of 4.6.1
2. The dependencies were installed using macports
3. All occurrences of $HOME/my_gcc were replaced with /opt/local
4. My --program-prefix='' and my --program-suffix=-mp-4.6

After 'make install' Macports can use gcc 4.6.2. Some advanced things that don't work quite right are:

1. Auto parallelization with Graphite
2. Basic auto parallelization with cloog
3. Using march=corei7-avx

Happy hacking!

-brad

[richard@…]

Cc Me!

[Kona8lend@…]

see patch attachment:gcc46-ld.diff​

...fixes port to build on Mac OS X 10.7.2 w/ Xcode 4.2. It seems that DYLD_LIBRARY_PATH is set during build-time and eventually being picked up by /usr/bin/ld, causing it to load gcc46's libstdc++.6.dylib and crash.

[Kona8lend@…]

Cc Me!

[drkp (Dan Ports)]

Cc Me!

[drkp (Dan Ports)]

It seems like the problem here may be caused by to the platform block that adds --enable-fully-dynamic-string to configure.args. gcc46 builds fine for me once I remove it.

--enable-fully-dynamic-string was added in r67282 in response to #22234 (and subsequently to other gcc versions). The thinking there was that Apple's libstdc++ was compiled with _GLIBCXX_FULLY_DYNAMIC_STRING, so would create incompatibilities if trying to link against that and something compiled without it.

I think that reasoning might have been mistaken. At least, it seems to be for Lion, where I don't see any evidence of libstdc++ being compiled with fully dynamic strings. The test file in #22234 works fine for me when using gcc46 built without --enable-fully-dynamic-string. See also Matt Seegmiller's comment in response to ​http://newartisans.com/2009/10/a-c-gotcha-on-snow-leopard/ which suggests that it isn't used on Snow Leopard either.

Maybe the original issue was actually related to the use of _GLIBCXX_DEBUG, which boost used to be compiled with (#22112) and which was a source of known issues with Xcode 3.2?

In any case, it seems like we should remove the platform darwin 11 block that sets --enable-fully-dynamic-string, and probably the platform darwin 10 one too.

[daitakahashi]

Cc Me!

[daitakahashi]

Unfortunately a patch posted by Kona8lend does not work here, but removal of --enable-fully-dynamic-string suggested by dports works fine. Thank you very much.

OSX 10.6.8 with Xcode 3.2.6 (x86_64 and i386 universal), Macbook pro early 2011

[Kona8lend@…]

Replying to dtakahashi42@…:

Unfortunately a patch posted by Kona8lend does not work here, but removal of --enable-fully-dynamic-string suggested by dports works fine. Thank you very much.

OSX 10.6.8 with Xcode 3.2.6 (x86_64 and i386 universal), Macbook pro early 2011

Good to know -- never tested my patch on Snow Leopard.

[Kona8lend@…]

as per dports comments about --enable-fully-dynamic-string see new patch attachment:gcc46-darwin11-no-fds.diff​

This approach seems to make gcc46's new libstdc++ ABI compatible once again with /usr/lib/libstdc++.6.dylib, thus negating any need to delve into gcc46 sources and block dangerous points of DYLD_LIBRARY_PATH propagation (as my first patch gcc46-ld does). It's cleaner and more future proof.

It appears the initial reasoning for --enable-fully-dynamic-string in r67282 (gcc44), r68780 (gcc45), r68778 (gcc46) was incorrect. Examining libstdcxx from ​http://opensource.apple.com for both Snow Leopard and Lion do not show this option enabled. Nor do the headers. Headers bundled with Xcode 4.2 in both 10.6 and 10.7 SDKs are also consistent: the feature is not enabled.

A deeper search as to why #22234 requested the option implicates use of _GLIBCXX_DEBUG, and that's a whole other can of worms. Sufficed to say, _GLIBCXX_DEBUG has some history of being wonky with bundled libstdc++ on OSX and it's possible this became a red herring. I am able to build #22234 souce with llvm-g++-4.2, g++-apple-4.2, g++-mp-4.5, g++-mp-4.6 with -O0, -O1, -O2, -O3, -Os on Lion Xcode 4.2 and it is not fatal. Additionally another regex test program posted by the same author, similar issue, and it is works fine.

So I'd like to conclude that unless we have concrete evidence that Apple's libstdc++ was built with --enable-fully-dynamic-string, I think we should not build any gcc/libstdc++ with that option by default.

Standard disclaimer: my testing is on Lion.

[drkp (Dan Ports)]

See also #27237, which appears to be the same problem.

[drkp (Dan Ports)]

Also has duplicate #32142

[ryandesign (Ryan Carsten Schmidt)]

Replying to vakeera@…:

It would be nice if I could at least figure out how to install GCC 4.6.1 in the mean time. I could not find any old port files on ​http://svn.macports.org/repository/macports/trunk/dports/lang/gcc46/

Read wiki:howto/InstallingOlderPort.

Also, I must remind everyone in this ticket to please use WikiFormatting and TracLinks, and to preview before submitting to ensure you've got it right. I don't want to keep having to correct everybody's formatting.

[drkp (Dan Ports)]

Hmm. If we remove --enable-fully-dynamic-string from gcc44, gcc45, and gcc46 -- as I'm inclined to do -- is this going to cause problems for any binaries built with previous revisions of the port, because they'll be expecting fully dynamic strings and libstdc++ is no longer built with such support?

[fleason (Fred Leason)]

Cc Me!

[drkp (Dan Ports)]

Hmm. If we remove --enable-fully-dynamic-string from gcc44, gcc45, and gcc46 -- as I'm inclined to do -- is this going to cause problems for any binaries built with previous revisions of the port, because they'll be expecting fully dynamic strings and libstdc++ is no longer built with such support?

The answer to this question appears to be yes, unfortunately. Some ports I built using the current version of the gcc44 ports promptly stopped working once I rebuilt gcc44 without --enable-fully-dynamic-string.

So that's a pretty serious problem. I was ready to remove that from the configure args of gcc44, gcc45, and gcc46. But doing that will break compatibility with any C++ binaries compiled before the change and that would be really unfortunate. We could go and revbump any port that builds with those compilers -- but that doesn't help any user who built their own programs using these compilers. As far as I can tell, they would just stop working if they use the empty string.

[daitakahashi]

Could you explain why --enable-fully-dynamic-string should be removed from gcc44 and gcc45? I think those compilers work fine even though those were compiled with --enable-fully-dynamic-string.

[drkp (Dan Ports)]

Replying to dtakahashi42@…:

Could you explain why --enable-fully-dynamic-string should be removed from gcc44 and gcc45? I think those compilers work fine even though those were compiled with --enable-fully-dynamic-string.

Well, the reason we enabled it in the first place was that we thought the system's standard library was built with that flag set, and we needed the generated code to be compatible. It seems like that was mistaken. Either way, it doesn't depend on gcc versions -- either the system library was built with fully dynamic strings and all of the gcc ports should do the same, or it wasn't and none of them should.

It is true that this only seems to be causing serious problems with gcc46. I don't know why that is. (It's also possible that it is causing problems with gcc44/45 that are just more subtle than failing to build entirely.)

[fleason (Fred Leason)]

The discussion thread in #31174 indicates this is a problem with the Apple loader. It is only a problem with gFORTRAN on i7 architectures.

[vakeera@…]

Cc Me!

[jacobu@…]

Cc Me!

[akimd (Akim Demaille)]

Cc Me!

[bonoba@…]

Cc Me!

[vallentin@…]

Cc Me!

[adfernandes (Andrew Fernandes)]

Cc Me!

[jon@…]

Is there a short-term workaround one could implement locally to get gcc 4.6.2 building?

[vallentin@…]

Replying to jon@…:

Is there a short-term workaround one could implement locally to get gcc 4.6.2 building?

Removing --enable-fully-dynamic-string from the Portfile did the trick for me, see Kona8lend's patch. If you don't want to modify the base Portfile, you can put a copy in an overlay ports tree. By the way, removing that flag also fixes a similar double-free segfault I encounter with the Boost libraries (specifically, the program options library).

[jon@…]

Replying to vallentin@…:

Replying to jon@…:

Is there a short-term workaround one could implement locally to get gcc 4.6.2 building?

Removing --enable-fully-dynamic-string from the Portfile did the trick for me, see Kona8lend's patch. If you don't want to modify the base Portfile, you can put a copy in an overlay ports tree. By the way, removing that flag also fixes a similar double-free segfault I encounter with the Boost libraries (specifically, the program options library).

Thanks. I couldn't see where the patch needed to be applied. I used

cd $(port dir gcc46)

to find the Portfile and have applied the edit suggested above.

[macports@…]

Cc Me!

[Kona8lend@…]

Changeset r87656 fixes the problem for me on Lion.

[fleason (Fred Leason)]

gcc46 @4.6.2_0 Installed on Lion
Processor 2.8 GHz Intel Core i7
Memory 16 GB 1067 MHz DDR3
Graphics ATI Radeon HD 4850 512 MB
Software Mac OS X Lion 10.7.2 (11C74)
Xcode Version 4.2.1 Build 4D502

Status should change to Works for Me

[drkp (Dan Ports)]

Yes, this was fixed by r87656 (for Lion, at least).

[daitakahashi]

Thank you for fixing it. However, also a compilation of GCC 4.6 on Snow leopard has the same issue. The configure option --enable-fully-dynamic-string should also be removed from platform darwin 10 (removal of that option fixed the problem for me on Snow leopard).

[adfernandes (Andrew Fernandes)]

Replying to dtakahashi42@…:

Thank you for fixing it. However, also a compilation of GCC 4.6 on Snow leopard has the same issue. The configure option --enable-fully-dynamic-string should also be removed from platform darwin 10 (removal of that option fixed the problem for me on Snow leopard).

I have built and have been using gcc 4.6 on snow leopard for the past couple of weeks after manually removing --enable-fully-dynamic-string.

[adfernandes (Andrew Fernandes)]

I've now built and tested much code with gcc-4.6.2 on 10.6 and removing the --enable-fully-dynamic-string has not ill effects with system code.

Given the openmaintainer status and the diff committed by mww, I'm committing in r87835

[jwiegley@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

This needs to be applied to gcc44 and gcc45 as well.

[jeremyhu (Jeremy Huddleston Sequoia)]

r97745

[cooljeanius (Eric Gallager)]

Cc Me!