[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

[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=gccview=revrev=131062
Log:
2007-12-19  Etsushi Kato  [EMAIL PROTECTED]
Paolo Bonzini  [EMAIL PROTECTED]

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

[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

[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

[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

[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

[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

[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

[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

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

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

[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