Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 53177 - glibc installs incorrect /lib64 directory on ppc64
Summary: glibc installs incorrect /lib64 directory on ppc64
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: PPC64 Linux
: Highest blocker (vote)
Assignee: Gentoo Toolchain Maintainers
Depends on:
Reported: 2004-06-06 17:19 UTC by Tom Gall (RETIRED)
Modified: 2004-09-03 20:23 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tom Gall (RETIRED) gentoo-dev 2004-06-06 17:19:54 UTC
First this is a blocking bug for 2004.2 + ppc64.

Here is that situation.

Baselayout creates the following symlinks

/lib64 -> /lib
/usr/lib64 -> /usr/lib

This is done because 80% of applications will correctly use /lib or /usr/lib but there are a couple of them out there that use /lib64 or /usr/lib64.  Since ppc64 is a complete top to bottom 64 bit solution, the solution is easy, create those symlinks, and everyone is happy.  This has been working for 2004.1.

Now trying to create the stages for 2004.2, I have the following situation during the creation of stage1. 

1) baselayout is installed. It correctly creates the /usr/lib64 -> /usr/lib and  /lib64 -> /lib symlinks.

2) glibc is installed. It thinks /lib64 and /usr/lib64 should be directories

Thus the system ends up being:

 drwxr-xr-x   2 root root  4096 Jun  7 17:47 bin
drwxr-xr-x   2 root root  4096 Jun  7 15:47 boot
drwxr-xr-x   5 root root 24576 Jun  7 15:47 dev
drwxr-xr-x  16 root root  4096 Jun  7 17:49 etc
drwxr-xr-x   2 root root  4096 Jun  7 15:47 home
drwxr-xr-x   5 root root  4096 Jun  7 17:49 lib
drwxr-xr-x   2 root root  4096 Jun  7 15:43 lib64
drwxr-xr-x   4 root root  4096 Jun  7 15:47 mnt
drwxr-xr-x   2 root root  4096 Jun  7 15:47 opt
drwxr-xr-x   2 root root  4096 Jun  7 15:47 proc
drwx------   2 root root  4096 Jun  7 15:47 root
drwxr-xr-x   2 root root  4096 Jun  7 17:33 sbin
drwxrwxrwt   2 root root  4096 Jun  7 17:49 tmp
drwxr-xr-x  14 root root  4096 Jun  7 19:06 usr
drwxr-xr-x  11 root root  4096 Jun  7 15:47 var

when it SHOULD be:

drwxr-xr-x    2 root root 4096 Jun  5 13:26 bin
drwxr-xr-x    2 root root 4096 May 20 15:04 boot
drwxr-xr-x    1 root root    0 Dec 31  1969 dev
drwxr-xr-x   27 root root 4096 Jun  7 19:07 etc
drwxr-xr-x    2 root root 4096 May 20 15:04 home
drwxr-xr-x    7 root root 4096 Jun  5 15:05 lib
lrwxrwxrwx    1 root root    3 Jun  5 13:23 lib64 -> lib
drwxr-xr-x    4 root root 4096 May 20 15:04 mnt
drwxr-xr-x    2 root root 4096 May 20 15:04 opt
drwxr-xr-x  117 root root    0 Jun  3 10:20 proc
drwx------    4 root root 4096 Jun  7 19:03 root
drwxr-xr-x    2 root root 4096 Jun  5 13:23 sbin
drwxrwxrwt    2 root root 4096 Jun  6 13:13 tmp
drwxr-xr-x   13 root root 4096 Jun  5 13:23 usr
drwxr-xr-x   12 root root 4096 May 20 22:29 var

Since this worked in 2004.1, I'd like this behavior back otherwise it's going to be impossible to create ppc64 stages.
Comment 1 Travis Tilley (RETIRED) gentoo-dev 2004-06-08 13:30:18 UTC
not a toolchain bug
Comment 2 Tom Gall (RETIRED) gentoo-dev 2004-06-12 06:17:58 UTC
any status on this base-system folks?  It would appear (on the surface) to be portage based. Especially new versions of portage
Comment 3 Martin Schlemmer (RETIRED) gentoo-dev 2004-06-16 12:08:10 UTC
Well, can you verify if its glibc that 'installs' those dirs?  if so,
just do add a 'rm -rf ${D}/lib64 ${D}/usr/lib64' at the end of src_install()
if they are empty.  If not, the contents will obviously have to be moved
to the correct locations.  I cannot test this unfortunately ...
Comment 4 Tom Gall (RETIRED) gentoo-dev 2004-06-19 14:19:49 UTC
sure I can give that a try ... at the moment I just have newer versions of portage  masked off
Comment 5 Philippe Trottier (RETIRED) gentoo-dev 2004-07-04 23:44:50 UTC
This is working for me with all the latest 2004.2 ... keep this open or close it ?
Comment 6 solar (RETIRED) gentoo-dev 2004-07-05 02:38:53 UTC
This is such a hack.. 
lrwxrwxrwx    1 root root    3 Jun  5 13:23 lib64 -> lib

I hope it does not exist this way for all 64bit arches when multilib is set.
Comment 7 Travis Tilley (RETIRED) gentoo-dev 2004-07-05 10:16:29 UTC
solar - this is also the way amd64 has done it since before i even joined. i've been trying to come up with a way to get rid of this disgusting ugly broken -crap-, but any attempt to do so results in a broken install. the linker is expected to be in lib64, so you cant even remove the symlink to make lib64 a normal directory. even if you manage to do so, the 64bit libc is expected to be in /lib thanks to the hack and if there is a 32bit one there, everything /still/ breaks.

at least on amd64, that is. :(
Comment 8 Travis Tilley (RETIRED) gentoo-dev 2004-08-17 21:07:17 UTC
tgall, i wont help you use a broken glibc, but if you want everything in lib you should take a look at the ugly as SIN amd64 nomultilib hack patch. also, baselayout should be properly making those symlinks and portage wont turn symlinks into directories on the live filesystem. i have lib as a symlink and ebuilds install files into lib all the time (though i seek to fix that).

with glibc, amd64 is finally able to get away from that hack patch and make lib64 a real directory... i'm also slowly converting ebuilds to have CONF_LIBDIR support (and thus install libraries to lib64 and not lib). there is also a lib64 sandbox fix in portage 2.0.51_pre which should hopefully make it's way into 2.0.50. baselayout now makes lib a symlink to lib64 for amd64... would you consider something similar for the testing version of the ppc64 port? (note that i dont intend to mark glibc stable on amd64 until the sandbox fixes make their way into 2.0.50)
Comment 9 Tom Gall (RETIRED) gentoo-dev 2004-08-29 19:07:57 UTC
Let me clearly state.

/lib64 is a hack. It is an ugly as sin, yet to be a standard hack. I am amazed that anyone would be as stupid to allow it's use save complete n00bs to unix who are unaware of unix's long and rich history.

Unix is not 32 bit, it's not 64 bit, it's not 16 bit, it's not 128 bit, yet linux runs across diverse architectures. But we don't see /lib16, /lib32 /lib128, so WHY /lib64?  Come on people!

The only story which seemingly justifies such a design point is in the case where you have an architecture which can natively run both. But seriously does anyone REALLY need full 32 and 64 bit installs on their system? Is there really a compelling reason for a 32 and 64 bit version of ls?  

Of course not. 

I'd like to propose we think one through and so the right thing for all uses of gentoo. There are many issues here a good clear implemented design that all agree to I think will go a long way to make sure we as a distro do the right thing. 
Comment 10 Travis Tilley (RETIRED) gentoo-dev 2004-08-31 00:36:22 UTC
if lib isnt used for 32bit on amd64, large numbers of apps wont work properly. adobe acrobat, staroffice, teamspeak, etc. i dont know about you, but i like it when things work. if you feel like causing bugs needlessly, go for it n00b.

also, the fact that you think two full installs are required further shows you have no idea what you're talking about. all of my 32bit compatibility is taking up 51M of diskspace, and that includes a -lot-.
Comment 11 Tom Gall (RETIRED) gentoo-dev 2004-09-03 20:23:51 UTC

I respect your amd64 experiences. However put the bong down. 

When I brought up ppc64 on gentoo, it was painfully obvious that the majority of stuff was going to have major issues if the system only had /lib64. Assuming I left /lib for 32 bit stuff later.  Now maybe you've solved all those issues since last december. I dunno, I'm all ears as to how fundamental things like:

emerge glibc  are support to work in a bi-arch system.

Which glibc?  The 32 bit one? The 64 bit one?  Both?

Or emerge python?  Speically with it's little expectation that only one python is on the system and the winner is only going to link the same number of bit libs.

Look I freely acknowledge you can have a bi-arch system installed. RedHat and SuSE clearly do that. Even you with amd64. But installing compatibility libs is a far cry from a full integrated flexiable system which can equally be used for develment AND running of both architectures at the same time for any J Random ebuild. That's the problem I think together and with all the other bi-arch capabile systems on gentoo we can solve. 

NeXT did this (in a fashion) 10 years ago. We can too.