This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libgcc_s.so.1 yet again
- From: Brad Lucier <lucier at math dot purdue dot edu>
- To: geoffk at geoffk dot org (Geoff Keating)
- Cc: lucier at math dot purdue dot edu (Brad Lucier), gcc at gcc dot gnu dot org
- Date: Tue, 9 Apr 2002 15:04:57 -0500 (EST)
- Subject: Re: libgcc_s.so.1 yet again
>
> Brad Lucier <lucier@math.purdue.edu> writes:
>
> > Now that I'm compiling various packages with gcc-3.1 on sparcv9-sun-solaris2.8,
> > I'm having libgcc_s.so.1 "issues" again.
> >
> > We've been assured that there will be forward compatibility with libgcc,
> > so that one can always use a newer version of libgcc with code compiled
> > with an older version of gcc. But now, I have to change my LD_LIBRARY_PATH
> > every time I execute a program compiled with a different gcc-3.1 (64-bit or
> > 32-bit).
> >
> > So is there any way to build libgcc so that it is usable with either
> > 64-bit or 32-bit applications on sparc?
>
> Just put both directories in your LD_LIBRARY_PATH. ld.so on Solaris
> appears to be smart enough to avoid shared objects that don't match
> the current ABI.
I finally decided to go with only one installation of gcc-3.1 on
sparc-sun-solaris2.8 (instead of having another installation in
sparcv9-sun-solaris2.8) and tried to follow your advice.
But it seems, as of today's CVS, that libgcc.so* is not installed in
$installdir/lib/sparcv9!!!!! So I can't run any sparcv9 binaries at all
(at least until I put a few links into lib/sparcv9).
This can't be right.
Here are some listings from my install directory:
banach-234% ll /pkgs/gcc-3.1/lib/sparcv9
total 24682
-rw-r--r-- 1 lucier 16104 Apr 9 14:56 libfrtbegin.a
-rw-r--r-- 1 lucier 3374412 Apr 9 14:56 libg2c.a
-rwxr-xr-x 1 lucier 743 Apr 9 14:56 libg2c.la*
lrwxrwxrwx 1 lucier 15 Apr 9 14:56 libg2c.so -> libg2c.so.0.0.0*
lrwxrwxrwx 1 lucier 15 Apr 9 14:56 libg2c.so.0 -> libg2c.so.0.0.0*
-rwxr-xr-x 1 lucier 2831736 Apr 9 14:56 libg2c.so.0.0.0*
-rw-r--r-- 1 lucier 945804 Apr 9 14:57 libiberty.a
-rw-r--r-- 1 lucier 539436 Apr 9 14:57 libobjc.a
-rwxr-xr-x 1 lucier 694 Apr 9 14:57 libobjc.la*
-rw-r--r-- 1 lucier 8721316 Apr 9 14:56 libstdc++.a
-rwxr-xr-x 1 lucier 1526 Apr 9 14:56 libstdc++.la*
lrwxrwxrwx 1 lucier 18 Apr 9 14:56 libstdc++.so -> libstdc++.so.4.0.0*
lrwxrwxrwx 1 lucier 18 Apr 9 14:56 libstdc++.so.4 -> libstdc++.so.4.0.0*
-rwxr-xr-x 1 lucier 8015416 Apr 9 14:56 libstdc++.so.4.0.0*
-rw-r--r-- 1 lucier 741964 Apr 9 14:56 libsupc++.a
-rwxr-xr-x 1 lucier 1422 Apr 9 14:56 libsupc++.la*
banach-235% ll /pkgs/gcc-3.1/lib/
total 24518
drwxr-sr-x 3 lucier 512 Apr 9 14:48 gcc-lib/
-rw-r--r-- 1 lucier 15612 Apr 9 14:56 libfrtbegin.a
-rw-r--r-- 1 lucier 3047064 Apr 9 14:56 libg2c.a
-rwxr-xr-x 1 lucier 735 Apr 9 14:56 libg2c.la*
lrwxrwxrwx 1 lucier 15 Apr 9 14:56 libg2c.so -> libg2c.so.0.0.0*
lrwxrwxrwx 1 lucier 15 Apr 9 14:56 libg2c.so.0 -> libg2c.so.0.0.0*
-rwxr-xr-x 1 lucier 2792936 Apr 9 14:56 libg2c.so.0.0.0*
lrwxrwxrwx 1 lucier 13 Apr 9 14:48 libgcc_s.so -> libgcc_s.so.1
-rw-r--r-- 1 lucier 793264 Apr 9 14:48 libgcc_s.so.1
lrwxrwxrwx 1 lucier 21 Apr 9 14:48 libgcc_s_sparcv9.so -> libgcc_s_sparcv9.so.1
-rw-r--r-- 1 lucier 827800 Apr 9 14:48 libgcc_s_sparcv9.so.1
-rw-r--r-- 1 lucier 778196 Apr 9 14:57 libiberty.a
-rw-r--r-- 1 lucier 448580 Apr 9 14:57 libobjc.a
-rwxr-xr-x 1 lucier 686 Apr 9 14:57 libobjc.la*
-rw-r--r-- 1 lucier 7940636 Apr 9 14:53 libstdc++.a
-rwxr-xr-x 1 lucier 1193 Apr 9 14:53 libstdc++.la*
lrwxrwxrwx 1 lucier 18 Apr 9 14:53 libstdc++.so -> libstdc++.so.4.0.0*
lrwxrwxrwx 1 lucier 18 Apr 9 14:53 libstdc++.so.4 -> libstdc++.so.4.0.0*
-rwxr-xr-x 1 lucier 7675928 Apr 9 14:53 libstdc++.so.4.0.0*
-rw-r--r-- 1 lucier 666596 Apr 9 14:53 libsupc++.a
-rwxr-xr-x 1 lucier 1105 Apr 9 14:53 libsupc++.la*
drwxr-sr-x 2 lucier 512 Apr 9 14:57 sparcv9/
(BTW, seeing the size of some of these libraries has given me a lot of
ammunition for the next person who says "Yeah, so you can build a Lisp
binary in 20K, how bit are the *libraries*, huh, huh, huh? ;-)
Brad