[Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Andreas Jaeger]

George, you forgot to add the appended part.  Especially the paragraph
is important that this will not imply a binary incompatible change for
ia64, ia64 has an emulation for 32-bit binaries but is not a real
32/64-bit platform like Sparc64, x86-64, PPC64 and S390.

David, does this satisfy your ia64 concerns?

Andreas

3. Recommendations

   We recommend the use of /lib64 to contain the 64bit
   libraries on multi-library capable 64bit Linux ports and a
   /lib which isn't a symbolic link but a real directory to
   contain 32bit libraries for the following reasons:

   * existing 32bit applications will install with rpm directly
     and run without a change in a 64bit system (zSeries and
     sparc64 today)

   * rpm is known to fail on nested symlinks within in pathes
     on updating those directories; therefore /lib should not
     be a link to /lib32.

   * dedicated directory structure for a 32bit subsystem does
     not integrate smoothly into the existing FHS / (root)
     directory structure. FHS today does not allow new
     directories below / (root). Possible options would be
     /opt/emu32, /usr/emu32 ... rpm needs to install
     accordingly, too, but will not work with todays versions
     (this could be achieved with intelligent wrapper scripts
     analysing the target system but this does not reflect a
     generic approach). Addtional problems might show up since
     /opt might not be available when booting up the system.

   * existing commercial binary-only applications like
     middleware and applications are and might only be
     available as 32-bit binaries for the time being due to
     porting efforts and quality assurance cycles.

   * exisiting binary executable code generating tool chain
     (gcc, binutils, glibc) already are capable to handle the
     /lib64 approach

   * /lib: consistent scheme for all 32bit systems and x86-64,
     sparc64, ppc64, zSeries (s390x).

   * iA64 today has a 32bit emulation mode, but 64bit is the
     (only) favored one; Alpha is too long established. (64bit
     libs will go to /lib)

   * only few applications or middleware will benefit from full
     64bit support in general (databases, ERP systems,
     applications using large memory caches for speed, numeric
     intense applications, ...)

   * 32bit applications tend to have a smaller memory footprint
     due code/data alignment in physical memory, thus total
     memory usage is more efficient on large systems with
     multiple Linux system instances (iSeries, zSeries)

   * compiler and toolchain can be used to build 32-bit
     applications on a 64-bit architecture; they can be
     transferred to 32-bit architecture hardware (cross
     development with tested executables) without further
     changes.

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Theodore Tso]

On Tue, Sep 18, 2001 at 10:34:50AM +0200, Andreas Jaeger wrote:
> 
>    * /lib: consistent scheme for all 32bit systems and x86-64,
>      sparc64, ppc64, zSeries (s390x).
> 
>    * iA64 today has a 32bit emulation mode, but 64bit is the
>      (only) favored one; Alpha is too long established. (64bit
>      libs will go to /lib)
> 

Does Sparc/Ultrasparc use /lib and /lib64?  Or will this be a change
for the Ultrasparc platform?

						- Ted

[Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Luigi Genoni]

On Tue, 18 Sep 2001, Theodore Tso wrote:

> Date: Tue, 18 Sep 2001 05:00:50 -0400
> From: Theodore Tso <tytso@mit.edu>
> To: Andreas Jaeger <aj@suse.de>
> Cc: fhs-discuss@ucsd.edu, linux-ia64@linuxia64.org,
>      lsb-spec@lists.linuxbase.org, Brad_Brech/Rochester/IBM@de.ibm.com,
>      jporell@us.ibm.com, Michael_Day/Austin/IBM@de.ibm.com,
>      Ron_Clark/Austin/IBM@de.ibm.com, George_Kraft/Austin/IBM@de.ibm.com,
>      Paul_McKenney/Beaverton/IBM@de.ibm.com,
>      Kenneth_Rozendal/Austin/IBM@de.ibm.com,
>      Satya_Sharma/Austin/IBM@de.ibm.com, ADLUNG@de.ibm.com, dbb@caldera.com,
>      mkraft@suse.de, David Mosberger <davidm@hpl.hp.com>
> Subject: Re: PROPOSED: 32/64 bit coexistance
> Resent-Date: Tue, 18 Sep 2001 11:02:12 +0200
> Resent-From: lsb-spec@lists.linuxbase.org
>
> On Tue, Sep 18, 2001 at 10:34:50AM +0200, Andreas Jaeger wrote:
> >
> >    * /lib: consistent scheme for all 32bit systems and x86-64,
> >      sparc64, ppc64, zSeries (s390x).
> >
> >    * iA64 today has a 32bit emulation mode, but 64bit is the
> >      (only) favored one; Alpha is too long established. (64bit
> >      libs will go to /lib)
> >
>
> Does Sparc/Ultrasparc use /lib and /lib64?  Or will this be a change
> for the Ultrasparc platform?
Actually userspace for ultrasparc is only 32 bits, there is a 64 bit
compiler for the kernel, I think, but I've never seeen 64 bits libraries
except the ones inside of /usr/lib/gcc-lib/<sprac>/<egcs-xxx>.

Luigi

[Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Jakub Jelinek]

On Tue, Sep 18, 2001 at 05:00:50AM -0400, Theodore Tso wrote:
> On Tue, Sep 18, 2001 at 10:34:50AM +0200, Andreas Jaeger wrote:
> > 
> >    * /lib: consistent scheme for all 32bit systems and x86-64,
> >      sparc64, ppc64, zSeries (s390x).
> > 
> >    * iA64 today has a 32bit emulation mode, but 64bit is the
> >      (only) favored one; Alpha is too long established. (64bit
> >      libs will go to /lib)
> > 
> 
> Does Sparc/Ultrasparc use /lib and /lib64?  Or will this be a change
> for the Ultrasparc platform?

Linux/SPARC uses /lib and /lib64 (dynamic linkers /lib/ld-linux.so.2 and
/lib64/ld-linux.so.2), at least glibc has this in (including /usr/include
headers which are correct for both 32bit and 64bit ports by looking
at preprocessor flags (this is what <bits/wordsize.h> is for, and 
magic /usr/include/asm/BuildASM script which creates asm header stubs from
<asm-sparc/*.h> and <asm-sparc64/*.h> headers)), likewise for gcc (the
default dynamic linker for -m64 is there /lib64/ld-linux.so.2; RHL gcc rpm
even contains patch which changes the -m32 resp. -m64 default based on
whether gcc is running in sparc32(8) compatibility environment, so if one
runs sparc32 /bin/sh and in there types ./configure; make, he'll get 32bit
programs, doing the same outside of sparc32 children will result in 64bit
programs (or libraries)), binutils. But as Red Hat SPARC distribution is in
a bad shape (I'm trying to resurrect it at least a little bit in my spare
time during last week), the 64bit stuff consists just of 64bit glibc, gcc,
libtermcap, gdb) there. I think Debian or SuSE folks have played with 64bit
userland too and might get further, though if I remember Debian folks used
to oppose this /lib and /lib64 scheme when I started using it for sparc64
and wanted to do something else.

	Jakub

[Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Jakub Jelinek]

On Tue, Sep 18, 2001 at 11:21:57AM +0200, Luigi Genoni wrote:
> Actually userspace for ultrasparc is only 32 bits, there is a 64 bit
> compiler for the kernel, I think, but I've never seeen 64 bits libraries
> except the ones inside of /usr/lib/gcc-lib/<sprac>/<egcs-xxx>.

Not true:
ldd ./iconv
        libc.so.6 => /lib64/libc.so.6 (0xfffff80000120000)
        /lib64/ld-linux.so.2 => /lib64/ld-linux.so.2 (0xfffff80000000000)
I can put up the rpms somewhere (but as I said, since %multilib support is
broken in rpm ATM, the only way to install this stuff and keep your 32bit
glibc is to unpack it manually).
But so that SPARC 64bit userland is widely used, this means somebody needs
to a) fix rpm or deal somehow with this in dpkg, b) package 64bit libs/apps
up (this may at least for rpm involve some macroizing of spec files where
needed), c) if gcc crashes/miscompiles something (similarly if ld or gas breaks),
send testcases (note that sparc64 is only supported by gcc-2.96-RH, gcc 3.1
CVS head or gcc 3.0.x with SUBREG_BYTE patch).

	Jakub

[Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[David Mosberger]

>>>>> On Tue, 18 Sep 2001 10:34:50 +0200, Andreas Jaeger <aj@suse.de> said:

  Andreas> George, you forgot to add the appended part.  Especially
  Andreas> the paragraph is important that this will not imply a
  Andreas> binary incompatible change for ia64, ia64 has an emulation
  Andreas> for 32-bit binaries but is not a real 32/64-bit platform
  Andreas> like Sparc64, x86-64, PPC64 and S390.

  Andreas> David, does this satisfy your ia64 concerns?

To be honest, I think the description is confusing and incomplete.
This is because it doesn't clearly distinguish between code model and
data model.  On ia64, there are presently two code models (x86 and
ia64) and two data models (ILP32 and LP64).  It turns out that three
of the four resulting possibilities make sense:

  (1) ia64/ilp32
  (2) ia64/lp64
  (3) x86/ilp32

In the future, there could be others.  For example, I'm pretty sure
that Alpha->ia64 binary translators are in the process of being
written and on a Compaq system, it could make sense to have
"alpha/lp64", for example.

I think LSB is correct in suggesting /libXX for the native code model
and "something" else for emulated code models.  /opt/emu32 is clearly
a silly name though: it mixes up the data model and the code model
again.  For the IA-64 Linux project, we're currently using
/emul/ia32-linux for the IA-32 subsystem.  (If there is strong
objection and good reasons to reject the "/emul" prefix, I suppose we
could use /opt/emu/ia32-linux/ instead.)

A related question is whether /emul/ is reserved for "same OS"
emulation.  E.g., where would a Windows emulator go?  If /emul/ only
ever contains Linux emulators, then we could change the prefix to
/emul/ia32/ but, from a user perspective, I think it would be
preferable if /emul/ were allowed to contain foreign OS emulators as
well.

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.

Thanks,

	--david

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Christoph Hellwig]

On Tue, Sep 18, 2001 at 09:33:11AM -0700, David Mosberger wrote:
> I think LSB is correct in suggesting /libXX for the native code model
> and "something" else for emulated code models.  /opt/emu32 is clearly
> a silly name though: it mixes up the data model and the code model
> again.  For the IA-64 Linux project, we're currently using
> /emul/ia32-linux for the IA-32 subsystem.  (If there is strong
> objection and good reasons to reject the "/emul" prefix, I suppose we
> could use /opt/emu/ia32-linux/ instead.)

Don't put it in /opt.  For something like a binray emulator /opt
is just silly.

Currently mips and sparc use /usr/gnemul/<opsys>, Linux-ABI for ix86
uses /emul/<opsys>.  I'd suggest going for one of those, possibly
the latter (:)).

> A related question is whether /emul/ is reserved for "same OS"
> emulation.  E.g., where would a Windows emulator go?  If /emul/ only
> ever contains Linux emulators, then we could change the prefix to
> /emul/ia32/ but, from a user perspective, I think it would be
> preferable if /emul/ were allowed to contain foreign OS emulators as
> well.

It does.  On Linux-ABI I use e.g. /emul/osr5, /emul/uw7 and /emul/svr4.
Id suggest using /emul/<opsys> for emulations of another operating
system for the same architecture, /emul/<arch>-<opsys> for non-native.

Windows should go into /emul/win64 and /emul/ia32-win32.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[David Mosberger]

>>>>> On Tue, 18 Sep 2001 18:57:15 +0200, Christoph Hellwig <hch@ns.caldera.de> said:

  Christoph> It does.  On Linux-ABI I use e.g. /emul/osr5, /emul/uw7
  Christoph> and /emul/svr4.  Id suggest using /emul/<opsys> for
  Christoph> emulations of another operating system for the same
  Christoph> architecture, /emul/<arch>-<opsys> for non-native.

  Christoph> Windows should go into /emul/win64 and /emul/ia32-win32.

Sounds reasonable.  /emul/ia32-linux should be it, then.

	--david

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Andreas Jaeger]

David Mosberger <davidm@hpl.hp.com> writes:

>>>>>> On Tue, 18 Sep 2001 10:34:50 +0200, Andreas Jaeger <aj@suse.de> said:
>
>   Andreas> George, you forgot to add the appended part.  Especially
>   Andreas> the paragraph is important that this will not imply a
>   Andreas> binary incompatible change for ia64, ia64 has an emulation
>   Andreas> for 32-bit binaries but is not a real 32/64-bit platform
>   Andreas> like Sparc64, x86-64, PPC64 and S390.
>
>   Andreas> David, does this satisfy your ia64 concerns?
>
> To be honest, I think the description is confusing and incomplete.
> This is because it doesn't clearly distinguish between code model and
> data model.  On ia64, there are presently two code models (x86 and
> ia64) and two data models (ILP32 and LP64).  It turns out that three
> of the four resulting possibilities make sense:
>
>   (1) ia64/ilp32
>   (2) ia64/lp64
>   (3) x86/ilp32
>
> In the future, there could be others.  For example, I'm pretty sure
> that Alpha->ia64 binary translators are in the process of being
> written and on a Compaq system, it could make sense to have
> "alpha/lp64", for example.

Then we should discuss where those will end.  For ia64, the places are
according to the proposal:
(1) not defined
(2) /lib and /usr/lib
(3) not defind - but not /lib



> I think LSB is correct in suggesting /libXX for the native code model
> and "something" else for emulated code models.  /opt/emu32 is clearly
> a silly name though: it mixes up the data model and the code model
> again.  For the IA-64 Linux project, we're currently using
> /emul/ia32-linux for the IA-32 subsystem.  (If there is strong
> objection and good reasons to reject the "/emul" prefix, I suppose we
> could use /opt/emu/ia32-linux/ instead.)
>
> A related question is whether /emul/ is reserved for "same OS"
> emulation.  E.g., where would a Windows emulator go?  If /emul/ only
> ever contains Linux emulators, then we could change the prefix to
> /emul/ia32/ but, from a user perspective, I think it would be
> preferable if /emul/ were allowed to contain foreign OS emulators as
> well.
>
> 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.

The proposal should just do this - and defines the "preferred" library
format.  For both ia64 and Alpha, it's 64-bit but for PPC64, Sparc64
etc it's 32-bit.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[David Mosberger]

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

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

	--david

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Andreas Jaeger]

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

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Christoph Hellwig]

On Tue, Sep 18, 2001 at 10:07:53PM +0200, Andreas Jaeger wrote:
> 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.

Would you mind adding my extended version, i.e.

	/emul/[<arch>-]<opsys>

for non-native trees?

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[David Mosberger]

>>>>> On Tue, 18 Sep 2001 22:25:01 +0200, Christoph Hellwig <hch@ns.caldera.de> said:

  Christoph> Would you mind adding my extended version, i.e.

  Christoph> 	/emul/[<arch>-]<opsys>

  Christoph> for non-native trees?

That would be good.  It might also be good to explicitly state that
these trees are expected to follow the filesystem layout conventions
of the emulated environment (to the degree that this makes sense).
For example, you could assume that there would be:

	/emul/ia32-linux/etc/ld.so.conf
	/emul/ia32-linux/lib
	/emul/ia32-linux/usr/lib

Thanks,

	--david

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[David Mosberger]

>>>>> On Tue, 18 Sep 2001 22:07:53 +0200, Andreas Jaeger <aj@suse.de> said:

  Andreas> But there are the following questions which I hope to get
  Andreas> solved:
  Andreas> - what's the preferred format on a platform?
  Andreas> - where will the other formats live?
  Andreas> - where should
  Andreas> emulations live?

Yes, these need to be answered, though it shouldn't be hard.  For
ia64, I think the answers would be:

	preferred format: lp64
	other formats:	  undefined (may want to mention that ia64 UNIX ABI
			  specifies /lib32 for ilp32; there are no plans to
			  support this under Linux)
	emulations:	  /emul/[<arch>-]<opsys> in general,
			  /emul/ia32-linux for the specific case of Linux/i386

Thanks,

	--david

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Joseph V Moss]

> >>>>> On Tue, 18 Sep 2001 18:57:15 +0200, Christoph Hellwig <hch@ns.caldera.de> said:
> 
>   Christoph> It does.  On Linux-ABI I use e.g. /emul/osr5, /emul/uw7
>   Christoph> and /emul/svr4.  Id suggest using /emul/<opsys> for
>   Christoph> emulations of another operating system for the same
>   Christoph> architecture, /emul/<arch>-<opsys> for non-native.
> 
>   Christoph> Windows should go into /emul/win64 and /emul/ia32-win32.
> 
> Sounds reasonable.  /emul/ia32-linux should be it, then.

I'm not so sure.  Should the architecture name be 'ia32'?  The linux kernel
and other things have normally referred to it as 'i386' (or any of i[3456]86 in
some cases).

Personally, I'd prefer the 'ia32' name, if for no other reason than to avoid
the problems associated with my parenthetical remark in the last paragraph.

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[Jakub Jelinek]

On Tue, Sep 18, 2001 at 01:47:12PM -0700, David Mosberger wrote:
> That would be good.  It might also be good to explicitly state that
> these trees are expected to follow the filesystem layout conventions
> of the emulated environment (to the degree that this makes sense).
> For example, you could assume that there would be:
> 
> 	/emul/ia32-linux/etc/ld.so.conf

Why ld.so.conf? /etc/ld.so.conf should be enough when ldconfig handles
multiple ABI libraries.

> 	/emul/ia32-linux/lib
> 	/emul/ia32-linux/usr/lib

	Jakub

Re: [Linux-ia64] Re: PROPOSED: 32/64 bit coexistance

[David Mosberger]

>>>>> On Wed, 19 Sep 2001 02:02:35 -0400, Jakub Jelinek <jakub@redhat.com> said:

  Jakub> On Tue, Sep 18, 2001 at 01:47:12PM -0700, David Mosberger
  Jakub> wrote:
  >> That would be good.  It might also be good to explicitly state
  >> that these trees are expected to follow the filesystem layout
  >> conventions of the emulated environment (to the degree that this
  >> makes sense).  For example, you could assume that there would be:
  >> 
  >> /emul/ia32-linux/etc/ld.so.conf

  Jakub> Why ld.so.conf? /etc/ld.so.conf should be enough when
  Jakub> ldconfig handles multiple ABI libraries.

I think there is a choice.  You could do it either way (theoretically
at least).  From a user perspective, it's probably better to have just
/etc/ld.so.conf.

	--david