This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libgcc_s.so.1 yet again
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