[Bug ada/42554] New: Can't build gnatlink, gnatmake

[Bug ada/42554] New: Can't build gnatlink, gnatmake

[simon at pushface dot org]

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.


-- 
           Summary: Can't build gnatlink, gnatmake
           Product: gcc
           Version: 4.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: simon at pushface dot org
 GCC build triplet: *86*-apple-darwin10.2.0
  GCC host triplet: *86*-apple-darwin10.2.0
GCC target triplet: *86*-apple-darwin10.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build gnatlink, gnatmake

[simon at pushface dot org]

------- Comment #1 from simon at pushface dot org  2009-12-30 18:27 -------
Created an attachment (id=19424)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19424&action=view)
Patch to gcc/ada/gcc-interface/Makefile.in

[Some] objects that are in the RTS archive mustn't be explicitly mentioned.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build gnatlink, gnatmake

[simon at pushface dot org]

------- Comment #2 from simon at pushface dot org  2010-01-06 22:35 -------
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.


-- 

simon at pushface dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build gnatlink, gnatmake

[simon at pushface dot org]

------- Comment #3 from simon at pushface dot org  2010-01-07 22:25 -------
Created an attachment (id=19503)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19503&action=view)
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).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build gnatlink, gnatmake

[simon at pushface dot org]

------- Comment #4 from simon at pushface dot org  2010-01-31 22:58 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build gnatlink, gnatmake

[simon at pushface dot org]

------- Comment #5 from simon at pushface dot org  2010-02-01 22:53 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build gnatlink, gnatmake

[simon at pushface dot org]

------- Comment #6 from simon at pushface dot org  2010-02-01 22:55 -------
Created an attachment (id=19782)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19782&action=view)
Patch to configure.ac, configure


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build gnatlink, gnatmake

[howarth at nitro dot med dot uc dot edu]

------- Comment #7 from howarth at nitro dot med dot uc dot edu  2010-02-02 01:55 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build GNAT tools

[simon at pushface dot org]

------- Comment #8 from simon at pushface dot org  2010-02-02 06:26 -------
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.


-- 

simon at pushface dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Can't build gnatlink,       |Can't build GNAT tools
                   |gnatmake                    |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build GNAT tools

[simon at pushface dot org]

------- Comment #9 from simon at pushface dot org  2010-02-02 13:10 -------
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 ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build GNAT tools

[simon at pushface dot org]

------- Comment #10 from simon at pushface dot org  2010-02-02 21:25 -------
(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'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build GNAT tools

[howarth at nitro dot med dot uc dot edu]

------- Comment #11 from howarth at nitro dot med dot uc dot edu  2010-02-02 22:55 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build GNAT tools

[simon at pushface dot org]

------- Comment #12 from simon at pushface dot org  2010-02-03 21:24 -------
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).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build GNAT tools

[mrs at gcc dot gnu dot org]

------- Comment #13 from mrs at gcc dot gnu dot org  2010-03-19 10:20 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554

[Bug ada/42554] Can't build GNAT tools

[fxcoudert at gcc dot gnu dot org]

------- Comment #14 from fxcoudert at gcc dot gnu dot org  2010-05-17 12:07 -------
Appears to be fixed. Please reopen if that's not the case.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554