[Bug bootstrap/37079] cannot find -lgcc_s

[Bug bootstrap/37079] cannot find -lgcc_s

[kai.extern at gmail dot com]

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

Kai Henningsen <kai.extern at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kai.extern at gmail dot com

--- Comment #9 from Kai Henningsen <kai.extern at gmail dot com> 2011-12-23 16:12:17 UTC ---
I am seeing something very like this on x86_64-linux-gnu (native), gcc 4.6.2.
The compiler (with --disable-bootstrap) builds and installs into the prefix,
but then ld is unable to find libgcc_s, because the directory it is installed
in is not in the search path. It is installed into
$(prefix)/lib/gcc/$(target)/lib64.

Complete configure options (including some only relevant for different
packages; from config.log):

$(src)/gcc/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--prefix=$(prefix) --disable-bootstrap --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-multilib --disable-nls
--enable-cxx --enable-decimal-float=no --enable-maintainer-mode
--enable-optimization --enable-pch --enable-rpath
--enable-version-specific-runtime-libs --with-bits=gmp --with-gnu-as
--with-gnu-ld --with-ppl --enable-languages=c,c++ --with-gmp=$(prefix)
--with-mpfr=$(prefix) --with-mpc=$(prefix) --with-ppl=$(prefix)
--with-cloog=$(prefix) --target=x86_64-linux-gnu

Other coments: Ubuntu, I'm symlinking all system libs into
$(prefix)/$(target)/lib before I start.

The actual path searched is:

$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/
$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/../../../../lib64/
/lib/../lib64/
/usr/lib/../lib64/
$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/../../../../x86_64-linux-gnu/lib/
$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/../../../
$(prefix)/x86_64-linux-gnu/lib64/
$(prefix)/lib64/
/usr/local/lib64/
/lib64/
/usr/lib64/
$(prefix)/x86_64-linux-gnu/lib/
$(prefix)/lib/
/usr/local/lib/
/lib/
/usr/lib/

[Bug bootstrap/37079] cannot find -lgcc_s

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-23 17:11:19 UTC ---
(In reply to comment #9)
> --enable-version-specific-runtime-libs

That's broken on x86_64 see bug 32415

[Bug bootstrap/37079] cannot find -lgcc_s

[3dw4rd at verizon dot net]

------- Comment #8 from 3dw4rd at verizon dot net  2009-12-09 13:22 -------
Subject: Re:  cannot find -lgcc_s

howarth at nitro dot med dot uc dot edu wrote:
> ------- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-12-09 04:21 -------
> (In reply to comment #6)
>   
>> I have this problem of MacOSX 10.3
>> $ gcc -v
>> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
>> Thread model: posix
>> gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)
>>
>> When I do a make on an empty directory it gets all the way into stage3 linking
>> libstdc++ until this:
>>
>> /usr/bin/ld: can't locate file for: -lgcc_s.10.4
>>
>> There are several libgcc_s around:
>>
>> MacOSX:~/obj ed$ find . -name libgcc_s\*
>> ./gcc/libgcc_s.1.dylib
>> ./gcc/libgcc_s_ppc64.1.dylib
>> ./gcc/libgcc_s_x86_64.1.dylib
>> ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
>> ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
>> ./prev-gcc/libgcc_s.1.dylib
>> ./prev-gcc/libgcc_s_ppc64.1.dylib
>> ./prev-gcc/libgcc_s_x86_64.1.dylib
>> ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
>> ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
>> ./stage1-gcc/libgcc_s.1.dylib
>> ./stage1-gcc/libgcc_s_ppc64.1.dylib
>> ./stage1-gcc/libgcc_s_x86_64.1.dylib
>> ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
>> ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
>>
>> I'm actually surprised by the ppc64 and x86_64 libs - I'm not building a cross
>> compiler.
>>
>>     
>
> I would be shocked if gcc trunk built on darwin7. Unless I am mistaken, we now
> assume
> that all darwin targets support dwarf which isn't the default case until Xcode
> 2.4 (10.4).
>
>
>   
I've been bootstrapping trunk happily up till about a couple months ago: 
10.15.2009.

Also, I've noticed a lot of issues with libgcc_s on other targets.  It 
looks like a build system change.

Is there a way to get the SVN version of a gcc?  I remember some 
discussion of that way back.


-- 


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

[Bug bootstrap/37079] cannot find -lgcc_s

[howarth at nitro dot med dot uc dot edu]

------- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-12-09 04:21 -------
(In reply to comment #6)
> I have this problem of MacOSX 10.3
> $ gcc -v
> Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
> Thread model: posix
> gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)
> 
> When I do a make on an empty directory it gets all the way into stage3 linking
> libstdc++ until this:
> 
> /usr/bin/ld: can't locate file for: -lgcc_s.10.4
> 
> There are several libgcc_s around:
> 
> MacOSX:~/obj ed$ find . -name libgcc_s\*
> ./gcc/libgcc_s.1.dylib
> ./gcc/libgcc_s_ppc64.1.dylib
> ./gcc/libgcc_s_x86_64.1.dylib
> ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
> ./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
> ./prev-gcc/libgcc_s.1.dylib
> ./prev-gcc/libgcc_s_ppc64.1.dylib
> ./prev-gcc/libgcc_s_x86_64.1.dylib
> ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
> ./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
> ./stage1-gcc/libgcc_s.1.dylib
> ./stage1-gcc/libgcc_s_ppc64.1.dylib
> ./stage1-gcc/libgcc_s_x86_64.1.dylib
> ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
> ./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
> 
> I'm actually surprised by the ppc64 and x86_64 libs - I'm not building a cross
> compiler.
> 

I would be shocked if gcc trunk built on darwin7. Unless I am mistaken, we now
assume
that all darwin targets support dwarf which isn't the default case until Xcode
2.4 (10.4).


-- 


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

[Bug bootstrap/37079] cannot find -lgcc_s

[3dw4rd at verizon dot net]

------- Comment #6 from 3dw4rd at verizon dot net  2009-12-09 02:00 -------
I have this problem of MacOSX 10.3
$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)

When I do a make on an empty directory it gets all the way into stage3 linking
libstdc++ until this:

/usr/bin/ld: can't locate file for: -lgcc_s.10.4

There are several libgcc_s around:

MacOSX:~/obj ed$ find . -name libgcc_s\*
./gcc/libgcc_s.1.dylib
./gcc/libgcc_s_ppc64.1.dylib
./gcc/libgcc_s_x86_64.1.dylib
./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
./powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
./prev-gcc/libgcc_s.1.dylib
./prev-gcc/libgcc_s_ppc64.1.dylib
./prev-gcc/libgcc_s_x86_64.1.dylib
./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
./prev-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib
./stage1-gcc/libgcc_s.1.dylib
./stage1-gcc/libgcc_s_ppc64.1.dylib
./stage1-gcc/libgcc_s_x86_64.1.dylib
./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.1.dylib
./stage1-powerpc-apple-darwin7.9.0/libgcc/libgcc_s.dylib

I'm actually surprised by the ppc64 and x86_64 libs - I'm not building a cross
compiler.


-- 

3dw4rd at verizon dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |3dw4rd at verizon dot net


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

[Bug bootstrap/37079] cannot find -lgcc_s

[jay dot krell at cornell dot edu]

------- Comment #5 from jay dot krell at cornell dot edu  2008-08-17 08:52 -------
Subject: RE:  cannot find -lgcc_s


Subject line reminded me: Also I -disable-bootstrap.



> From: jay.krell@cornell.edu
> To: gcc-bugzilla@gcc.gnu.org; pinskia@gcc.gnu.org
> Subject: RE: [Bug bootstrap/37079] cannot find -lgcc_s
> Date: Sun, 17 Aug 2008 08:50:44 +0000
>
>
> Let's dissect the output a bit:
> Word wrap plus laziness => I didn't look closely before.
>
>
> -Wl,-rpath -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> -Wl,-rpath
> -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> -L/obj/gcc.1/sparc64-sun-solaris2.10/sparc64-sun-solaris2.10/./ld
> -L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> -L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sunsolaris2.10/lib/sparcv9
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/lib/sparcv9
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib/sparcv9
> -L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sun-solaris2.10/lib
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/lib
> -L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib
>
>
> vs. the workaround:
>
>
> Directory = Prefix + "/lib/gcc/sparc64-sun-solaris2.10/" + GccVersion
> Run(".", "mkdir -p " + Directory)
> Run(Directory, "-ln -s sparcv9/libgcc_s.so libgcc_s.so")
> Run(Directory, "-ln -s sparcv9/libgcc_s.so.1 libgcc_s.so.1")
>
>
> Therefore:
>
>
>
> The "biarch" paths are not being applied to the "gcc .libs" paths.
> /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
> but not
> /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/sparcv9
>
>
> both for -Wl,-rpath and -L.
> This IS reasonable, since the tools were built with -disable-multilib, BUT
> the .libs were in fact put in sparcv9 -- at least the .so files.
>
>
> (I find all the dot-dots a pain to read! I understand relocatable, and symlinks, but still..)
>
> They are being applied to the "system .libs" paths.
> sys-root/lib/sparcv9 and sys-root/usr/lib/sparcv9.
>
>
> Could be that .so file placement is not so flexible? Because they aren't
> really supposed to be placed here anyway? You know, it is very up to me
> where to place .a files, but .so files maybe more important to adhere
> to strict standards, since they are used at runtime?
>
>
> Also not shown is -enable-version-specific-runtimes or such, whatever
> I saw Cygwin using.
>
>
> It SEEMS the fix is now almost obvious.
> That multilib suffixes need to be applied to more prefixes.
> Or alter the directory structure otherwise, via configure.
>
>
> I should also try without -enable-rpath I guess.
>
>
> Thank you for attention to the bug,
> - Jay
>
>
>
>
>> Date: Sat, 16 Aug 2008 22:36:55 +0000
>> Subject: [Bug bootstrap/37079] cannot find -lgcc_s
>> To: jay.krell@cornell.edu
>> From: gcc-bugzilla@gcc.gnu.org
>>
>>
>>
>> ------- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-16 22:36 -------
>> What happens if you just use --with-build-sysroot= ? without saying the
>> --with-sysroot?
>>
>>
>> --
>>
>> pinskia at gcc dot gnu dot org changed:
>>
>> What |Removed |Added
>> ----------------------------------------------------------------------------
>> Component|c |bootstrap
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
>>
>> ------- You are receiving this mail because: -------
>> You reported the bug, or are watching the reporter.


-- 


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

[Bug bootstrap/37079] cannot find -lgcc_s

[jay dot krell at cornell dot edu]

------- Comment #4 from jay dot krell at cornell dot edu  2008-08-17 08:51 -------
Subject: RE:  cannot find -lgcc_s


  Let's dissect the output a bit:
  Word wrap plus laziness => I didn't look closely before.


  -Wl,-rpath -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1  
  -Wl,-rpath  
  -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1   
  -L/obj/gcc.1/sparc64-sun-solaris2.10/sparc64-sun-solaris2.10/./ld 
  -L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1 
 
-L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sunsolaris2.10/lib/sparcv9 
  -L/usr/local/sparc64-sun-solaris2.10/sys-root/lib/sparcv9  
  -L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib/sparcv9  
 
-L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sun-solaris2.10/lib 
  -L/usr/local/sparc64-sun-solaris2.10/sys-root/lib  
  -L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib  


  vs. the workaround: 


    Directory = Prefix + "/lib/gcc/sparc64-sun-solaris2.10/" + GccVersion  
    Run(".", "mkdir -p " + Directory)  
    Run(Directory, "-ln -s sparcv9/libgcc_s.so libgcc_s.so")  
    Run(Directory, "-ln -s sparcv9/libgcc_s.so.1 libgcc_s.so.1")  


 Therefore:  



 The "biarch" paths are not being applied to the "gcc .libs" paths.
    /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
  but not
    /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/sparcv9


 both for -Wl,-rpath and -L.
 This IS reasonable, since the tools were built with -disable-multilib, BUT
   the .libs were in fact put in sparcv9 -- at least the .so files.


(I find all the dot-dots a pain to read! I understand relocatable, and
symlinks, but still..) 

 They are being applied to the "system .libs" paths.
   sys-root/lib/sparcv9 and sys-root/usr/lib/sparcv9.


 Could be that .so file placement is not so flexible? Because they aren't
  really supposed to be placed here anyway? You know, it is very up to me
  where to place .a files, but .so files maybe more important to adhere
  to strict standards, since they are used at runtime?


 Also not shown is -enable-version-specific-runtimes or such, whatever
  I saw Cygwin using.


It SEEMS the fix is now almost obvious.
That multilib suffixes need to be applied to more prefixes.
Or alter the directory structure otherwise, via configure.


I should also try without -enable-rpath I guess.


Thank you for attention to the bug,
 - Jay




> Date: Sat, 16 Aug 2008 22:36:55 +0000
> Subject: [Bug bootstrap/37079] cannot find -lgcc_s
> To: jay.krell@cornell.edu
> From: gcc-bugzilla@gcc.gnu.org
>
>
>
> ------- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-16 22:36 -------
> What happens if you just use --with-build-sysroot= ? without saying the
> --with-sysroot?
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Component|c |bootstrap
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.


-- 


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

[Bug bootstrap/37079] cannot find -lgcc_s

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-08-16 22:36 -------
What happens if you just use --with-build-sysroot= ? without saying the
--with-sysroot?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |bootstrap


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