While building gnatlink & gnatmake for both i386 and x86_64, get ld: duplicate symbol _system__secondary_stack__mark_idIP in ../rts/libgnat.a(s-secsta.o) and s-secsta.o (and, after fixing this, s-exctab.o). I suppose this is because of a change in Snow Leopard where an object can't be both explicitly present on the command line and in a static library? Though there are other objects explicitly mentioned, eg s-stalib.o, which don't have to be removed. Anyway, editing gcc/ada/gcc-interface/Makefile.in to remove s-exctab.o and s-secsta.o from GNATLINK_OBJS and GNATMAKE_OBJS does the trick, see attached patch.
Created attachment 19424 [details] Patch to gcc/ada/gcc-interface/Makefile.in [Some] objects that are in the RTS archive mustn't be explicitly mentioned.
This is a duplicate of bootstrap/41180, see comment #8. It's an Xcode 3.2 linker bug, (radar 6320843) "duplicate symbols from static libraries not properly ignored". Fixes in 41180 were like my fix suggestion, which works OK on 4.4 but completely breaks ada/4.5.0. The problem as I see it is that the build ends up with * a full set of rts objects in gcc/ada/rts * gcc/ada/rts/libgnat.a * a random subset of rts objects in gcc/ada * a random subset of rts objects in gcc/ada/tools so when we try to build eg gnatcmd, running in gcc/ada/tools, gnatbind calls up (as well as local objects) * the required rts objects in gcc/ada/tools * the remaining rts objects in gcc/ada/rts * -lgnat and the gnatlink invocation adds ../rts/libgnat.a for no particular reason I can see. The Apple bug is triggered when ld sees more than one copy of the same object file; typically one of the rts objects listed above, but even from seeing two copies of libgnat.a. We could avoid this by eliminating all the rts objects (.o files) and by not adding ../rts/libgnat.a in the gnatlink commands As Jack said in 41180, this is an Apple bug and needs to be fixed by Apple.
Created attachment 19503 [details] Workround for Apple bug in Xcode 3.2 I'm not sure that deleting ../$(RTSDIR)/*.o before building common-tools will be OK in all circumstances, but it certainly works for a native Darwin build. The point is that by this stage all the libraries (???) will have been built; and we don't want gnatbind to pick up duplicate .o's from the rts directory (which it scans because of -I../rts).
(In reply to comment #3) > I'm not sure that deleting ../$(RTSDIR)/*.o before building common-tools will > be OK in all circumstances, but it certainly works for a native Darwin build. > The point is that by this stage all the libraries (???) will have been built; > and we don't want gnatbind to pick up duplicate .o's from the rts directory > (which it scans because of -I../rts). After some discussion about this, in which the idea of deleting the RTSDIR object files was frowned on (not to mention that there is at least one .o file which needs to be retained in the RTSDIR), posted a patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01596.html Note that this patch's Subject: refers to PR ada/42254 whereas it should of course be 42554.
I think this bug is caused by a much more fundamental problem: the -c switch to ranlib, which seems to be a Darwin special, appears to cause this problem (at any rate with Xcode >= 3.2, ie darwin10. The top-level configure.ac includes the following *-*-darwin*) # ranlib from Darwin requires the -c flag to look at common symbols. extra_ranlibflags_for_target=" -c" ;; and the SVN log for ths says r60397 | geoffk | 2002-12-22 06:46:41 +0000 (Sun, 22 Dec 2002) | 4 lines * configure.in (extra_ranlibflags_for_target): New variable. (*-*-darwin): Add -c to ranlib commands. * configure (tooldir): Handle extra_ranlibflags_for_target. The Darwin man page for ranlib says -c Include common symbols as definitions with respect to the ta- ble of contents. This is seldom the intended behavior for linking from a library, as it forces the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This option is included only because this was the original behavior of ran- lib. This option is not the default. Apple, in response to Jack Howarth re: radar 6320843 Darwin static archives traditionally do not have common symbols in there table of contents. The -c option forces common symbols into the table of contents and causes this problem. I have replaced the section of configure.ac above by this: *-*-darwin1[[0123456789]]*) # ranlib from Darwin 10 (Xcode 3.2) does not require the -c flag # to look at common symbols. ;; *-*-darwin*) # ranlib from older Darwins requires the -c flag to look at common # symbols. extra_ranlibflags_for_target=" -c" ;; and the build proceeds to completion
Created attachment 19782 [details] Patch to configure.ac, configure
Why not remove the duplicate linkage of s-secsta.o in gnatlink and gnatmake? There is no reason to link it in a second time since it is already in libgnat.a.
It's much worse than that.. Aside from the other object file which triggers the same bug, the make of gnatlink and gnatmake calls in libgnat.a twice. And when you build the other GNAT tools, it calls in all the Ada-derived RTS object files explicitly as well as libgnat.a. I did try deleting them, but (a) the C-derived object files are required, (b) that would mean rebuilding the entire RTS for the smallest change. So I reorganised the bind/link not to call in libgnat.a; to do that you need a libgnatc.a for the C-derived object files. So far so good; but now 'make check-ada' fails for every test in exactly the same way! See http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01596.html (also referenced in comment #4) for the last attempt at this approach (NB it has one error, see http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00005.html). I agree my latest patch here is rather global, but Fortran builds fine and 'make check-fortran' is only showing XFAILs. I can probably make an alternative, restricted to Ada only, might stand more chance of being accepted.
I've traced where the 'ranlib -c' switch was introduced: at http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01183.html . The original purpose of this patch was to fix g77 regressions, and we now pass check-fortran without it, so I think there's some evidence for removing it. Of course, other languages might rely on this switch ...
(In reply to comment #7) > Why not remove the duplicate linkage of s-secsta.o in gnatlink and gnatmake? > There is no reason to link it in a second time since it is already in > libgnat.a. I agree we could tidy up ada/gcc-interface/Makefile but (after removing the ranlib -c flag) it's not necessary to resolve this problem. And no amount of tinkering with this Makefile will fix the problem with 'make check-ada'.
Building gcc trunk with... Index: configure =================================================================== --- configure (revision 156440) +++ configure (working copy) @@ -7292,7 +7292,7 @@ extra_arflags_for_target=" -X32_64" extra_nmflags_for_target=" -B -X32_64" ;; - *-*-darwin*) + *-*-darwin[89]*) # ranlib from Darwin requires the -c flag to look at common symbols. extra_ranlibflags_for_target=" -c" ;; on x86_64-apple-darwin10 doesn't produce any regressions... http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00168.html I am checking with Mike Stump but I suspect that the requirement of -c with ranlib is a depreciated 'feature' from earlier Xcode. In particular, the comments in the ranlib manpage on darwin10.... -c Include common symbols as definitions with respect to the table of contents. This is seldom the intended behavior for linking from a library, as it forces the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This option is included only because this was the original behavior of ranlib. This option is not the default. suggest that this is feature being depreciated out.
I re-ran the tests just for Ada; results at http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00265.html . Looking good - there is a problem with the ACATS tests, but I have a feeling it's some sort of race condition in the test suite (for info, not a dejagnu suite).
Subject: Bug 42554 Author: mrs Date: Fri Mar 19 10:19:52 2010 New Revision: 157563 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157563 Log: PR ada/42554 * configure.ac: Only pass -c to ranlib for darwin9 and earlier. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
Appears to be fixed. Please reopen if that's not the case.
The patch is incomplete. The same logic must be applied to gcc/configure.ac and gcc/configure too.