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

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

And on Solaris:
$ gcc -print-multi-os-directory
$ gcc -print-multi-os-directory -m64

So it should be a matter of changing that to print this instead on Debian multiarch:
$ gcc -print-multi-os-directory
$ gcc -print-multi-os-directory -m32

(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:

If gcc was patched to output the correct multiarch directory then no upstream changes would be required for these packages.

Best regards,

Reply to: