Re: Multiarch file locations and cross-compilation
Hello.
> > 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.
>
> Just to nitpick, while ${prefix}/${target}/lib is the defacto standard,
> very few people use /usr/ as the prefix. More likely target libs are
> somewhere under /opt or /home/joedeveloper/acmetools/.
Yes, but AFAIK /opt is used to keep /usr managed by distribution package
management tools (and to avoid conflicts between distribution-installed
files and cross-toolchain files installed from other sources), and /home
is used for user personal (non system-wide) installation.
This is not cross-compilation-specific, but true for almost any package.
When trying to create "distribution-level" cross-compilation toolchain for
debian, I use /usr as prefix.
> Using the crosscompilation scheme for multiarch is inconvinient, because
> then we need two binary packages for each binary lib package - One
> compiled to be used as "native" and to be installed to /usr/lib, and
> one for crosscompilation, installing to /usr/${target}/lib.
I can't agree with this. Set of binaries provided is completely orthogonal
to library and header placement.
Even more - binutils configured for cross target by default create
${prefix}/${arch}/bin/ld, which is the same as ${prefix}/bn/${arch}-ld;
same for other tools - that means, executable for host arch. Same for
other tools.
I'm not aware what for this is done - but it is done, and I've seen
makefiles that depend on this.
> While it is possible to convert packages from first format second using
> some clever hacks, wouldn't it be a lot easier if you could just install
> unmodified target lib .debs with apt-get to the crosscompilation system?
I agree. Tools like 'dpkg-cross -b' are needed only while multiarch is not
implemented in distributions.
However, again, this is not related to library placement.
Nikita
P.S.
I'll reply to the original mail a bit later.
Reply to: