Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: First of all, RHL, RHEL and FC are the only distros I know that do not have /usr/local/lib entry in /etc/ld.so.conf file! Always, after fresh installation first thing that I do is to add such line there. The new problem is that in FC3 SELinux does not allow ldconfig to handle libraries installed there properly. At first, I was installing tarball libraries that way: ./configure make setenforce 0 make install ldconfig setenforce 1 Unfortunately, after installation of few libraries, setenforce 0 didn't help to run ldconfig properly anymore! I had to disable SELinux completly on my desktop PC, but it can be real problem if I run FC3 on server. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Download any tarball with library 2. configure, make and install it 3. run ldconfig Actual Results: ldconfig writes error messages (If you're working on X, look at dmesgs to see that it's because of SELinux activity) Expected Results: Proper behavior Additional info:
/usr/local/lib not in /etc/ld.so.conf is on purpose. As for the SELinux related problems, this is because the libraries aren't system_u:object_r:shlib_t as they ought to, but root:object_r:lib_t or something like that. Certainly restorecon /usr/local/lib/lib*.so* ought to fix this, but whether and why you need to run this is something selinux policy maintainers need to answer.
SELinux does not handle the labeling of shared libraries installed or copied/moved outside of RPM. File contexts will default to the context of the directory they are installed into. So in this case they are defaulting to lib_t. The only thing that you can do is do a restorecon after the install to set them to the proper security context of shlib_t. (You could also use chcon which is similar to chmod. but often restorecon is easier.) Dan