This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: yet again

On Monday 11 February 2002 23:51, Rainer Orth wrote:
> Brad Lucier <> 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 is handled,
> compared to other multilibs:
> For a (bi-arch) sparc-sun-solaris2.8 gcc 3.1, there will be
> 	$slibdir/			ELF32
> 	$slibdir/		ELF64
> while a bi-arch sparcv9-sun-solaris2.8 gcc 3.1 has
> 	$slibdir/			ELF64
> 	$slibdir/		ELF32
> even though the ELF32 and and the ELF64
> and 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/			ELF32
> 	$slibdir/sparcv9/		ELF64

No, go all the way:


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


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 Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]