[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Multiarch file locations and cross-compilation



Hello.
I'm writing to you as to maintainer of FHS multiarch proposal. 
(http://www.linuxbase.org/futures/ideas/multiarch/)

I'm working on Debian cross-toolchain packages. Recentry, there was a short 
discussion on debian-devel mailing list 
(http://lists.debian.org/debian-devel/2005/07/msg00517.html) about 
placement of files of cross-compilation environment. In that discussion, 
Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> suggested me 
to get in contact with FHS multiarch maintainer with the following issue.

Cross-compilation setup is not the same as multiarch setup: multiarch is 
about running different architecture binaries on the system (and building 
binaries intended to run on the same system), while cross-compilation is 
about building binaries for foriegn architectures, that can't run on the 
build system.
However, both multiarch and cross-compilation setups require of 
installation of libraries and headers for different architectures on the 
same host. So it seems reasonable to use common policies about placing 
those files.

Cross-compilation setups are in wide use for many years, and there is a 
de-facto standard that libs are placed into ${prefix}/${target}/lib, and 
headers are placed into ${prefix}/${target}/include. This convention is 
coded in binutils and gcc packages, as well as in other toolchains.

This differs from what you propose for multiarch (${prefix}/lib/${target} 
ans ${prefix}/include/${target}). Your argument is that you wish to 
prevent /usr pollution.

But it seems that this 'pollution' argument is not strong enough to change 
the way how cross-compilation setups worked for years.

*) The 'pollution' is actually tiny - number of 'arch directories' that 
will appear under /usr will not be larger than number of architectures 
that multiarch system supports - which is probably very small.

*) Having things placed under common prefix makes it easier to create 
chroots, target system images and similar things.

*) Many existing cross-compilation tools work with current setup, and quite 
a lot developers expect things to be this way.

What do you thing about the above?
Isn't it better to make multiarch proposal consistent with de-facto 
standard of cross-compilation setup?

WBR,
Nikita Youshchenko.

Attachment: pgpghq8s3LBob.pgp
Description: PGP signature


Reply to: