Re: libgcc_s.so.1 yet again

[Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>]

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