[Bug target/30572] New: [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[Bug target/30572] New: [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

I don't know when this broke but this has been here between 
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00121.html (rev 120402)
and
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00134.html (rev 120429)

For some reason I think this was caused by the toplevel libgcc which was
introduced inbetween those revisions.  Also I thought I tested toplevel libgcc
on ppc-darwin with getting no failures.


-- 
           Summary: [4.3 Regression] libstdc++ links against
                    /libgcc_s.1.dylib instead of
                    $(prefix)/lib/libgcc_s.1.dylib
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin


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

[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.0


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

[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-01-24 06:35 -------
libgcc_s.1.dylib has the correct install name as far as I can tell (otool -L
output):
libgcc_s.1.dylib:
        /Users/pinskia/gcc-trunk-java/lib/libgcc_s.1.dylib (compatibility
version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.1.6)


libstdc++6.dylib output:
otool -L libstdc++.6.dylib
libstdc++.6.dylib:
        /Users/pinskia/gcc-trunk-java/lib/libstdc++.6.dylib (compatibility
version 7.0.0, current version 7.10.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.1.6)
        /libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)


-- 


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

[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[echristo at apple dot com]

-- 

echristo at apple dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |echristo at apple dot com
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-01-24 06:40:46
               date|                            |


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

[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[echristo at apple dot com]

------- Comment #2 from echristo at apple dot com  2007-01-24 18:56 -------
I looked at this a bit last night and I'm mystified. I'll look more after this
weekend.


-- 


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

[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[echristo at apple dot com]

------- Comment #3 from echristo at apple dot com  2007-04-18 18:44 -------
As a note, this is due to the make install bit of libgcc when putting things
back into the gcc build dir we set $(slibdir) to null and then the darwin
install name ends up being set to $(slibdir)/libgcc_s.1.dylib which ends up
being /libgcc_s.1.dylib.


-- 


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

[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-09 18:55 -------
*** Bug 32255 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dir at lanl dot gov


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-08-20 09:13 -------
Any news on this?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-01-24 06:40:46         |2007-08-20 09:13:25
               date|                            |


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[echristo at apple dot com]

------- Comment #6 from echristo at apple dot com  2007-08-20 17:11 -------
No, I spoke to Daniel about it a while back, but he hasn't had time to look
into it. It's definitely caused by the toplevel changes to libgcc. The basic
idea is that the toplevel makefile re-installs libgcc into the gcc directory
for some reason causing a relink of libgcc and since the is null the installed
libgcc gets an install name of /libgcc_s.1.dylib. This is then used with
libstdc++. When it's installed it is _again_ relinked and then has the proper
install_name, but this won't fix the problem that libstdc++ has since it's
already been linked in.


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2007-10-28 04:31 -------
This also happens on x86-darwin.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|powerpc-darwin              |*-darwin*
   Last reconfirmed|2007-08-20 09:13:25         |2007-10-28 04:31:04
               date|                            |


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2007-10-31 22:00 -------
Couldn't we use install_name_tool before installing the binary to fix up the
install name?


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[echristo at apple dot com]

------- Comment #9 from echristo at apple dot com  2007-11-01 17:09 -------
I guess that would be a good workaround.


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2007-11-18 20:06 -------
*** Bug 34142 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[fang at csl dot cornell dot edu]

------- Comment #11 from fang at csl dot cornell dot edu  2007-11-25 04:10 -------
*nudge* (got patch?)

Also, is there a "make installcheck" mechanism in place to automatically test
installed builds?  
It wouldn't have to be very extensive, just enough to make sure each supported
language at least compiles and links, which would catch installation breakages
such as this.  

Just an idea.  


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[ek dot kato at gmail dot com]

------- Comment #12 from ek dot kato at gmail dot com  2007-11-28 09:19 -------
Hi,

I encountered this problem today, as I would like to use latest gfortran on Mac
OS X 10.4.11.

Anyway here is the crude workaround to avoid the install name problem.  It just
install libgcc_s.*.dylib with slibdir defiend, and then move them to the
$(gcc_objdir) later.

Index: libgcc/Makefile.in
===================================================================
--- libgcc/Makefile.in  (revision 130489)
+++ libgcc/Makefile.in  (working copy)
@@ -100,8 +100,13 @@
        # in-tree libraries, and DejaGNU) know about the layout
        # of the build tree, for now.
        $(MAKE) install DESTDIR=$(gcc_objdir) \
-         slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)
+         slibdir=$(slibdir) libsubdir= MULTIOSDIR=$(MULTIDIR)

+       objdir="$(gcc_objdir)/$(slibdir)";                      \
+       if test -d "$$objdir"; then                             \
+         mv -f $$objdir/libgcc_s.* $(gcc_objdir)/;             \
+       fi;                                                     \
+
 .PHONY: all-multi
 all-multi:
        # If this is the top-level multilib, build all the other


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[ek dot kato at gmail dot com]

------- Comment #13 from ek dot kato at gmail dot com  2007-11-29 09:08 -------
Oops, I noticed the diff sent yesterday was broken.  Here is the correct one
for the workaround.


Index: libgcc/Makefile.in
===================================================================
--- libgcc/Makefile.in  (revision 130508)
+++ libgcc/Makefile.in  (working copy)
@@ -100,8 +100,17 @@
        # in-tree libraries, and DejaGNU) know about the layout
        # of the build tree, for now.
        $(MAKE) install DESTDIR=$(gcc_objdir) \
-         slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)
+         slibdir=$(slibdir) libsubdir= MULTIOSDIR=$(MULTIDIR)

+       objdir="$(gcc_objdir)/$(slibdir)";              \
+       if test -d $$objdir; then                       \
+         for file in $$objdir/libgcc_s*; do            \
+           if test -f $$file -o -L $$file; then        \
+             mv -f $$file $(gcc_objdir)/;              \
+           fi;                                         \
+         done;                                         \
+       fi
+
 .PHONY: all-multi
 all-multi:
        # If this is the top-level multilib, build all the other


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

------- Comment #14 from howarth at nitro dot med dot uc dot edu  2007-12-16 21:52 -------
Etsushi,
     Your last patch doesn't do the right thing for the x86_64 multilib. The
shared libraries in...

/sw/lib/gcc4.3/lib/x86_64

...are linked to /sw/lib/gcc4.3/lib/libgcc_s.1.dylib instead of the desired
/sw/lib/gcc4.3/lib/x86_64/libgcc_s.1.dylib.


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[ek dot kato at gmail dot com]

------- Comment #15 from ek dot kato at gmail dot com  2007-12-17 02:02 -------
(In reply to comment #14)
> Etsushi,
>      Your last patch doesn't do the right thing for the x86_64 multilib. The
> shared libraries in...
> 
> /sw/lib/gcc4.3/lib/x86_64
> 
> ...are linked to /sw/lib/gcc4.3/lib/libgcc_s.1.dylib instead of the desired
> /sw/lib/gcc4.3/lib/x86_64/libgcc_s.1.dylib.

Since /sw/lib/gcc4.3/lib/libgcc_s.1.dylib is a binary with 2 architectures
(i386 and x86_64 in my case; see below), I think it should work and the links
are intended one, which is not related the last patch.

$ file /sw/lib/gcc4.3/lib/libgcc_s.1.dylib
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib: Mach-O universal binary with 2
architectures
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib (for architecture i386):    Mach-O
dynamically linked shared library i386
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib (for architecture x86_64):  Mach-O 64-bit
dynamically linked shared library x86_64


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

------- Comment #16 from howarth at nitro dot med dot uc dot edu  2007-12-17 02:55 -------
My mistake. I had forgotten to check the contents of the binaries.

Eric,
    Shouldn't this go into gcc trunk (with perhaps a TODO comment that a
cleaner approach should replace it)?


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[echristo at apple dot com]

------- Comment #17 from echristo at apple dot com  2007-12-17 23:25 -------
I rather like this patch... someone should ping Paolo about it.


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

------- Comment #18 from howarth at nitro dot med dot uc dot edu  2007-12-18 00:23 -------
Etsushi,
     Why don't you go ahead and submit your patch with a ChangeLog entry to the
gcc-patches mailing list.? It is under the limit of lines for patches without
FSF paperwork (in case you don't have any).


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[ek dot kato at gmail dot com]

------- Comment #19 from ek dot kato at gmail dot com  2007-12-18 02:20 -------
OK.  I've just sent a mail to gcc-patches.


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[bonzini at gnu dot org]

------- Comment #20 from bonzini at gnu dot org  2007-12-18 08:35 -------
Eric, would you please take a look at my counter-proposal and commit it if it
works?


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

------- Comment #21 from howarth at nitro dot med dot uc dot edu  2007-12-19 04:38 -------
The counter proposal doesn't work. It produces...

[Macintosh:darwin_objdir/i686-apple-darwin9/libgcc] howarth% otool -L
libgcc_s.1.dylib
libgcc_s.1.dylib:
        @slibdir@/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[bonzini at gcc dot gnu dot org]

------- Comment #22 from bonzini at gnu dot org  2007-12-19 14:28 -------
Subject: Bug 30572

Author: bonzini
Date: Wed Dec 19 14:28:32 2007
New Revision: 131062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131062
Log:
2007-12-19  Etsushi Kato  <ek.kato@gmail.com>
            Paolo Bonzini  <bonzini@gnu.org>

        PR target/30572
        * Makefile.in: Use @shlib_slibdir@ substitution to get correct install
name
        on darwin.
        * config/t-slibgcc-darwin: Use @shlib_slibdir@ for -install_name.


Modified:
    trunk/libgcc/ChangeLog
    trunk/libgcc/Makefile.in
    trunk/libgcc/config/t-slibgcc-darwin


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[jakub at gcc dot gnu dot org]

------- Comment #23 from jakub at gcc dot gnu dot org  2007-12-19 14:48 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

------- Comment #24 from howarth at nitro dot med dot uc dot edu  2008-02-29 14:06 -------
Jakub,
    I think your fix to this PR could be the cause of
PR 35401. All of gcc 4.3.0's shared libraries are being
linked against the system libgcc in /usr/lib on darwin
rather than the libgcc built and installed by gcc 4.3.0
(in say /sw/lib/gcc4.3/lib for instance).
                        Jack


-- 


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