When I made stage1 on PPC64 using catalyst newly, baselayout did not make symlink. I make with stage2 and stage3 continuously, and I have noticed libstdc++-v3 failing in compile. I think that this problem occurred since it did not make symlink. I'll attach the patch which solves this problem. Thanks. Reproducible: Always Steps to Reproduce: 1. catalyst -C target=snapshot version_stamp=20051020 2. catalyst -C target=stage1 source_subpath=default/stage3-ppc64-64ul-2005.1 version_stamp=20051020 snapshot=20051020 subarch=ppc64-64ul rel_type=default profile=default-linux/ppc/2005.1/ppc64/64bit-userland 3. cd /var/tmp/catalyst/tmp/default/stage1-ppc64-64ul-20051020/tmp/stage1root 4. ls -ld lib* 5. ls -ld usr/lib* Actual Results: # ls -ld lib* drwxr-xr-x 5 root root 192 Oct 20 14:21 lib drwxr-xr-x 3 root root 2016 Oct 20 14:21 lib64 # ls -ld usr/lib* drwxr-xr-x 7 root root 176 Oct 20 14:20 usr/lib drwxr-xr-x 6 root root 3496 Oct 20 14:12 usr/lib64 drwxr-xr-x 4 root root 96 Oct 20 14:05 usr/libexec Expected Results: # ls -ld lib* lrwxrwxrwx 1 root root 5 Oct 22 22:33 lib -> lib64 drwxr-xr-x 5 root root 2128 Oct 22 22:36 lib64 # ls -ld usr/lib* lrwxrwxrwx 1 root root 5 Oct 22 22:33 usr/lib -> lib64 drwxr-xr-x 10 root root 3592 Oct 22 22:36 usr/lib64 drwxr-xr-x 4 root root 96 Oct 22 22:35 usr/libexec
Created attachment 71199 [details, diff] patch for baselayout-1.11.13-r1.ebuild
Created attachment 71200 [details, diff] patch for profiles/default-linux/packages.build
Created attachment 71243 [details, diff] patch for baselayout-1.11.13-r1.ebuild new patch creates lib64 directory appropriately in ppc64's 64bit-userland profile.
Alright boys and girls. This is being upgraded to a blocker because it *will* keep both PPC64 and AMD64 from building the 2006.0 release, which we have already started working on initial QA testing. What do I need to do to get this expedited?
there is nothing binary about dev-state and udev-state...
sorry, I read through this too quick... try this fix:
Created attachment 74852 [details, diff] baselayout-1.11.14.ebuild.diff
That should work. Go ahead and commit it. --Dan
Your patch did not solve this problem... I think that the cause of this problem is the following. * get_all_libdirs in multilib.eclass returns not lib64 but lib. Therefore, /usr/lib64 is not made. * mkdirs.sh is performed ahead of mklinks.sh by pkg_postinst in baselayout.ebuild, and Symbolic Link (/lib -> /lib64) cannot be created. [note] ppc64's 64bit-userland profile has the feature of amd64's no-multilib profile. Thanks for your help.
result of `ACCEPT_KEYWORDS=~ppc64 ROOT='/tmp/baselayout' USE='build' emerge --nodeps '=baselayout-1.11.14'` # ls -ld /tmp/baselayout/lib* drwxr-xr-x 4 root root 112 Dec 17 04:44 /tmp/baselayout/lib drwxr-xr-x 3 root root 104 Dec 17 04:44 /tmp/baselayout/lib64 # ls -ld /tmp/baselayout/usr/lib* lrwxrwxrwx 1 root root 5 Dec 17 04:44 /tmp/baselayout/usr/lib -> lib64
Any word on this? We are planning on freezing the snapshot for 2006.0 soon and this is currently the only real showstopper bug.
Created attachment 76098 [details, diff] multilib.eclass.patch sorry, I was away on vacation. Please try this patch to multilib.eclass, and ping me on IRC so we can get this resolved...
Created attachment 76163 [details, diff] patch for baselayout-1.11.13-r1.ebuild eradicator, Thanks for your patch. The problem which /usr/lib64 is not created was solved. But, Symbolic Link (/lib --> /lib64) cannot be created. Because, /lib directory is created before the work which creates Symbolic Link. I attach the new patch which avoids this problem.
Ok, the multilib.eclass patch is committed, and the ebuilds have been patched.
reopening... The problem is not solved. eradicator, Would you apply my patch (Attachment 76163 [details, diff]) to baselayout.ebuild ? kdir function creates the list of directories to create. And directories are actually created in pkg_postinst. It is unsolvable even if it moves the kdir command in src_install...
Created attachment 76929 [details, diff] patch for profiles/default-linux/packages.build In addition, please apply the patch to package.build. This workaround patch fixes the problem on which python-2.4.x installs files in /usr/lib. However, I have noticed that this patch is not good. Isn't there any idea which solves the problem of python ? Thank you.
add deps on bug #118805 (python problem bug)
Removing dependency since packages.build isn't the realm of baselayout and doesn't belong here. base-system, can you think of any reason why we can't move baselayout first in packages.build until bug 108608 and bug 108805 are resolved?
Created attachment 77267 [details, diff] baselayout-1.11.14.ebuild patch This patch is against baselayout-1.11.14.ebuild and works for me on amd64...
I've added my patch (minus the KEYWORDS stuff) to CVS w/ permission of eradicator... Thanks to everyone involved... =]
