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. > 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. > 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. > 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. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]