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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110627142023.ge31...@virgil.dodds.net
