FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 06-27-2011, 12:06 PM
Török Edwin
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E087232.4080701@gmail.com">http://lists.debian.org/4E087232.4080701@gmail.com
 
Old 06-27-2011, 12:16 PM
Hector Oron
 
Default Multiarch in Debian unstable

Hello,

2011/6/27 Török Edwin <edwintorok@gmail.com>:
> I think gcc already provides a way to find out the multiarch directory, so it should be only a matter of patching gcc.

Please try not to confuse multiarch with multilibs.
There is also multiarch designation for sparc machines so they use
STT_GNU_IFUNC functions for relocations, nothing to do with what is
proposed here.

Best regards,
--
*Héctor Orón *-.. . -... .. .- -. * -.. . ...- . .-.. --- .--. . .-.

<free spam>
-- Would you like to make a donation for Debian Conference?
* *** http://debconf11.debconf.org/payments.xhtml **
</free spam>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTik_=B=z0C_Kk89NUy5ACAf9UQ-oDw@mail.gmail.com">http://lists.debian.org/BANLkTik_=B=z0C_Kk89NUy5ACAf9UQ-oDw@mail.gmail.com
 
Old 06-27-2011, 01:19 PM
Adam Borowski
 
Default Multiarch in Debian unstable

On Mon, Jun 27, 2011 at 12:16:41PM +0000, Hector Oron wrote:
> 2011/6/27 Török Edwin <edwintorok@gmail.com>:
> > I think gcc already provides a way to find out the multiarch directory,
> > so it should be only a matter of patching gcc.
>
> Please try not to confuse multiarch with multilibs.

What multilib does is allowing use of incompatible modes of the CPU: 32 bit
vs 64 bit, hard float vs soft float, etc. In Debian non-biarch world, this
is done as separate architectures.

I wonder, is there any reason to not reuse -print-multi-os-directory for
multiarch? Doing that has the benefit of being compatible with all but most
ancient versions of gcc.

Using this option for multiarch wouldn't even break its old use:

(amd64)$ gcc -print-multi-os-directory
.
(amd64)$ gcc -print-multi-os-directory -m32
../../lib32

Before the conversion of amd64 -m32 to i386, and sparc -m64 to sparc64, it
could keep using biarch paths for the time being but provide the correct
multiarch one when no -m is specified.

Otherwise, it produces oh so useful:
(amd64)$ arm-linux-gnueabi-gcc -print-multi-os-directory
.


--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110627131953.GA5516@angband.pl">http://lists.debian.org/20110627131953.GA5516@angband.pl
 
Old 06-27-2011, 01:31 PM
Vincent Lefevre
 
Default Multiarch in Debian unstable

Hi,

On 2011-06-27 11:54:53 +0100, Steve Langasek wrote:
> 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.
>
> A summary of currently known upstream compatibility issues, and the status
> of prospective patches for them, can also be found in the Debian wiki here:
>
> http://wiki.debian.org/Multiarch/TheCaseForMultiarch#Impact

Just a comment...

How libraries are searched is not clear, but depending on how this
is done, there may be compatibility issues when the user installs
software in his home directory, in case he or some tool installs
libraries in $prefix/lib instead of $prefix/lib/<arch>.

For instance, if all the default .../lib/<arch> directories have
the precedence over the .../lib directories listed in the user's
$LIBRARY_PATH, bad things can happen. This is the choice followed
by upstream GCC (lib64 directories have the precedence over the
user's lib directories), with the following consequence:

http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html

Related to that, will Linux support fat binaries[*] one day?
If this is possible, where should they be installed, and how
libraries would be searched in a consistent way to support
various kinds of libraries?
[*] containing different architectures, not just sub-architectures.

--
Vincent Lefčvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110627133124.GA16463@prunille.vinc17.org">http://lists.debian.org/20110627133124.GA16463@prunille.vinc17.org
 
Old 06-27-2011, 02:20 PM
Steve Langasek
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110627142023.GE31198@virgil.dodds.net">http://lists.debian.org/20110627142023.GE31198@virgil.dodds.net
 
Old 06-27-2011, 02:42 PM
Steve Langasek
 
Default Multiarch in Debian unstable

On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote:
> On 2011-06-27 11:54:53 +0100, Steve Langasek wrote:
> > 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.

> > A summary of currently known upstream compatibility issues, and the status
> > of prospective patches for them, can also be found in the Debian wiki here:

> > http://wiki.debian.org/Multiarch/TheCaseForMultiarch#Impact

> Just a comment...

> How libraries are searched is not clear, but depending on how this
> is done, there may be compatibility issues when the user installs
> software in his home directory, in case he or some tool installs
> libraries in $prefix/lib instead of $prefix/lib/<arch>.

> For instance, if all the default .../lib/<arch> directories have
> the precedence over the .../lib directories listed in the user's
> $LIBRARY_PATH, bad things can happen. This is the choice followed
> by upstream GCC (lib64 directories have the precedence over the
> user's lib directories), with the following consequence:

> http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html

This particular issue will not occur with multiarch, because /usr/lib/<arch>
will never be a symlink to /usr/lib in the canonical implementation. A user
could do this locally, but there's no good reason to ever do so.

As a practical matter, the runtime path will list all of the multiarch paths
before all of the non-multiarch paths. (It does this already today.) If
nothing else, we do need to list out these directories in /etc/ld.so.conf.d
(because other things parse these files), and it's impractical to have a
different config file for each of the multiarch paths for each architecture.

> Related to that, will Linux support fat binaries[*] one day?

I don't agree that this is related.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110627144246.GF31198@virgil.dodds.net">http://lists.debian.org/20110627144246.GF31198@virgil.dodds.net
 
Old 06-27-2011, 02:59 PM
Simon McVittie
 
Default Multiarch in Debian unstable

On Mon, 27 Jun 2011 at 15:31:24 +0200, Vincent Lefevre wrote:
> Related to that, will Linux support fat binaries[*] one day?

I doubt it; but multiarch doesn't make them any more problematic.

> If this is possible, where should they be installed, and how
> libraries would be searched in a consistent way to support
> various kinds of libraries?

If by "fat binaries" you mean executables, they'd go in ${prefix}/bin just
like normal executables do (under multi-arch or not), and the runtime
linker would have to search the appropriate linker path for whichever
architecture's part of the binary was actually being executed.

(Concrete example: I install an i386/x86-64/armel fat binary on my x86-64.
My kernel can natively execute i386 and x86-64, and it chooses to execute
the x86-64 version. The runtime linker should look in
/usr/local/lib/x86_64-linux-gnu, /usr/local/lib, and so on, in some order,
ignoring any non-x86-64 libraries it finds - but the runtime linker already
knows how to ignore unsuitable libraries, so that's easy.)

If by "fat binaries" you mean shared libraries, they could either go in
/usr/lib, or go in /usr/lib/TUPLE for every appropriate tuple (using hard
links or something). But there's no real advantage in doing that, you could
just as easily install several "thin" libraries.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110627145927.GA25411@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110627145927.GA25411@reptile.pseudorandom.co.uk
 
Old 06-27-2011, 04:31 PM
"Bernhard R. Link"
 
Default Multiarch in Debian unstable

* Steve Langasek <vorlon@debian.org> [110627 13:00]:
> http://wiki.debian.org/Multiarch/Implementation
>
> If you have any questions about the multiarchification of libraries, please
> don't hesitate to ask on debian-devel@lists.debian.org.

Is there anything for nss plugins yet? As plugins for libc one needs to
make sure that if it is installed, it is installed for all installed libcs.
With bi-arch/multilib one can get there by just having it compiled for all
possible variants. Is there any way to not break nss modules with
multiarch?

> Multiarch is a significant departure from the historical directory layout,

It is not really new, it was common in commercial unices. A pity one can
no longer make fun of them.

> A number of upstream build
> systems rely on being able to locate libraries and headers on the filesystem
> at build time, not just using the system compiler's built-in search path.

Please feel free to relay them my "I told you so". Thinking your build
system would know where the files are and that duplicating the code the
preprocessor and linker already have, has been a bad idea in the past
and is still a bad idea now.

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110627163119.GA18093@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110627163119.GA18093@pcpool00.mathematik.uni-freiburg.de
 
Old 06-27-2011, 04:37 PM
Ben Hutchings
 
Default Multiarch in Debian unstable

On Mon, Jun 27, 2011 at 03:19:53PM +0200, Adam Borowski wrote:
[...]
> Before the conversion of amd64 -m32 to i386, and sparc -m64 to sparc64, it
> could keep using biarch paths for the time being but provide the correct
> multiarch one when no -m is specified.
>
> Otherwise, it produces oh so useful:
> (amd64)$ arm-linux-gnueabi-gcc -print-multi-os-directory

Indeed, I saw a complaint from David Miller that building gcc from
upstream source fails at present (on sparc, I assume).

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110627163703.GZ29924@decadent.org.uk">http://lists.debian.org/20110627163703.GZ29924@decadent.org.uk
 
Old 06-27-2011, 10:31 PM
Steve Langasek
 
Default Multiarch in Debian unstable

On Mon, Jun 27, 2011 at 06:31:19PM +0200, Bernhard R. Link wrote:
> * Steve Langasek <vorlon@debian.org> [110627 13:00]:
> > http://wiki.debian.org/Multiarch/Implementation

> > If you have any questions about the multiarchification of libraries, please
> > don't hesitate to ask on debian-devel@lists.debian.org.

> Is there anything for nss plugins yet? As plugins for libc one needs to
> make sure that if it is installed, it is installed for all installed libcs.
> With bi-arch/multilib one can get there by just having it compiled for all
> possible variants. Is there any way to not break nss modules with
> multiarch?

If you care about the nss module being available for all of the
architectures you're running, you simply go through the same process to
convert the nss package to multiarch and install the package for each
architecture. No special handling has been proposed for nss modules beyond
that - though this is already a substantial improvement over the status quo,
where about half our nss modules have biarch versions available and the
other half don't.

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

Thread Tools




All times are GMT. The time now is 04:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org