Summary: | glibc installs incorrect /lib64 directory on ppc64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tom Gall (RETIRED) <tgall> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | VERIFIED WONTFIX | ||
Severity: | blocker | CC: | iamroot, ppc64 |
Priority: | Highest | ||
Version: | 2004.1 | ||
Hardware: | PPC64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Tom Gall (RETIRED)
2004-06-06 17:19:54 UTC
not a toolchain bug any status on this base-system folks? It would appear (on the surface) to be portage based. Especially new versions of portage 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 ... sure I can give that a try ... at the moment I just have newer versions of portage masked off This is working for me with all the latest 2004.2 ... keep this open or close it ? 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. 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. :( 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 2.3.4.20040808, 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 2.3.4.20040808 stable on amd64 until the sandbox fixes make their way into 2.0.50) 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. 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-. Travis, 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. |