[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: URGENT [PROPOSAL] V3: lsb lib and lsb loader location (alsoIA64)

Stuart Anderson wrote:
> On Thu, 21 Jun 2001, Wichert Akkerman wrote:
> > Previously Johannes Poehlmann wrote:
> > > 1. lsb library location.
> > >
> > >    lsb libraries native for this architecture
> > >    runtime  libraries       ->      /lib/lsb
> > >    Stub  libraries          ->      /usr/lib/lsb-stub
> > >
> > >    IA32 emulation libraries on non IA32 systems (IA64)
> > >    runtime  libraries       ->      /lib/lsb-ia32compat
> > >    Stub      libraries      ->      /usr/lib/lsb-stub-ia32compat
> >
> > Imho this is silly. IA64 can run IA32 binaries natively, and should
> > also be able to run IA32 software unchanged. But since you use
> > /lib/lbs-ia32compat instead of the normal /lib/lsb that isn't possible
> > so you completely break that nice feature of ia64 systems.
> >
> > The same holds for sparc32/sparc64, mips/mips64, powerpc/powerpc64,
> >  and ia32/x86-64.
> Can you please summarize what directories are used to support the different
> architectures? I think that if we see the existing stuff laid out in one place,
> we can see what the pattern is, and where to put lsb version of things should
> be more obvious.

To some extend ths depends on the implementation.

So far, the FHS has suggested {,/usr}/lib<qual>. This means:

     /usr/lib/lsb or /usr/libia64/lsb or /usr/libia32/lsb
     similarly for stub libraries.

The problem occurs when an application:

     o  is pre-linked on an ia32 machine, referencing share objects in /lib, and

     o  is run on an ia64 machine, where share objects are in /lib

To overcome this problem, we can:

     o  suggest dual migration, i.e. currently ia64 machines MUST link against
        /libia64, ia32 machines MUST link against /libia32, machines where /lib
        is the same as /libia64 cannot run binaries linked against /lib meaning
        /libia32. At some time in the future (when ia32 drops off) ia64 binaries
        should be linked against libraries in /lib.

     o  ask for the linker to inspect the object and remove some library 
        directories or libraries from the search path (i.e. satisfy externals
        in programs where main() is of ia32 architecture against ia32 libraries

Since the linker is to some extend architecture dependent, I think the latter is 
the  way to go, it also falls in with "fat" libraries (where modules for different 
architectures, glibc versions etc. of the same name can be in one library).

Remains the question if it is to be /lib-ia62, /libia64 or /lib64. No preference
here from me, although the FHS should contain a list of <qual>s and what they 
mean, this is specifically so for ia64 and the AMD effort (I guess that is what 
was meant by x86-64), both of which are "extensions" to ia32.


*   Why not use metric units and get it right first time, every time ?
*   email: cmaae47 @ imperial.ac.uk
*   voice: +4420-7594-6912 (day)
*   fax:   +4420-7594-6958
*   snail: Thomas Sippel - Dau
*          Linux Services Manager
*          Imperial College of Science, Technology and Medicine
*          The Center for Computing Services
*          Exhibition Road
*          Kensington SW7 2BX
*          Great Britain

Reply to: