Hi, On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote:
> But moving the 32-bit libs to /usr/lib32 does not make us > standards-conformant on amd64, because the FHS (yuckily) standardized on > storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs > in /usr/lib64. That is actually beneficial if we wanted to merge both architectures into one, which would IMO be the sanest thing to do, since it'd allow us to get rid of a lot of special cases (for example, uclibc has a mapping mechanism that finds out if we're building with -m32 on amd64 and uses the config for i386 then, and vice versa -- the entire mechanism could be dropped if we had an unified arch with 32 and 64 bit variants). I am not convinced that using triplets will gain us anything, since a lot of arches have incompatible ABIs without using different triplets for them (IIRC PowerPC has support for big and little endian processes on the same system) Rather, I think we should be using the same names that gcc uses for its multilibs for runtime libraries, and triplets for cross building. These mechanisms are orthogonal, so I can have /usr/arm-linux-gnueabi/lib/thumb as a directory for Thumb libraries. To a certaint extent, multilibs overlap with CPU feature flags, so I wonder if these mechanisms should be unified as well (I'm not even sure there are 64-bit PowerPCs without AltiVec). Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
