Ian Lance Taylor <i...@google.com> writes: > Russ Allbery <r...@stanford.edu> writes:
>> The reason, for the record, is because Debian wants to be able to >> support multiarch with more than two architectures. The /lib32 >> vs. /lib64 distinction doesn't allow one to use the same underlying >> machinery to easily install, say, armel library and development >> packages because you're doing development in a cross-compiled >> environment. The general /lib/<triplet> layout allows you to install >> packages from as many different architectures as you desire. > The GNU tools have handled cross-compilation for decades, so I don't > find this answer convincing as stated. Nothing needed to change to make > cross-compilation work. It doesn't have anything to do with the GNU tools or with gcc itself. I agree that this change isn't necessary to make gcc work. It's about package management. The goal is to be able to install the same Debian package for various different architectures on the same system at the same time, and one of the scenarios this helps with is cross development. For example, suppose I'm doing development on an amd64 box targeting armel and I want to use Kerberos libraries in my armel application. I'd like to be able to install the armel Kerberos libraries on my Debian system using regular package management commands, just like any other package. Then I want to have the compiler, when building for armel, find the appropriate armel header files and libraries to link my armel binaries against. The Debian multiarch layout strategy allows this to happen. It's an additional feature that isn't available in the lib32/lib64 model, since that layout doesn't generalize to arbitrary additional architectures. This isn't the only use case, just an example. The embedded Debian folks are very happy with this particular feature, which is why it came to mind. > The lib64 directory does not exist for cross-compilation. It exists > because the kernel supports two different native ABIs. Note there too the lib32/lib64 solution doesn't generalize. What if there is an additional ABI whose distinction isn't the bit size, such as the armhf architecture in Debian where the distinction is support for hardware floating point? Using the triplet offers a general solution to this problem and allows any number of native ABIs. > I strongly support the idea of a compatibility symlink so that older gcc > releases will continue to work. I'm completely agnostic on this point. I only replied to provide the explanation for why Debian chose this layout rather than lib32/lib64. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
