Re: Multiarch in Debian unstable
On 06/27/2011 01:54 PM, Steve Langasek wrote:
> currently the only authoritative way to get the multiarch path for a system
> is by calling dpkg-architecture, so many of these patches are not yet
> upstreamable; with the result that some upstream projects now have a hard
> time building on Debian without the addition of Debian patches.
>
> Work is ongoing to formulate a proper, distribution-neutral interface for
> querying the correct multiarch path for a system. In the meantime, if you
> are an upstream affected by this issue, or a maintainer of a package whose
> upstream is affected, you are welcome to join us in discussing these matters
> on debian-devel as well.
I think gcc already provides a way to find out the multiarch directory, so it should be only a matter of patching gcc.
Upstream would then just use gcc -print-multi-os-directory to find out the path (when building with gcc).
For example I currently get this:
On Linux:
$ gcc -print-multi-os-directory
.
$ gcc -print-multi-os-directory -m32
../../lib32
And on Solaris:
$ gcc -print-multi-os-directory
.
$ gcc -print-multi-os-directory -m64
sparcv9
So it should be a matter of changing that to print this instead on Debian multiarch:
$ gcc -print-multi-os-directory
x86_64-linux-gnu
$ gcc -print-multi-os-directory -m32
i486-linux-gnu
(or whatever -m32 will use)
For example of packages that have been using gcc's -print-multi-os-directory since quite some time are:
- ltdl (libtool.m4): to find the runtime search path of the linker
- ClamAV: to automatically install to /usr/lib32 when you compile with -m32
For example here is an GPLv2 m4 macro to "guess" the multilib directory:
http://git.clamav.net/gitweb?p=clamav-devel.git;a=blob;f=m4/acinclude.m4#l844
If gcc was patched to output the correct multiarch directory then no upstream changes would be required for these packages.
Best regards,
--Edwin
Reply to: