Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 117741 - gnat-3.45 fails to configure (-lgcc_s issue)
Summary: gnat-3.45 fails to configure (-lgcc_s issue)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: ada team [OBSOLETE]
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-04 07:06 UTC by Sven E.
Modified: 2006-01-05 14:30 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven E. 2006-01-04 07:06:15 UTC
When trying to emerge gnat-3.45 (or gnat-3.44-r2 as in the example below), I get the following error:

/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
*** The command '/var/tmp/portage/gnat-3.44-r2/work/usr/bin/gcc -o conftest -O3 -mtune=pentium4 -march=pentium4  -L/var/tmp/portage/gnat-3.44-r2/work/usr/lib/gcc/i486-linux-gnu/3.4.5 conftest.c' failed.
*** You must set the environment variable CC to a working compiler.
Comment 1 Sven E. 2006-01-04 07:31:48 UTC
Okay, to add more information:

I tried alternatively to emerge gnat-3.44-r2, the issue is the same as for 3.45 ... now back to george's post on the other bug report:

I resynced this morning, without any effect ...

"So, try emerging gcc again? I hope you have a .tbz2 (binary) of your previous
gcc? Then you could downgrade and test again.. It is usefull to do quickpkg gcc
before you emerge a new version anyway."

About the first part, I reemerged gc-3.45 (just in case) ... I am not sure about what you mean with the .tbz2 (bin) thing and quickpkg ... I got a whole bunch of different gccs, I usually switch them with gcc-config ... but to make sure, I reemerged gcc-4.5 this morning ...

Next point:

"can you please also check what instances of libgcc_s you have on your system:
find /usr/lib -iname libgcc_s*
find /lib -iname libgcc_s*
 and post the list. It would also be good if you could identify where each of
them is coming from:
equery belongs file_from_found_list"

Okay, let's see, what I can find out ...

locate libgcc_s
/lib/libgcc_s.so.1
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc_s.so.1
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc_s.so
/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libgcc_s.so.1
/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libgcc_s.so
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcc_s.so.1
/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcc_s.so
/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20051223/libgcc_s.so.1
/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20051223/libgcc_s.so
/usr/lib/gcc/m68k-unknown-linux-gnu/3.4.5/libgcc_s.so.2
/usr/lib/gcc/m68k-unknown-linux-gnu/3.4.5/libgcc_s.so
/usr/lib/gcc/alpha-unknown-linux-gnu/3.4.5/libgcc_s.so.1
/usr/lib/gcc/alpha-unknown-linux-gnu/3.4.5/libgcc_s.so
/usr/lib/ada/libgcc_s.so.1
/usr/lib/ada/libgcc_s.so

>>> equery b `locate libgcc_s` gives:
dev-lang/gnat-3.44-r2 (/usr/lib/ada/libgcc_s.so -> libgcc_s.so.1)
dev-lang/gnat-3.44-r2 (/usr/lib/ada/libgcc_s.so.1)
cross-alpha-unknown-linux-gnu/gcc-3.4.5 (/usr/lib/gcc/alpha-unknown-linux-gnu/3.4.5/libgcc_s.so ->  libgcc_s.so.1)
cross-alpha-unknown-linux-gnu/gcc-3.4.5 (/usr/lib/gcc/alpha-unknown-linux-gnu/3.4.5/libgcc_s.so.1)
cross-m68k-unknown-linux-gnu/gcc-3.4.5 (/usr/lib/gcc/m68k-unknown-linux-gnu/3.4.5/libgcc_s.so -> libgcc_s.so.2)
cross-m68k-unknown-linux-gnu/gcc-3.4.5 (/usr/lib/gcc/m68k-unknown-linux-gnu/3.4.5/libgcc_s.so.2)
sys-devel/gcc-3.3.6 (/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc_s.so -> libgcc_s.so.1)
sys-devel/gcc-3.3.6 (/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc_s.so.1)
sys-devel/gcc-4.0.2-r1 (/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libgcc_s.so.1)
sys-devel/gcc-4.0.2-r1 (/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libgcc_s.so -> libgcc_s.so.1)
sys-devel/gcc-3.4.5 (/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcc_s.so.1)
sys-devel/gcc-3.4.5 (/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcc_s.so -> libgcc_s.so.1)
sys-devel/gcc-4.1.0_beta20051223 (/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20051223/libgcc_s.so.1)
sys-devel/gcc-4.1.0_beta20051223 (/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20051223/libgcc_s.so -> libgcc_s.so.1)

I can'T see a package for /lib/lib_gccs.so.1 ... hummm, this seems a little odd ?

If more info is needed - please feel free to ask for it ...

Comment 2 George Shapovalov (RETIRED) gentoo-dev 2006-01-04 12:04:35 UTC
Ok, I think I've got a fix. Please resync and try again. 
I repackaged the bootstrap compiler (The issue I thought was specific to amd64 appears to relate to system gcc). Since the ebuilds were already out of package mask I had to upload the result under modified name and adjust ebuilds, otherwise the stuff in the tree would be broken until mirrors would pick up new binary - for ~ 4 hours.. What this means, is that you only have to wait for ~ 30 min, for the cvs modification to propagate. If you are impatient just change the:
x86? ( http://dev.gentoo.org/~george/src/gcc-3.4-i386.tar.bz2 )
line in SRC_URI to 
x86? ( http://dev.gentoo.org/~george/src/gcc-3.4-i386-r1.tar.bz2 )

update digest and emerge..
Do this for all >=gnat-3.44-r2 ebuilds that you want to build..

Since this is a compile-time fix, no new revision issued.

That should fix it. Basically looks like previously one of your system's libgcc_s libs was picked up during bootstrap, and that cised to work after the upgrade to gcc-3.4.5.

As for the /lib/libgcc_s.so* files: I could not identify their origin as well, until now. I have a relatively fresh chroot install and there /lib/libgcc_s.so.1 was dated Oct 20, which seems to be around the time the 2005.1-r1 stages were produced (the chroot was built like Dec 26th or around, so this is in no way mine). Thus it is likely that the file belongs to the stage. 
It seems you can remove this file and a symlink (/lib/lingcc_s.so*) now, that you have rebuilt gcc (probably a few times) after the original install. At least I can compile stuff here after I moved them out. To be safe, rather than just running rm on them move them somewhere out of lib search path, so that you can restore them if need arises (although I think that kind of breakage should be reported as bugs really).

George
Comment 3 davegot 2006-01-05 13:59:33 UTC
I tried to re-emerge gnat-3.4.5 and I get the following:

>>> checksums src_uri ;-) gcc-core-3.4.5.tar.bz2
>>> checksums src_uri ;-) gcc-ada-3.4.5.tar.bz2

!!! Digest verification Failed:
!!!    /var/tmp/portage/gnat-3.45/distdir/gcc-3.4-i386-r1.tar.bz2
!!! Reason: Filesize does not match recorded size
!!! Got:      10364595
!!! Expected: 1002016

This is on an x86 build
Comment 4 George Shapovalov (RETIRED) gentoo-dev 2006-01-05 14:30:46 UTC
Sorry about that. For some reason digest for 3.45 got screwed (3.44-r2 has it right for the same source). Looks like I generated that digest not quite timely..
Fixed now. Please resync in 30 min..

George