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.
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.
