ldconfig will not link /usr/local/lib

Hey Everyone,

Getting back into FreeBSD after 2 years of Linux (feels good to be back!!). I've got a problem though. It seems that the system cannot see the libraries in /usr/local/lib.

lbconfig -r properly displays all the linked libraries and I've tried every way I can think of to manually add /usr/local/lib. But applications keep throwing errors indicating they cannot be found when run as anyone but root. Moving the libraries to another ldconfig monitored directory, like /lib/, solves the problem but it is by no means an elegant solution (especially as i still have more programs to compile).

Any help would be greatly appreciated,

DarkenedReality
 
The result of the comparison are:
Code:
#mtree -de -f /etc/mtree/BSD.local.dist -p /usr/local && echo OK
OK
#

Sorry for the Lack of information yesterday, i was running out the door.

Here's the standard error it gives me when trying to access almost any program with shared libraries as a regular user:
Code:
$startx
/libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth"
/libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth"
/libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth"
/libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth"
/libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth"
/libexec/ld-elf.so.1: Shared object "libX11.so.6" not found, required by "xinit"
/libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth"
Code:
$bash
/libexec/ld-elf.so.1: Shared object "libintl.so.6" not found, required by "bash"
Even though ldconfig shows them:
Code:
#ldconfig -r | grep libXau.so.6
       270:-lXau.6 => /usr/local/lib/libXau.so.6
#ldconfig -r | grep libX11
       178:-lX11.6 => /usr/local/lib/libX11.so.6
#ldconfig -r | grep libintl
       178:-lintl.8 => /usr/local/lib/libintl.so.8

.... and it only seems to happen with the /usr/local/lib directory.
 
You need to rebuild bash, it was build with an older version of libintl.

This might be the problem with the other libraries too. If you update anyone of them you need to rebuild everything that depends on it.
 
Ok, so you installed via ports and no obvious reasons for normal users to not see the libraries.

As your normal user, can you run:
ldd -a `which xauth`

Also, might you have umask other then 022 as root user?
 
Just Xau.so.6? Please show output, like:
Code:
$ ldd -a `which xauth`
/usr/local/bin/xauth:
        libXau.so.6 => /usr/local/lib/libXau.so.6 (0x38083000)
        libXext.so.6 => /usr/local/lib/libXext.so.6 (0x38086000)
        libXmuu.so.1 => /usr/local/lib/libXmuu.so.1 (0x38094000)
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x38097000)
        libc.so.7 => /lib/libc.so.7 (0x38184000)
/usr/local/lib/libXau.so.6:
        libc.so.7 => /lib/libc.so.7 (0x38184000)
/usr/local/lib/libXext.so.6:
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x38097000)
        libXau.so.6 => /usr/local/lib/libXau.so.6 (0x38083000)
        libc.so.7 => /lib/libc.so.7 (0x38184000)
/usr/local/lib/libXmuu.so.1:
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x38097000)
        libc.so.7 => /lib/libc.so.7 (0x38184000)
/usr/local/lib/libX11.so.6:
        libXau.so.6 => /usr/local/lib/libXau.so.6 (0x38083000)
        libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x38286000)
        librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x3828b000)
        libc.so.7 => /lib/libc.so.7 (0x38184000)
/usr/local/lib/libXdmcp.so.6:
        libc.so.7 => /lib/libc.so.7 (0x38184000)
/usr/lib/librpcsvc.so.4:
        libc.so.7 => /lib/libc.so.7 (0x38184000)
 
sorry about that, here it is:
Code:
$ ldd -a `which xauth`
/libexec/ld-elf.so.1: Shared object "libXau.so.6" not found, required by "xauth"

usage: ldd [-a] [-v] [-f format] program ...
$
 
And that makes no sense.

Code:
$ sudo mv /usr/local/lib/libXau.so.6 /tmp/
Password:

$ ldd -a `which xauth`
/usr/local/bin/xauth:
        libXau.so.6 => not found (0x0)
        libXext.so.6 => /usr/local/lib/libXext.so.6 (0x38083000)
        libXmuu.so.1 => /usr/local/lib/libXmuu.so.1 (0x38091000)
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x38094000)
        libc.so.7 => /lib/libc.so.7 (0x38181000)
/usr/local/lib/libXext.so.6:
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x38094000)
        libXau.so.6 => not found (0x0)
        libc.so.7 => /lib/libc.so.7 (0x38181000)
/usr/local/lib/libXmuu.so.1:
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x38094000)
        libc.so.7 => /lib/libc.so.7 (0x38181000)
/usr/local/lib/libX11.so.6:
        libXau.so.6 => not found (0x0)
        libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x38283000)
        librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x38288000)
        libc.so.7 => /lib/libc.so.7 (0x38181000)
/usr/local/lib/libXdmcp.so.6:
        libc.so.7 => /lib/libc.so.7 (0x38181000)
/usr/lib/librpcsvc.so.4:
        libc.so.7 => /lib/libc.so.7 (0x38181000)

Are you attempting to use xauth at the moment by X11 forwarding over ssh? I can't think of anything else that would cause this broken behavior...
Hmm, or are your quotes translated wrongly...
Try instead:
ldd -a /usr/local/bin/xauth
 
And the plot thickens:
Code:
$ldd -a /usr/local/bin/xauth
/usr/local/bin/xauth:
        libXau.so.6 => not found (0x0)
        libXext.so.6 => not found (0x0)
        libXmuu.so.1 => not found (0x0)
        libX11.so.6 => not found (0x0)
        libc.so.7 => /lib/libc.so.7 (0x800639000)
$
and again,the same command run as root wields the proper dependent libraries and sub-dependent libraries (as in your previous example). I'm not trying to tunnel X11 over SSH. I think reformatting may be in order.......
 
I've tried some scenarios (perm on /var/run/ld*.hints, removing exec bit on libs), but the only one that reproduces this is having no read permission on /usr/local/lib/libXau.so.6.

if you can confirm that, we just need to figure out why that is...umask isn't, so I'd need to see the line that installs a library. If we stick to libXau.so.6 for the time being:
Code:
pkg_delete -f libXau*
make -C /usr/ports/x11/libXau clean install
ls -al $(make -C /usr/ports/x11/libXau -V WRKSRC)/.libs
 
The permissions on libXau.so.6 is 755. But I seem to have stumbled over a bigger problem when i went to re-install the port anyway:
Code:
#pkg_delete -f libXau*
pkg_delete: No match.
#pkg_info: libXau*
pkg_info: No match.
#man pkg_info 
No manual entry for pkg_info
#pkg_info | grep libXau
libXau-1.0.4       Authentication Protocol library for X11

Are there any know bugs with using ZFS that would account for this weird behavior? I've set up other system with ZFS and haven't seen this happen. Otherwise I think I'll just start over, I just wanted to know what would cause this.
 
I'm just going to reformat and re-install (my servers been down for far too long; though the question of "why?" will still haunt me for awhile). Thanks Mel for all your help. Hopefully this doesn't repeat itself.
 
I understand, sometimes the why is less important. I haven't seen anything like this, and since things like man pkg_info aren't even working either, I can only assume disk and/or memory corruption.
I highly doubt that if ZFS had a shortage of memory, it would return ENOENT for valid paths.
 
I am having a similar issue with libintl.so.6, but I am trying to run apache. I manually compile my apache1.3.41 and php5.2.10, and have done so.

This all started when I did a portmaster upgrade.

I was receiving similar errors as apache before rebuilding php5, but now it is fine (able to run php -i again)

When I try to start apache:

Code:
Syntax error on line 5 of /var/apache/conf/httpd.conf:
Cannot load /var/apache/libexec/libphp5.so into server: Shared object "libintl.so.6" not found, required by "libphp5.so"
/var/apache/bin/apachectl startssl: httpd could not be started

server has been down all day so I am kind of reaching for ideas here.

Code:
# ldconfig -r | grep libintl
        256:-lintl.8 => /usr/local/lib/libintl.so.8
 
tekkitan said:
I am having a similar issue with libintl.so.6, but I am trying to run apache. I manually compile my apache1.3.41 and php5.2.10, and have done so.

This all started when I did a portmaster upgrade.

I was receiving similar errors as apache before rebuilding php5, but now it is fine (able to run php -i again)

When I try to start apache:

Syntax error on line 5 of /var/apache/conf/httpd.conf:
Cannot load /var/apache/libexec/libphp5.so into server: Shared object "libintl.so.6" not found, required by "libphp5.so"
/var/apache/bin/apachectl startssl: httpd could not be started

server has been down all day so I am kind of reaching for ideas here.

# ldconfig -r | grep libintl
256:-lintl.8 => /usr/local/lib/libintl.so.8

Well I found a way around it. I configured apache1.3 to activate the php5 module instead of loading it via httpd.conf. So all is well again one way or another :)
 
DarkenedReality said:
The permissions on libXau.so.6 is 755. But I seem to have stumbled over a bigger problem when i went to re-install the port anyway:
Code:
#pkg_delete -f libXau*
pkg_delete: No match.
#pkg_info: libXau*
pkg_info: No match.
#man pkg_info 
No manual entry for pkg_info
#pkg_info | grep libXau
libXau-1.0.4       Authentication Protocol library for X11

You have to escape the * with a \ in order for the shell to ignore it and pass it on to the pkg_* command.

The correct usage, though, is to use -x, which tells the pkg_* tools to do a search for that term: # pkg_delete -x libXau
 
tekkitan said:
I am having a similar issue with libintl.so.6, but I am trying to run apache. I manually compile my apache1.3.41 and php5.2.10, and have done so.

This all started when I did a portmaster upgrade.

Don't do that (mix ports with manual compiles). If you had installed everything via the ports tree, this would have been fixed by portmaster recompiling apache and php when libintl was updated. Now you will have to manually recompile Apache and PHP, and hope you remember which settings you used, to keep things working.
 
DarkenedReality said:
I'm just going to reformat and re-install (my servers been down for far too long; though the question of "why?" will still haunt me for awhile). Thanks Mel for all your help. Hopefully this doesn't repeat itself.

If you haven't done this yet, one other thing to try would be to change the shell for your non-root user to be /bin/tcsh, the same as root. And then see if things are working or not. I think it's just that your shell is corrupt due to the upgrades of dependent libs.
 
phoenix said:
Don't do that (mix ports with manual compiles). If you had installed everything via the ports tree, this would have been fixed by portmaster recompiling apache and php when libintl was updated. Now you will have to manually recompile Apache and PHP, and hope you remember which settings you used, to keep things working.

I did recompile both. Still seeing the same issue. I know you aren't supposed to mix ports and manual compiles, unless you know what you are doing. This is the first time I've done a portmaster upgrade since... well ever. Figured something would break.

apache and php are fine now since I modulized php5, but some other things are still seeing an issue. I guess I have a lot more recompiling to do. I believe imagemagik to be having an issue because when I edit an image in my php gallery, it completely breaks the image. That is interesting because it is a port, not manually compiled. I should also mention that this broke bash as well, which I had to boot into single user mode over a serial console and rebuild bash because I couldn't log in. Not sure I'll be doing a portmaster upgrade again if it is going to break ports.
 
tekkitan said:
Not sure I'll be doing a portmaster upgrade again if it is going to break ports.
It normally doesn't but it is advised to read /usr/ports/UPDATING before starting. Sometimes ports need to be upgraded in a certain order.
 
Back
Top