* [Bug c/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
@ 2008-08-14 11:57 ` jay dot krell at cornell dot edu
2008-08-14 12:06 ` jay dot krell at cornell dot edu
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jay dot krell at cornell dot edu @ 2008-08-14 11:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from jay dot krell at cornell dot edu 2008-08-14 11:55 -------
Here is a lame workaround:
if (Host == Target) and (Host != Build):
ExtraConfig += " -with-sysroot=/"
ExtraConfig += " -with-build-sysroot=" + DefaultSysroot
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
2008-08-14 11:57 ` [Bug c/37079] " jay dot krell at cornell dot edu
@ 2008-08-14 12:06 ` jay dot krell at cornell dot edu
2008-08-16 22:38 ` [Bug bootstrap/37079] " pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jay dot krell at cornell dot edu @ 2008-08-14 12:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from jay dot krell at cornell dot edu 2008-08-14 12:05 -------
wrong workaround before, actual:
def WorkaroundUnableToFindSparc64LibGcc():
#
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
# ld: cannot find -lgcc_s
# collect2: ld returned 1 exit status
# make[4]: *** [libstdc++.la] Error 1
# make[4]: Leaving directory
/obj/gcc.1/sparc64-sun-solaris2.10/sparc64-sun-solaris2.10/sparc64-sun-solaris2.10/libstdc++-v3/src
#
# -disable-shared is probably also a good workaround here
#
PatchName = "inability to find sparc64 libgcc.so"
print("patching install " + PatchName)
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")
print("done patching " + PatchName)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37079
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug bootstrap/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
2008-08-14 11:57 ` [Bug c/37079] " jay dot krell at cornell dot edu
2008-08-14 12:06 ` jay dot krell at cornell dot edu
@ 2008-08-16 22:38 ` pinskia at gcc dot gnu dot org
2008-08-17 8:52 ` jay dot krell at cornell dot edu
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-08-16 22:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug bootstrap/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
` (2 preceding siblings ...)
2008-08-16 22:38 ` [Bug bootstrap/37079] " pinskia at gcc dot gnu dot org
@ 2008-08-17 8:52 ` jay dot krell at cornell dot edu
2008-08-17 8:53 ` jay dot krell at cornell dot edu
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jay dot krell at cornell dot edu @ 2008-08-17 8:52 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug bootstrap/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
` (3 preceding siblings ...)
2008-08-17 8:52 ` jay dot krell at cornell dot edu
@ 2008-08-17 8:53 ` jay dot krell at cornell dot edu
2009-12-09 2:00 ` 3dw4rd at verizon dot net
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jay dot krell at cornell dot edu @ 2008-08-17 8:53 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug bootstrap/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
` (4 preceding siblings ...)
2008-08-17 8:53 ` jay dot krell at cornell dot edu
@ 2009-12-09 2:00 ` 3dw4rd at verizon dot net
2009-12-09 4:22 ` howarth at nitro dot med dot uc dot edu
2009-12-09 13:22 ` 3dw4rd at verizon dot net
7 siblings, 0 replies; 9+ messages in thread
From: 3dw4rd at verizon dot net @ 2009-12-09 2:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug bootstrap/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
` (5 preceding siblings ...)
2009-12-09 2:00 ` 3dw4rd at verizon dot net
@ 2009-12-09 4:22 ` howarth at nitro dot med dot uc dot edu
2009-12-09 13:22 ` 3dw4rd at verizon dot net
7 siblings, 0 replies; 9+ messages in thread
From: howarth at nitro dot med dot uc dot edu @ 2009-12-09 4:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug bootstrap/37079] cannot find -lgcc_s
2008-08-11 9:29 [Bug c/37079] New: cannot find -lgcc_s jayk123 at hotmail dot com
` (6 preceding siblings ...)
2009-12-09 4:22 ` howarth at nitro dot med dot uc dot edu
@ 2009-12-09 13:22 ` 3dw4rd at verizon dot net
7 siblings, 0 replies; 9+ messages in thread
From: 3dw4rd at verizon dot net @ 2009-12-09 13:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 9+ messages in thread