Daniel Jacobowitz wrote: > On Sat, Oct 15, 2005 at 07:35:39PM -0700, Josh Triplett wrote: >>(such as powerpc64), because the contents are in lib64 directories and >>the include files are in alternate locations as well. > > The include files nowadays are in /usr/include/<biarch>, so no. It > would only need to know about /lib64.
Actually, I was misremembering the behavior of dpkg-cross; I thought it
ignored subdirectories under include directories, but it just ignores
subdirectories under lib directories.
>>Furthermore, it is not clear how it should convert these packages. If
>>the architecture string were to be believed, it should stick the files
>>in the same arch directory under /usr as the standard libraries for that
>>architecture; however, the architecture string is in fact misleading,
>>and the files should be put in the directory under /usr corresponding to
>>the alternate architecture.
>
> Why? A good motto for cross compilers is that they should be as much
> as possible like the corresponding native compilers. The native
> compiler knows /usr/lib and /usr/lib64; the cross compiler should know
> /usr/i486-linux-gnu/lib and /usr/i486-linux-gnu/lib64.
>
> Or just update to the current year, and use ..../usr/lib and
> ..../usr/lib64, and --with-sysroot, in which case just about everything
> becomes easier.
That does indeed sound like a better alternative, since library package
contents could just be moved wholesale from / to /usr/$ARCH/ . It also
means that dpkg-cross doesn't have to care whether GCC is looking for
/usr/$ARCH/usr/lib64 or /usr/$OTHERARCH/usr/lib ; it can just convert
packages naively.
This would, however, require some reworking of dpkg-cross and the cross
support in the GCC package. It sounds like the ideal solution for
cross-compilation, though.
Just out of curiosity, is it possible to provide multiple sysroots, such
that the resulting gcc looks in (for example) /usr/${ARCH1}-linux-gnu
for -march=(something in the $ARCH1 family) and /usr/${ARCH2}-linux-gnu
for -march=(something in the $ARCH2 family) ?
>>In the ideal case, with long-term work on dpkg and dpkg-cross to support
>>multiple architectures, it might be possible to just make use of the
>>binary packages for the alternate architecture, rather than needing
>>hacks like "libc6-dev-powerpc64" and "libc6-dev-amd64". It might also
>>be possible to hack dpkg-cross to deal with such hacks in the meantime.
>
> dpkg-cross should presumably not diverge from what dpkg does, and today
> dpkg uses libc6-dev-amd64.
Hence "ideal case" and "long-term work". I'm just referring to what
I've heard about the plans for dpkg multiple-architecture handling in
the future, and I wasn't suggesting that dpkg-cross should change before
dpkg does.
>>However, at the moment, this patch makes it possible to build at least a
>>plain cross-compiler for such architectures.
>
> I think it's worth doing it correctly.
I agree. However, I also think it's worth having something that works
in the meantime; at the moment, it is not possible to use dpkg-cross and
the cross-compiler support in the current GCC source package to build a
Debian-packaged cross-compiler for any architecture currently using
biarch support. This patch does fix that problem; I'd certainly love to
see a better fix which makes use of --with-sysroot as you suggest.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
