Opened 13 years ago

Closed 12 years ago

Last modified 10 years ago

#31171 closed defect (fixed)

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

Reported by: okpail@… Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: skymoo (Adam Mercer), bradskins@…, m214089, mjhsieh@…, gregorbrandt@…, josh@…, qpjevi@…, fyu+macports@…, david@…, larryv (Lawrence Velázquez), sygnet@…, AlonzoQuixote@…, david.brockley@…, arsenm2@…, vincent.liegeois@…, maehne (Torsten Maehne), bosch@…, Serge3leo (Serguei E. Leontiev), scottp@…, alexander.bolodurin+macports@…, richard@…, Kona8lend@…, drkp (Dan Ports), daitakahashi, lukas.reichlin@…, fleason (Fred Leason), jacobu@…, akimd (Akim Demaille), bonoba@…, vallentin@…, adfernandes (Andrew Fernandes), macports@…, jwiegley@…, cooljeanius (Eric Gallager)
Port: gcc46

Description (last modified by skymoo (Adam Mercer))

--->  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>

Attachments (5)

main.log (64.7 KB) - added by okpail@… 13 years ago.
gcc46_build.log.bz2 (222.7 KB) - added by maehne (Torsten Maehne) 12 years ago.
gcc46 build log showing linker and malloc errors
main.2.log (16.1 MB) - added by vakeera@… 12 years ago.
gcc46 @4.6.2 error log
gcc46-ld.diff (1.2 KB) - added by Kona8lend@… 12 years ago.
gcc46-darwin11-no-fds.diff (421 bytes) - added by Kona8lend@… 12 years ago.

Change History (74)

Changed 13 years ago by okpail@…

Attachment: main.log added

comment:1 Changed 13 years ago by okpail@…

Cc: okpail@… added

Cc Me!

comment:2 Changed 13 years ago by skymoo (Adam Mercer)

Cc: okpail@… removed
Description: modified (diff)
Owner: changed from macports-tickets@… to mww@…
Port: gcc46 added
Priority: HighNormal
Version: 2.0.3

Don't forget WikiFormatting and to CC the maintainer

comment:3 Changed 13 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:4 Changed 13 years ago by bradskins@…

Cc: bradskins@… added

Cc Me!

comment:5 Changed 13 years ago by m214089

Cc: luis.kornblueh@… added

Cc Me!

comment:6 Changed 13 years ago by mjhsieh@…

Cc: mjhsieh@… added

Cc Me!

comment:7 Changed 13 years ago by gregorbrandt@…

Cc: gregorbrandt@… added

Cc Me!

comment:8 Changed 12 years ago by josh@…

Cc: josh@… added

Cc Me!

comment:9 Changed 12 years ago by qpjevi@…

Cc: qpjevi@… added

Cc Me!

comment:10 Changed 12 years ago by fyu+macports@…

Cc: fyu+macports@… added

Cc Me!

comment:11 Changed 12 years ago by david@…

Cc: david@… added

Cc Me!

comment:12 Changed 12 years ago by 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.

comment:13 Changed 12 years ago by larryv (Lawrence Velázquez)

Cc: larry.velazquez@… added

Cc Me!

comment:14 Changed 12 years ago by sygnet@…

Cc: sygnet@… added

Cc Me!

comment:15 in reply to:  description Changed 12 years ago by E.Kirk@…

Cc Me!

comment:16 Changed 12 years ago by AlonzoQuixote@…

Cc: AlonzoQuixote@… added

Cc Me!

comment:17 in reply to:  12 Changed 12 years ago by 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

comment:18 Changed 12 years ago by david.brockley@…

Cc: david.brockley@… added

Cc Me!

comment:19 Changed 12 years ago by arsenm2@…

Cc: arsenm2@… added

Cc Me!

comment:20 Changed 12 years ago by vincent.liegeois@…

Cc: vincent.liegeois@… added

Cc Me!

comment:21 Changed 12 years ago by maehne (Torsten Maehne)

Cc: Torsten.Maehne@… added

Cc Me!

comment:22 Changed 12 years ago by 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.

Changed 12 years ago by maehne (Torsten Maehne)

Attachment: gcc46_build.log.bz2 added

gcc46 build log showing linker and malloc errors

comment:23 Changed 12 years ago by bosch@…

Cc: bosch@… added

Cc Me!

comment:24 Changed 12 years ago by Serge3leo (Serguei E. Leontiev)

Cc: leo@… added

Cc Me!

comment:25 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: scottp@… added

Has duplicate #31976.

comment:26 Changed 12 years ago by alexander.bolodurin+macports@…

Cc: alexander.bolodurin+macports@… added

Cc Me!

comment:27 Changed 12 years ago by vakeera@…

Cc: vakeera@… added

Cc Me!

comment:28 Changed 12 years ago by 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/

Changed 12 years ago by vakeera@…

Attachment: main.2.log added

gcc46 @4.6.2 error log

comment:29 Changed 12 years ago by 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

comment:30 Changed 12 years ago by richard@…

Cc: richard@… added

Cc Me!

Changed 12 years ago by Kona8lend@…

Attachment: gcc46-ld.diff added

comment:32 Changed 12 years ago by 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.

comment:33 Changed 12 years ago by Kona8lend@…

Cc: Kona8lend@… added

Cc Me!

comment:34 Changed 12 years ago by drkp (Dan Ports)

Cc: dports@… added

Cc Me!

comment:35 Changed 12 years ago by 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.

comment:36 Changed 12 years ago by daitakahashi

Cc: dtakahashi42@… added

Cc Me!

comment:37 Changed 12 years ago by 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

comment:38 in reply to:  37 Changed 12 years ago by 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.

Changed 12 years ago by Kona8lend@…

Attachment: gcc46-darwin11-no-fds.diff added

comment:39 Changed 12 years ago by 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.

comment:40 Changed 12 years ago by drkp (Dan Ports)

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

comment:41 Changed 12 years ago by drkp (Dan Ports)

Cc: lukas.reichlin@… added

Also has duplicate #32142

comment:42 in reply to:  28 ; Changed 12 years ago by 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.

comment:43 Changed 12 years ago by 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?

comment:44 Changed 12 years ago by fleason (Fred Leason)

Cc: fleason@… added

Cc Me!

comment:44 in reply to:  42 Changed 12 years ago by 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.

comment:45 Changed 12 years ago by 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.

comment:46 in reply to:  45 Changed 12 years ago by 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.)

comment:47 Changed 12 years ago by 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.

comment:48 Changed 12 years ago by vakeera@…

Cc: vakeera@… removed

Cc Me!

comment:49 Changed 12 years ago by jacobu@…

Cc: jacobu@… added

Cc Me!

comment:50 Changed 12 years ago by akimd (Akim Demaille)

Cc: akim.demaille@… added

Cc Me!

comment:51 Changed 12 years ago by bonoba@…

Cc: bonoba@… added

Cc Me!

comment:52 Changed 12 years ago by vallentin@…

Cc: vallentin@… added

Cc Me!

comment:53 Changed 12 years ago by adfernandes (Andrew Fernandes)

Cc: adfernandes@… added

Cc Me!

comment:54 Changed 12 years ago by jon@…

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

comment:55 in reply to:  54 ; Changed 12 years ago by 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).

comment:56 in reply to:  55 Changed 12 years ago by 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.

comment:57 Changed 12 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:58 Changed 12 years ago by Kona8lend@…

Changeset r87656 fixes the problem for me on Lion.

comment:59 Changed 12 years ago by 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

comment:60 Changed 12 years ago by drkp (Dan Ports)

Resolution: fixed
Status: newclosed

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

comment:61 Changed 12 years ago by 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).

comment:62 in reply to:  61 Changed 12 years ago by 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.

comment:63 Changed 12 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: closedreopened

comment:64 Changed 12 years ago by adfernandes (Andrew Fernandes)

Resolution: fixed
Status: reopenedclosed

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

comment:65 Changed 12 years ago by jwiegley@…

Cc: jwiegley@… added

Cc Me!

comment:66 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: closedreopened

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

comment:67 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Owner: changed from mww@… to jeremyhu@…
Status: reopenednew
Summary: building gcc46 on osx lion failsDon't build gcc ports with --enable-fully-dynamic-string

comment:68 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed

comment:69 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.