Bug#420667: libc6 breaks bash, renders all compiles unusable
David Baron a écrit :
> On Tuesday 24 April 2007, Aurelien Jarno wrote:
>> David Baron a écrit :
>>> On Tuesday 24 April 2007, Aurelien Jarno wrote:
>>>> David Baron a écrit :
>>>>> Package: libc6
>>>>> Version: 2.5-2
>>>>> Severity: critical
>>>>> Justification: breaks unrelated software
>>>>>
>>>>> 1. Upgrade -- balks at symlinks in /usr/lib, asks user to remove them.
>>>>> BAD BAD BAD!
>>>> What do you mean exactly? Could you please give us the output messages?
>>> I have downgraded because more things became broken and a lot of
>>> dependencies are shot. The message was to the effect:
>>> Duplicate library found .... unsafe to upgrade .... remove, then try
>>> again. The libraries sited were symlinks on /usr/ib
>>> frist libc.so.0.6, then libdl.so.2, ehtn librt.so.1 (if I remember
>>> correctly)
>> You should never have such libraries in /usr/lib. No Debian package
>> install the glibc libraries in /usr/lib, their place is in /lib,
>> otherwise expect the problem you encountered.
>>
>> This is therefore not a bug of the glibc package, but a problem of your
>> system. Closing the bug.
>>
>>>>> 2. Once these removed, installs. Bash is now unusable--problem is in
>>>>> calls from bashrc, bash.bashrc, et al. bash -norc, sh (not login) work.
>>>> Well I don't really understand what did you removed. Anyway bash should
>>>> work correctly, even with /usr/lib removed.
>>> I removed the symlinks requested for removal above.
>>> Bash using its rc files no longer worked.
>>> Without the rcfiles,as I stated, worked as non-login mode.
>>> bash -norc or sh.
>>>
>>>>> 3. The libc.so.6 synlink it kicked at is replaced. Reinstall will again
>>>>> balk.
>>>> Which file exactly? Could you give us the full path.
>>> Those cited above.
>>>
>>>>> 4. The other symlinks are needed by ld when building dependent
>>>>> programs! 5. Once replaced, builds procede but all built programs
>>>>> segfault.
>>> Note that I did not simply remove anyting but moved it. First I took off
>>> from /lib which of course was catastrohpic. I restored those ans was able
>>> to reboot. That is why I say that the script should not ask users to
>>> remove anything like that. What must be removed/replaced should be done
>>> by the script and this should be thoroughly tested before posting,
>>> obviously. This is unstable, ok, but not experimental.
>> Wrong. No package put glibc libraries in /usr/lib. If a user does that,
>> it is his/her responsability to take care of those files.
>
> However, 2.5.2 certainly did do so. Maybe the older ones I had there should
> not have been but once I took them out, they should not have reappeared!
Wrong again. It's ldconfig which recreate them because you have a copy
of the glibc in /usr/lib. This is not new for glibc 2.5-2, its the case
since ldconfig exists...
Try 'rm -f /usr/lib/*-2.3.6.so'. Again you should not have a copy of the
glibc in /usr/lib (*-2.3.6.so files). BAD BAD BAD!
> 2.3.6.... does not put a libc.so symlink in /usr/lib but does place symlinks
> for librt, libdl.
>
> Note that if the symlinks are absent, ld will fail looking for them but this
> could be a path problem.
.so symlinks are needed for ld, but .so.X are not needed and only create
problems as you experienced.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: