Re: Multiarch in Debian unstable
On Mon, Jun 27, 2011 at 03:06:10PM +0300, Török Edwin wrote:
> 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
There are certain implementation difficulties with this proposal. The
multi-os-directory printed by gcc is always a *relative* path with respect
to the "base" lib directory; and in a multiarch directory, this base lib
directory *is* the multiarch directory (for the primary toolchain target).
So this:
> 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
would definitely be wrong, because neither
/usr/lib/x86_64-linux-gnu/x86_64-linux-gnu nor
/usr/lib/x86_64-linux-gnu/i486-linux-gnu will exist. Correct would be '.'
and '../i486-linux-gnu', but that's of little help if one doesn't know what
it's relative to in the first place!
It could be done instead with absolute paths, but that's still a semantic
change for gcc and consumers of this may not be expecting the change.
> 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
Heh, that's not at all a correct method of querying the runtime search path
of the linker.
> If gcc was patched to output the correct multiarch directory then no
> upstream changes would be required for these packages.
A number of upstream changes would still be required in order for these
packages to *use* the gcc -print-multi-os-directory output.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: