Bug 439804 – sys-libs/glibc: desync of SYMLINK_LIB settings can break system

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Pacho Ramos 2012-10-26 21:55:47 UTC]

This is the first time I have so much problems when updating my chroot to generate emul packages.

The first issue is that, as soon as glibc is updated from 2.14.1-r3 to 2.15-r3, it fails to run postinst phase and causes a total breakage in chroot, causing any command to fail with:
Too many levels of symbolic links

I have solved it manually running "ldconfig", but later chroot broke again while updating another package (causing all commands to be supposedly unavailable even being still in their proper places) but, until I find the new offending package, would like to notice this major problem.

Reproducible: Always

[Comment 1 Pacho Ramos 2012-10-26 21:57:34 UTC]

Created attachment 327500 [details]
build1.log.bz2

[Comment 2 Pacho Ramos 2012-10-26 21:57:45 UTC]

Created attachment 327502 [details]
build2.log.bz2

[Comment 3 Pacho Ramos 2012-10-26 21:58:39 UTC]

Created attachment 327504 [details]
emerge --info from chroot

[Comment 4 Pacho Ramos 2012-10-27 08:09:45 UTC]

I found the problem, I need to set:
SYMLINK_LIB=yes

I found the problem when seeing baselayout update was the other package causing breakage but, that one, at least showed me the following:
WARN: setup
Your system profile has SYMLINK_LIB=no, so that means you need to
have these paths configured as follows:
directories: /lib /usr/lib
The ebuild will attempt to fix these, but only for trivial conversions.
If things fail, you will need to manually create/move the directories.
Converting /lib from a symlink to a dir
Migrating /lib32 to /lib

Could a similar message be shown when a /lib is a link and SYMLINK_LIB is set to no? I am still surprised I tried to run "ldconfig" to get chroot working again and, if baselayout wouldn't have such message, it would be really difficult to me to find the problem

Thanks

[Comment 5 SpanKY 2012-10-27 09:11:17 UTC]

(In reply to comment #4)

i could probably update multilib.eclass's multilib_env, but i don't see how that'd help here

i also consider messing around with SYMLINK_LIB one of those "you must be this tall to ride" variables ... if you're mucking with it, you get the pieces

[Comment 6 SpanKY 2014-04-04 19:26:10 UTC]

we're killing off SYMLINK_LIB in bug 506276.  i don't think glibc needs to do anything special here ... if you change the value of SYMLINK_LIB and don't adjust your installed paths to match, then stuff will blow up and it isn't specific to glibc.