public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Haubenwallner <haubi@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] RFC: multilib and the compatibility to singlelib
Date: Tue, 20 Oct 2009 15:06:29 +0200	[thread overview]
Message-ID: <4ADDB5D5.30502@gentoo.org> (raw)

Hi devs,

while there is the appreciated multiple ABI portage support going on,
a thought on the intentions of the multilib profiles.

Some background:
I do have to support building an older, but still maintained large
application software, that simply does not work when built as 64bit.
As it does not have the need itself for >32bit pointers, and all
the 64bit target platforms do support 32bit binaries too, the plan
to fix the code for 64bits has been cancelled.

I'm using gcc to build the application on all the target unices,
as well as autotools for build management.

As I'm building the toolchain myself too, I configure it with the
32bit host triplet on each platform, usually disabling multilib.

This simply works for ppc-aix, hppa-hpux, ia64-hpux, sparc-solaris,
x86-solaris, even if the underlying OS/kernel is 64bit.
It isn't even necessary to explicitly use --{build,host} at all,
as config.guess tells the 32bit triplet on these platforms.
Additionally, even their default compiler output is 32bit.

But Linux "is not Unix":
Configuring both binutils and gcc needs to be done with:
  $ CC="gcc -m32" /path/to/configure --{build,host}=i686-pc-linux-gnu ...
This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /lib,
64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux.

Problem is that, as x86-linux isn't a multilib target, both ld and gcc
search for 32bit libs&objects in /usr/lib:/lib, as they don't know about
/usr/lib32:/lib32. The error when bootstrapping gcc is:
  /usr/lib/crti.o: file not recognized: File format not recognized

While it is possible to patch binutils[1] and gcc[2] to search in
/usr/lib32:/lib32 even with this otherways non-multilib target,
it doesn't feel like the "right thing" to enable multilib for
just one multilib option.

Isn't the intention of multilib to have a new (64bit) system
be compatible with the corresponding old (32bit) system?

Please comment, thank you!
/haubi/

[1] http://overlays.gentoo.org/proj/alt/changeset/51324
[2] http://overlays.gentoo.org/proj/alt/changeset/51325




             reply	other threads:[~2009-10-20 13:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-20 13:06 Michael Haubenwallner [this message]
2009-10-20 14:19 ` [gentoo-dev] Re: RFC: multilib and the compatibility to singlelib 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
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=4ADDB5D5.30502@gentoo.org \
    --to=haubi@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