From: Andreas Jaeger <aj@suse.de>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance
Date: Tue, 18 Sep 2001 20:07:53 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590698805216@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590698805199@msgid-missing>
David Mosberger <davidm@hpl.hp.com> writes:
>>>>>> On Tue, 18 Sep 2001 19:50:52 +0200, Andreas Jaeger <aj@suse.de> said:
>
> >> It turns out that three of the four resulting possibilities make
> >> sense:
> >>
> >> (1) ia64/ilp32 (2) ia64/lp64 (3) x86/ilp32
>
> Andreas> Then we should discuss where those will end. For ia64, the
> Andreas> places are according to the proposal:
>
> Andreas> (1) not defined
> Andreas> (2) /lib and /usr/lib
> Andreas> (3) not defind - but not /lib
>
> (2) is fine, but I think LSB should also (3)---at least for ia64.
> It's important for distributors to agree on the local of (3). The
> current proposal is /emul/ia32-linux.
I agree and will add it to the proposal.
> >> Now, as far as /libXX is concerned: in my opinion, /lib should
> >> contain the "native" or "preferred" library format (primarily for
> >> source compatibility and user convenience reasons). LSB is in
> >> denial if it claims /lib is used for 32-bit libraries only. Both
> >> IA-64 and Alpha use it for 64-bit libraries and if, god forbid,
> >> someone ever added ILP32 support to IA-64 Linux, those libraries
> >> would certainly go into /lib32 or something of that sort. LSB
> >> should consider and accommodate this case.
>
> Andreas> The proposal should just do this - and defines the
> Andreas> "preferred" library format. For both ia64 and Alpha, it's
> Andreas> 64-bit but for PPC64, Sparc64 etc it's 32-bit.
>
> If that's the idea, good. From the description that you quoted, it
> sounded like the "Alpha case" was there solely for historical
> purposes, which would be misleading. /lib should *always* contain the
> "preferred" library format.
But there are the following questions which I hope to get solved:
- what's the preferred format on a platform?
- where will the other formats live?
- where should emulations live?
I'm reworking the proposal tomorrow,
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
next prev parent reply other threads:[~2001-09-18 20:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-18 8:34 [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance Andreas Jaeger
2001-09-18 9:00 ` Theodore Tso
2001-09-18 9:21 ` Luigi Genoni
2001-09-18 9:39 ` Jakub Jelinek
2001-09-18 10:06 ` Jakub Jelinek
2001-09-18 16:33 ` David Mosberger
2001-09-18 16:57 ` Christoph Hellwig
2001-09-18 17:22 ` David Mosberger
2001-09-18 17:50 ` Andreas Jaeger
2001-09-18 19:33 ` David Mosberger
2001-09-18 20:07 ` Andreas Jaeger [this message]
2001-09-18 20:25 ` Christoph Hellwig
2001-09-18 20:47 ` David Mosberger
2001-09-18 20:53 ` David Mosberger
2001-09-18 21:05 ` Joseph V Moss
2001-09-19 6:02 ` Jakub Jelinek
2001-09-19 21:43 ` David Mosberger
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=marc-linux-ia64-105590698805216@msgid-missing \
--to=aj@suse.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.