From: Mike Frysinger <vapier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib
Date: Mon, 26 Oct 2009 08:12:59 -0400 [thread overview]
Message-ID: <200910260813.00341.vapier@gentoo.org> (raw)
In-Reply-To: <4ADEF1BA.1020501@gentoo.org>
[-- Attachment #1: Type: Text/Plain, Size: 1869 bytes --]
On Wednesday 21 October 2009 07:34:18 Michael Haubenwallner wrote:
> Mike Frysinger wrote:
> > On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote:
> >> As I'm building the toolchain myself too, I configure it with the
> >> 32bit host triplet on each platform, usually disabling multilib.
> >
> > this doesnt make any sense to me
>
> What exactly doesn't make sense to you:
it doesnt make sense to build your own toolchain when the default native one
Gentoo provides includes all multilib support already.
but i guess when you're commercially developing a binary-only package, people
tend to not have such freedoms as the binary-only mentality infects all
layers.
> >> Isn't the intention of multilib to have a new (64bit) system
> >> be compatible with the corresponding old (32bit) system?
> >
> > your description of "compatible" is pretty vague. ignoring /lib ->
> > /lib64 symlink (which shouldnt matter to any binaries), i'm not aware of
> > any differences off the top of my head.
>
> Well, "compatible" here means to me that when I do
> $ configure --{build,host}=i686-pc-linux-gnu
assuming you simply forgot the forcing of -m32 here, or you have a fully named
i686-pc-linux-gnu-... toolchain
> on x86-linux, I'd like to expect this working on x86_64-linux too, as the
> "_64" can be seen as an "extension"[1] to x86 I just do not want to use.
>
> It turns out that it is the "/lib resolving to 64bit" thing only that
> causes me headaches here, which actually is distro-specific.
i'm not against changing things to fall in line with what other distros have
settled on (guess that's the risk you take when you're one of the first
distros to do multilib), i just want this kind of decision to be fully
informed / thought out before making it. it's not something i'd label
"trivial".
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2009-10-26 12:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 13:06 [gentoo-dev] RFC: multilib and the compatibility to singlelib Michael Haubenwallner
2009-10-20 14:19 ` [gentoo-dev] " Nikos Chantziaras
2009-10-20 15:29 ` [gentoo-dev] " Thomas Sachau
2009-10-20 16:25 ` [gentoo-dev] " Duncan
2009-10-20 17:45 ` Mike Frysinger
2009-10-20 20:47 ` Jonathan Callen
2009-10-21 1:27 ` Mike Frysinger
2009-10-20 18:16 ` [gentoo-dev] " Mike Frysinger
2009-10-21 11:34 ` Michael Haubenwallner
2009-10-26 12:12 ` Mike Frysinger [this message]
2009-10-27 10:19 ` Michael Haubenwallner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200910260813.00341.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox