Emerging this portage gets permanently stuck on one of my systems: ./create-localdecls + ./create-localdecls Checking truncate argument type... off_t Checking libc version... libc.so.6 Checking glibc subversion... It seems to be performing this test tmp="`ldd /bin/sh | grep libc.so 2> /dev/null`" However, that test can not succeed here: Green sandbox-1.1 # ldd /bin/sh ldd /bin/sh + ldd /bin/sh not a dynamic executable On another machine, it gives the expected result: cdimage linux # ldd /bin/sh libdl.so.2 => /lib/libdl.so.2 (0x40018000) libc.so.6 => /lib/libc.so.6 (0x4001b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Perhaps there is a more reliable way of finding this information?
Where did your sh come from? Is it a symlink?
The offending sh was installed at this point: 1072750334: *** emerge sync 1072750460: Started emerge on: Dec 29, 2003 19:14:20 1072750460: *** emerge --update --upgradeonly --deep world 1072750536: >>> emerge (2 of 15) app-shells/bash-2.05b-r9 to / 1072750536: === (2 of 15) Cleaning (app-shells/bash-2.05b-r9::/usr/portage/app-shells/bash/bash-2.05b-r9.ebuild) 1072750537: === (2 of 15) Compiling/Merging (app-shells/bash-2.05b-r9::/usr/portage/app-shells/bash/bash-2.05b-r9.ebuild) 1072750697: === (2 of 15) Post-Build Cleaning (app-shells/bash-2.05b-r9::/usr/portage/app-shells/bash/bash-2.05b-r9.ebuild) 1072750699: >>> AUTOCLEAN: app-shells/bash Followed by even more unsuccessful attempts than just this: 1072808750: Started emerge on: Dec 30, 2003 11:25:50 1072808750: *** emerge portage 1072808750: >>> emerge (1 of 1) sys-apps/portage-2.0.49-r19 to / 1072808750: === (1 of 1) Cleaning (sys-apps/portage-2.0.49-r19::/usr/portage/sys-apps/portage/portage-2.0.49-r19.ebuild) 1072808751: === (1 of 1) Compiling/Merging (sys-apps/portage-2.0.49-r19::/usr/portage/sys-apps/portage/portage-2.0.49-r19.ebuild) 1072808872: Started emerge on: Dec 30, 2003 11:27:52 1072808872: *** emerge portage 1072808872: >>> emerge (1 of 1) sys-apps/portage-2.0.49-r19 to / 1072808872: === (1 of 1) Cleaning (sys-apps/portage-2.0.49-r19::/usr/portage/sys-apps/portage/portage-2.0.49-r19.ebuild) 1072808873: === (1 of 1) Compiling/Merging (sys-apps/portage-2.0.49-r19::/usr/portage/sys-apps/portage/portage-2.0.49-r19.ebuild) At which point I emerged bash again by itself 1072848383: Started emerge on: Dec 30, 2003 22:26:23 1072848383: *** emerge bash 1072848383: >>> emerge (1 of 1) app-shells/bash-2.05b-r9 to / 1072848383: === (1 of 1) Cleaning (app-shells/bash-2.05b-r9::/usr/portage/app-shells/bash/bash-2.05b-r9.ebuild) 1072848385: === (1 of 1) Compiling/Merging (app-shells/bash-2.05b-r9::/usr/portage/app-shells/bash/bash-2.05b-r9.ebuild) 1072848512: === (1 of 1) Post-Build Cleaning (app-shells/bash-2.05b-r9::/usr/portage/app-shells/bash/bash-2.05b-r9.ebuild) 1072848513: >>> AUTOCLEAN: app-shells/bash This time though, it seemed to be linked in such a way that the portage script parsed it alright. Though it was after some hassle to find out portage was even looking for "sh" to get the version of something completely unrelated. I would think even awking an emerge -p (or something to that effect) would give a more accurate answer anyway.
right now portage requires bash to never be statically linked (thus /bin/sh is never statically linked) ... normally we would say "if you make a static /bin/sh it's your problem to fix portage" ... but is there any particular reason we cant abuse /usr/include/features.h ? <snip> /* Major and minor version number of the GNU C library package. Use these macros to test for features in specific releases. */ #define __GLIBC__ 2 #define __GLIBC_MINOR__ 2 </snip>
I'm not sure HOW it decided to build itself statically. I made no funky patches to bash or its ebuild or even changed any use flags, least of which being the static flag. The troublesome one was fresh from a emerge sync ; emerge -U --deep world. So, unless there was a change in the last day to bash without a version bump, I can't figure how it managed to get built that way.
portage-2.0.49-r20 should fix this.
