From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: lib64 in fedora glibc
Date: Fri, 04 Jun 2004 04:58:48 +0000 [thread overview]
Message-ID: <16576.392.754663.498730@napali.hpl.hp.com> (raw)
In-Reply-To: <20040528214105.GK9115@mustard.zk3.dec.com>
>>>>> On Tue, 01 Jun 2004 11:48:56 +0200, Andreas Jaeger <aj@suse.de> said:
Andreas> Just a clarification: AMD64 [1] has most of user space
Andreas> 64-bit. Only a few applications are 32-bit - but this
Andreas> lib/lib64 is the best way to handle 32-bit packages (no
Andreas> need to change files).
>> Moving to lib32 and lib64 makes sense in that environment.
Andreas> Not lib32, just lib.
That may be a reasonable solution for x86-64 but I don't think it is
for ia64. What's needed is multi-architecture support, not bi-arch
support. Let's consider some possible bi-arch setups:
contents of:
host arch: /usr/lib /usr/lib64
----------
x86-64 x86 x86-64
ia64 x86 ia64
ppc64 ppc32 ppc64
So far, so good. But what if x86-64 emulation support were added to
Intel's IA32EL? With the bi-arch-logic, that's either not supported
or you'd have to move the ia64-stuff _again_ from /usr/lib64 into some
other place. Thanks, but no thanks. Not to mention that trying to
move ia64 libraries from /usr/lib to /usr/lib64 is almost certainly
worse than any ill it could possibly cure.
Even if you didn't in the above scenario, it wouldn't surprise me if
the ppc64 folks also wanted to be able to run x86 binaries. If so,
the bi-arch approach won't work for them either, because /usr/lib is
already taken by ppc32.
--david
next prev parent reply other threads:[~2004-06-04 4:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-28 21:41 lib64 in fedora glibc Aron Griffis
2004-05-28 22:14 ` David Mosberger
2004-05-29 3:33 ` Aron Griffis
2004-05-29 5:21 ` Grant Grundler
2004-06-01 9:48 ` Andreas Jaeger
2004-06-04 4:58 ` David Mosberger [this message]
2004-06-04 5:08 ` Andreas Jaeger
2004-06-04 6:21 ` David Mosberger
2004-06-04 8:16 ` Christoph Hellwig
2004-06-04 19:23 ` Bill Nottingham
2004-06-04 20:14 ` David Mosberger
2004-06-04 20:21 ` Bill Nottingham
2004-06-04 22:15 ` David Mosberger
2004-06-07 20:05 ` Saxena, Sunil
2004-06-07 20:09 ` Bill Nottingham
2004-06-07 21:06 ` Andreas Schwab
2004-06-07 21:18 ` Bill Nottingham
2004-06-07 21:58 ` Andreas Schwab
2004-06-07 22:14 ` Bill Nottingham
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=16576.392.754663.498730@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=linux-ia64@vger.kernel.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