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

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

	$slibdir/			ELF32
	$slibdir/sparcv9/		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


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