Bug 188551 - After upgrade to FC5 can not login with normal level users under X till ld.so.conf is fixed
After upgrade to FC5 can not login with normal level users under X till ld.so...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-10 23:12 EDT by Jeff Means
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-12 04:35:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Means 2006-04-10 23:12:29 EDT
Description of problem:
After upgrading to FC5 I can not login as a unprivledged user due to the
standard libraries not being found as they are not listed in /etc/ld.so.conf or
/etc/ld.so.conf.d/*

Version-Release number of selected component (if applicable):
FC5

How reproducible:
Two upgrades later (1 i386 and 1 x86_64) same behaviour.

Steps to Reproduce:
1. Run a upgrade off CD from FC4
2. Try to login as a non-privledged user
3. Get an error message about shared library not found
  
Actual results:
When logging in you will get an error message about shared libraries not found

Expected results:
Login sucessful.

Additional info:
Attaching the following to the end of /etc/ld.so.conf would solve the problem...
/lib
/usr/lib
/usr/X11R6/lib
Comment 1 Karsten Hopp 2006-04-11 05:16:29 EDT
/lib and /usr/lib are automatically searched, adding these directories to
/etc/ld.so.conf  doesn't change anything.
The directory /usr/X11R6/lib doesn't exist in FC5, if you still have files in
there, you need to find out to which packages they belong and update them:
find /usr/X11R6/lib -type f | xargs rpm -qf 

So your problem most probably is that not all of your packages have been updated
and you need to find out why. But this definitely isn't a libtool problem,
libtool is a program which is used when you're compiling sources into binaries
and has nothing to do with ld.so.conf
Comment 2 Jeff Means 2006-04-12 03:46:12 EDT
Ok I have done as asked and found that only my nVidia driver lives in the
directory that no longer exists... However I am still having interesting
problems with libraries not being found, any sugestions would be much apreciated.

-- Screen clip --
[root@jeff-w ~]# /usr/local/Zend/ZendStudioClient-5.1.0/bin/ZDE
awk: error while loading shared libraries: libdl.so.2: cannot open shared object
file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared
object file: No such file or directory
/bin/ls: error while loading shared libraries: librt.so.1: cannot open shared
object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared
object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared
object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared
object file: No such file or directory
grep: error while loading shared libraries: libc.so.6: cannot open shared object
file: No such file or directory
/usr/local/Zend/ZendStudioClient-5.1.0/jre/bin/java: error while loading shared
libraries: libpthread.so.0: cannot open shared object file: No such file or
directory
[root@jeff-w ~]# find / -name libdl.so.2
/lib/libdl.so.2

[root@jeff-w ~]# find / -name libc.so.6
/lib/i686/nosegneg/libc.so.6
/lib/libc.so.6

[root@jeff-w ~]# find / -name libpthread.so.0
/lib/i686/nosegneg/libpthread.so.0
/lib/libpthread.so.0

[root@jeff-w ~]#
-- end Screen clip --

As you can see these files do exist and are in the correct places to be searched
automatically (right?)
Comment 3 Jeff Means 2006-04-12 04:35:05 EDT
Found a solution: it involves the LD_ASSUME_KERNEL work around.

Solution:
in /etc/rc.d/rc.local or in your ~/.bashrc set
unset LD_ASSUME_KERNEL

Note You need to log in before you can comment on or make changes to this bug.