libgcc_s.so.1 yet again

libgcc_s.so.1 yet again

[Brad Lucier]

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?

Brad

PS:  Here is what file gives me.

banach-23% file /pkgs/gcc-3.1v9/lib/libgcc_s.so.1
/pkgs/gcc-3.1v9/lib/libgcc_s.so.1:      ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped
banach-24% file /pkgs/gcc-3.1/lib/libgcc_s.so.1
/pkgs/gcc-3.1/lib/libgcc_s.so.1:        ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped

Re: libgcc_s.so.1 yet again

[Jeff Sturm]

On Mon, 11 Feb 2002, Brad Lucier wrote:
> 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.

For the same architecture, yes.

> 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 instead of using the biarch feature (which takes care of the libgcc
naming) you are building and installing gcc into a separate ${prefix} for
each of 32 and 64-bit compilation?

> So is there any way to build libgcc so that it is usable with either
> 64-bit or 32-bit applications on sparc?

I'd guess you could set LD_LIBRARY_PATH_64, which will be ignored by the
32-bit loader.

Jeff

Re: libgcc_s.so.1 yet again

[Brad Lucier]

> > 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 instead of using the biarch feature (which takes care of the libgcc
> naming) you are building and installing gcc into a separate ${prefix} for
> each of 32 and 64-bit compilation?

I'm building and testing both 64-bit and 32-bit builds of the compiler,
each of which can generate 64-bit or 32-bit code.

> > So is there any way to build libgcc so that it is usable with either
> > 64-bit or 32-bit applications on sparc?
> 
> I'd guess you could set LD_LIBRARY_PATH_64, which will be ignored by the
> 32-bit loader.

Thanks, this looks like what I need.

Brad

Re: libgcc_s.so.1 yet again

[Geoff Keating]

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.

> Brad
> 
> PS:  Here is what file gives me.
> 
> banach-23% file /pkgs/gcc-3.1v9/lib/libgcc_s.so.1
> /pkgs/gcc-3.1v9/lib/libgcc_s.so.1:      ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped
> banach-24% file /pkgs/gcc-3.1/lib/libgcc_s.so.1
> /pkgs/gcc-3.1/lib/libgcc_s.so.1:        ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped
> 

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: libgcc_s.so.1 yet again

[Rainer Orth]

Brad Lucier <lucier@math.purdue.edu> writes:

> > So instead of using the biarch feature (which takes care of the libgcc
> > naming) you are building and installing gcc into a separate ${prefix} for
> > each of 32 and 64-bit compilation?
> 
> I'm building and testing both 64-bit and 32-bit builds of the compiler,
> each of which can generate 64-bit or 32-bit code.

I find it very unfortunate how the multilibbed libgcc_s.so is handled,
compared to other multilibs:

For a (bi-arch) sparc-sun-solaris2.8 gcc 3.1, there will be

	$slibdir/libgcc_s.so.1			ELF32
	$slibdir/libgcc_s_sparcv9.so.1		ELF64

while a bi-arch sparcv9-sun-solaris2.8 gcc 3.1 has

	$slibdir/libgcc_s.so.1			ELF64
	$slibdir/libgcc_s_sparcv7.so.1		ELF32

even though the ELF32 libgcc_s.so.1 and libgcc_s_sparcv7.so.1 and the ELF64
libgcc_s.so.1 and libgcc_s_sparcv9.so.1 libs are identical.

I'd consider it much more useful if (like all other multilibs do, and
following the lead of Solaris system libraries) we had (for both
configurations)

	$slibdir/libgcc_s.so.1			ELF32
	$slibdir/sparcv9/libgcc_s.so.1		ELF64

I'd consider this arrangement much more natural: it's consistent with both
vendor and other gcc multilib handling and would even allow sparc and
sparcv9 configurations to share a common $prefix (provided that
ELF64/sparcv9 multilibs) were stored in sparcv9 subdirs, even for a sparcv9
configuration.

	Rainer

Re: libgcc_s.so.1 yet again

[Bo Thorsen]

On Monday 11 February 2002 23:51, Rainer Orth wrote:
> Brad Lucier <lucier@math.purdue.edu> writes:
> > > So instead of using the biarch feature (which takes care of the libgcc
> > > naming) you are building and installing gcc into a separate ${prefix}
> > > for each of 32 and 64-bit compilation?
> >
> > I'm building and testing both 64-bit and 32-bit builds of the compiler,
> > each of which can generate 64-bit or 32-bit code.
>
> I find it very unfortunate how the multilibbed libgcc_s.so is handled,
> compared to other multilibs:
>
> For a (bi-arch) sparc-sun-solaris2.8 gcc 3.1, there will be
>
> 	$slibdir/libgcc_s.so.1			ELF32
> 	$slibdir/libgcc_s_sparcv9.so.1		ELF64
>
> while a bi-arch sparcv9-sun-solaris2.8 gcc 3.1 has
>
> 	$slibdir/libgcc_s.so.1			ELF64
> 	$slibdir/libgcc_s_sparcv7.so.1		ELF32
>
> even though the ELF32 libgcc_s.so.1 and libgcc_s_sparcv7.so.1 and the ELF64
> libgcc_s.so.1 and libgcc_s_sparcv9.so.1 libs are identical.
>
> I'd consider it much more useful if (like all other multilibs do, and
> following the lead of Solaris system libraries) we had (for both
> configurations)
>
> 	$slibdir/libgcc_s.so.1			ELF32
> 	$slibdir/sparcv9/libgcc_s.so.1		ELF64

No, go all the way:

	$slibdir/$arch1/libx
	$slibdir/$arch2/libx
	...

With your proposal, the problem is the same as if it's in the name. With this 
scheme, it's for sparc this would be

	$slibdir/sparcv7/libgcc_s.so.1
	$slibdir/sparcv9/libgcc_s.so.1
	$slibdir/sparcv10?/libgcc_s.so.1

no matter which sparc it's compiled on. Especially for the architectures 
where the 32 bit architecture can compile to 64 bit (only sparc so far, 
x86-64 will maybe also do this), this would be nice.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: libgcc_s.so.1 yet again

[Rainer Orth]

Bo Thorsen writes:

> > I'd consider it much more useful if (like all other multilibs do, and
> > following the lead of Solaris system libraries) we had (for both
> > configurations)
> >
> > 	$slibdir/libgcc_s.so.1			ELF32
> > 	$slibdir/sparcv9/libgcc_s.so.1		ELF64
> 
> No, go all the way:
> 
> 	$slibdir/$arch1/libx
> 	$slibdir/$arch2/libx
> 	...

No, this is both unnecessary and against current practice, compared both to
how non-libgcc multilibs are installed by gcc (i.e. the default multilib in
$slibdir, others in appropriate subdirs) and vendor practice.  Moving the
default multilibs to a subdir just creates confusion for the users
(especially if they need to handle this change when either setting
LD_LIBRARY_PATH or passing -R/-rpath) with no real gain.

> no matter which sparc it's compiled on. Especially for the architectures 
> where the 32 bit architecture can compile to 64 bit (only sparc so far, 
> x86-64 will maybe also do this), this would be nice.

Right, but its not only SPARC/Solaris 7+: MIPS/IRIX 6 is in the same boat
with the N32 and N64 ABIs.

	Rainer

Re: libgcc_s.so.1 yet again

[Jakub Jelinek]

On Tue, Feb 12, 2002 at 04:02:48PM +0100, Rainer Orth wrote:
> > no matter which sparc it's compiled on. Especially for the architectures 
> > where the 32 bit architecture can compile to 64 bit (only sparc so far, 
> > x86-64 will maybe also do this), this would be nice.
> 
> Right, but its not only SPARC/Solaris 7+: MIPS/IRIX 6 is in the same boat
> with the N32 and N64 ABIs.

Well, slightly different, since SPARC/Solaris uses /lib/libfoo.so.* and
/lib/sparcv9/libfoo.so.* while Irix uses /lib/libfoo.so.*,
/lib64/libfoo.so.*, /libn32/libfoo.so.* (which is what SPARC Linux uses as
well).

	Jakub

Re: libgcc_s.so.1 yet again

[Rainer Orth]

Jakub Jelinek writes:

> > Right, but its not only SPARC/Solaris 7+: MIPS/IRIX 6 is in the same boat
> > with the N32 and N64 ABIs.
> 
> Well, slightly different, since SPARC/Solaris uses /lib/libfoo.so.* and
> /lib/sparcv9/libfoo.so.* while Irix uses /lib/libfoo.so.*,
> /lib64/libfoo.so.*, /libn32/libfoo.so.* (which is what SPARC Linux uses as
> well).

Indeed (only that its /lib32/libfoo.so.* for the N32 ABI), but I really
dislike this scheme since it doesn't match the GNU coding standards (only a
single lib dir), creates platform specific maintenance hassle
(e.g. special-casing three different libdirs on IRIX) and doesn't match
the established practice of using subdirs for non-default multilibs.

	Rainer

Re: libgcc_s.so.1 yet again

[Bo Thorsen]

On Tuesday 12 February 2002 20:50, Rainer Orth wrote:
> Jakub Jelinek writes:
> > > Right, but its not only SPARC/Solaris 7+: MIPS/IRIX 6 is in the same
> > > boat with the N32 and N64 ABIs.
> >
> > Well, slightly different, since SPARC/Solaris uses /lib/libfoo.so.* and
> > /lib/sparcv9/libfoo.so.* while Irix uses /lib/libfoo.so.*,
> > /lib64/libfoo.so.*, /libn32/libfoo.so.* (which is what SPARC Linux uses
> > as well).
>
> Indeed (only that its /lib32/libfoo.so.* for the N32 ABI), but I really
> dislike this scheme since it doesn't match the GNU coding standards (only a
> single lib dir), creates platform specific maintenance hassle
> (e.g. special-casing three different libdirs on IRIX) and doesn't match
> the established practice of using subdirs for non-default multilibs.

It is the way it's done on multiarch platforms:

[sledgehammer:/] # ll */libc*
-rwxr-xr-x    1 root     root      1384168 Sep 20  2001 lib/libc.so.6
-rwxr-xr-x    1 root     root     14646840 Feb 13  2002 lib64/libc-2.2.5.so
lrwxrwxrwx    1 root     root           13 Feb 13  2002 lib64/libc.so.6 -> 
libc-2.2.5.so

If you can come up with a way to have both a 32 and 64 bit libc.so.6 on the 
system without a lib64 or something equivalent, I'd like to hear about it.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: libgcc_s.so.1 yet again

[Rainer Orth]

Bo Thorsen writes:

> It is the way it's done on multiarch platforms:
> 
> [sledgehammer:/] # ll */libc*
> -rwxr-xr-x    1 root     root      1384168 Sep 20  2001 lib/libc.so.6
> -rwxr-xr-x    1 root     root     14646840 Feb 13  2002 lib64/libc-2.2.5.so
> lrwxrwxrwx    1 root     root           13 Feb 13  2002 lib64/libc.so.6 -> 
> libc-2.2.5.so
> 
> If you can come up with a way to have both a 32 and 64 bit libc.so.6 on the 
> system without a lib64 or something equivalent, I'd like to hear about it.

I don't object to the `something equivalent' part, but specificially to
lib{32, 64} parallel to lib: this solution gets unwieldly too fast,
especially if you consider platforms with more multilibs.  Thus my proposal
to keep the status quo with the default multilib in lib, and others in
subdirs of lib instead of separate lib<something> hierarchies.

And please treat libgcc_s in the same way as all other libraries, instead
of encoding the multilib variant in the library name in this one case only.

	Rainer

Re: libgcc_s.so.1 yet again

[Brad Lucier]

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