Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Mon, Apr 18, 2005 at 07:54:51AM -0400, Sergey A. Lipnevich wrote:
> Seth,
> 
> Isn't lib64 required by LFS? 

The only place it's mentioned is in a draft of the amd64 ABI standard as 
"however, linux uses..." clause for the dynamic linker executable.  
Every other OS (for some reason) uses one in /lib.

Last I checked FHS specifies /lib is used for the main system (which as 
a pure 64-bit system it would fit).  Both ubuntu and gentoo place them 
in /lib according to sources I've read on the Internet.  Only debian has 
refused, despite the fact that a compatibility link from 
/lib64/ld-linux-x86-64.so.2 to it s partner in /lib is an easy 
workaround for stuff that only expects it in /lib64 and is on both OSs.

If we want 32-bit multilib it can go in /lib32, as well.

> Also, there's always software we can't 
> recompile, such as Oracle database or VMWare, that people will need to 
> run. To make this work, these links will be needed.

Exactly, I figure we'll default to have the compatibility link, for 
example, and have all my stuff be optional.  I personally just don't 
want my spells installed to the wrong places, so I plan on making the 
spells work on either type system where the linker is in either 
location.  Choice, right?

> I don't feel good about this approach in general. I don't suffer from 
> lib64 links. After the procedure described here [1], Benoit's ISO works 
> just fine for me. We have an option to disable multilib build of GCC 
> which works great. I and others contributed fixes to make 64-bit spells 
> work, and having this link was never an issue. I think *not* having it 
> would have been.

You didn't see much because you had the Great Big Symlink.  Yeah, that's 
great for single-arch.  Anything else, and it's potential doom (although 
I suppose you could leave the GBS and use /lib and /ilb64 for 64-bit and 
/lib32 for 32-bit).

Very few spells happen to install to /lib64 by default.  My patches just 
clean up a few.  Perl wasn't even looking in /lib64 for glibc, and is 
actually improved by installing to /lib natively.  My patch for perl 
just makes it look in /lib64 instead.  Granted, the GB /lib64 to 
/lib Symlink fixes that, but why not make perl flexible enough to be 
used on multilib systems?

I'm at the same time helping make it so you can have separate 
directories with different binaries in /lib and /lib64 or /lib and 
/lib32 so that you can have a decent multilib system later.  In order to 
do this though the Great Big Symlink would be best to go.

That's at least how I'm looking at it.  If it's not a good idea, I'm not 
beholden to it, though.

Seth

> Why is having these links such a big deal?
> Thanks,
> 
> Sergey.
> 
> [1] http://wiki.sourcemage.org/index.php?page=AMD64+Status
> 
> Seth Alan Woolley wrote:
> 
> >I've recently been working on getting the amd64 port to be all in /lib 
> >without a /lib64 symlink (and /usr/lib{,64}).  I've succeeded but will 
> >have to make it easy for people to convert before I apply the various 
> >patches I've written.
> >
> > 
> >
> 

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737  F2FF 7A3F 6D3C 00BA 3AF3
Security Team Member Source Mage GNU/Linux http://www.sourcemage.org
Elected Coordinating Committee Member, Pacific Green Party of Oregon

Attachment: pgppsGaPj6mfl.pgp
Description: PGP signature