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

Re: Get rid of the lib64 dir?

On 04-May-08 12:39, Stephen Frost wrote:
> * Andreas Jochens (aj@andaco.de) wrote:
> > This could easily be changed to '/lib/ld-linux-x86-64.so.2' or 
> > something else. However, as I understand it, the current 
> Erm, AIUI you'd have to recompile everything if you change the location
> of the interpreter.

If we would not provide a compatibility symlink at the old location, 
we would have to recompile everything. Since there is no 
official archive yet, even that would be possible. I compiled about 
11500 binary packages for 'pure64' and I will recompile them all, if 
this proves to be necessary to support a good solution to the 
'lib64' issue. However, I am not sure about the best solution at 
this moment.

> > FHS/LSB standards require the 64bit program interpreter to be in 
> > '/lib64'. But this will certainly change once the FHS and LSB 
> > implement the multiarch proposal. Maybe we should make a real 
> Erm, that assumes they will.  I wouldn't exactly bet on it. :)

Of course, you are right. However, if Debian implements a good 
working multiarch solution this will certainly make decisions easier.

> > '/lib64' directory (not a symlink to '/lib') with just a symlink to the 
> > program interpreter in it to conform with the standards - at least until 
> > the standards have been adapted to multiarch.
> How does making the actual interpreter a symlink satisfy the standard
> where having the directory symlink'd doesn't?

We could also put the interpreter directly in a real '/lib64' directory 
without any symlinks. This would satisfy the standards. I have tried 
this and it doesn't seem to make any problems in the 'pure64' context.

What solution to the '/lib64' issue would you prefer?

I think we have basically three options at the moment:

1. Make /lib64 a symlink to /lib (and do not install any 32bit libraries)
This is what 'pure64' does now. (Gentoo does the same, so at least we 
would not be alone with this approach).

2. Make /lib64 a real directory and put just the interpreter in it. 
All other libraries go to /lib.

3. Make /lib64 a real directory and put the interpreter in it. 
Compile some things like gcc and libc6 as multilib/biarch and put the 
32bit libraries in /lib and the 64bit libraries in /lib64. All 
other libraries go to /lib.

I do not yet know which of those options would be the best. Maybe we 
should stay with Option 1. which is implemented in 'pure64' now for the 
moment. I think it will be possible to change things later without 
breaking too many things.

Andreas Jochens

Reply to: