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

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: