SliTaz Forum
You are not logged in.
Pages: 1
Hi,
Last April I compiled Jpilot and pilot-link, and installed them under /usr/local. It has worked well for months.
Today I couldn't launch Jpilot. The error was:
[c]$ jpilot
jpilot: error while loading shared libraries: libpisock.so.9: cannot open shared object file: No such file or directory[/c]
It looks like ld doesn't look in /usr/local/lib by default anymore! Fortunately I could make Jpilot work by manually setting the lib path:
[c]$ LD_LIBRARY_PATH=/usr/local/lib jpilot[/c]
I don't use Jpilot very often, so I cannot tell precisely when this bug appeared. But everything worked one month ago (24 October to be precise).
Any ideas?
Offline
Hi again,
Reading the man page on http://linux.die.net/man/1/ld , it seems /usr/local/lib is not in the default search path. So I've asked myself why did ld use to find the said lib? And I've come to the hypothesis that the install of libpisock had registered it (or its path) into /etc/ld.so.conf or /etc/ld.so.cache . These files are found in glibc-base, but are not marked as config files in its receipt, so they got overwritten when I upgraded glibc-base (not new version, but new build).
What do you think?
Offline
Hi Lucas,
IIRC SliTaz come with the pre-generated unchanged ld.so.cache file. And without tools to manage it. Try to overwrite your ld.so.* files with the original files provided in the glibc-base. (I based on my confidence that /usr/local/lib is working out from the box.)
Offline
Thanks for answering.
Meanwhile, I found a copy of a previous ld.so.conf, it was already empty. So the problem is not here.
Some detailed tests:
[c]# tazpkg -i /var/cache/tazpkg/cooking/packages/glibc-base-2.14.1.tazpkg --forced[/c]
-> jpilot doesn't run
[c]# ldconfig -p[/c]
-> 40 libraries
[c]# ldconfig[/c]
-> jpilot doesn't run (so /usr/local/lib doesn't work out-of-the-box here (*))
[c]# ldconfig -p[/c]
-> 1042 libs (yes, I have many packages installed 
) but nothing from /usr/local/lib
[c]# ldconfig /usr/local/lib[/c]
-> jpilot runs
[c]# ldconfig -p[/c]
-> 1046 libs: the 4 libs from /usr/local/lib were added
So my conclusion is that the install script of libpisock must have updated the cache.
Can ld.so.conf and ld.so.cache be added to CONFIG_FILES in the receipt of glibc-base?
(ldconfig is in glibc-dev)
(*) I just noticed that LD_LIBRARY_PATH is set in /etc/profile to contain /usr/local/lib.
From the man http://linux.die.net/man/1/bash , bash should source /etc/profile and ~/.profile when a login shell, but in a terminal I observe ~/.profile has been sourced, /etc/profile not. (However, if I invoke [c]bash --login[/c] in the terminal, the new shell has sourced both. [c]busybox sh --login[/c] behaves the same.) I'm confused!
Offline
Just add ". /etc/profile" to $HOME/.profile, relogin :
[c]sed -i '3i\. /etc/profile' ~/.profile[/c]
No problem on fresh-iso, only old-iso with update.
Offline
Thanks Alexander, I know the workaround, but I was concerned by a possible bug (hence the post in the Devel subforum 
)
No problem on fresh-iso, only old-iso with update.
This is reassuring. Do you know why/can you explain please?
Offline
Sorry for wrong info. There are problems with 'Unnamed window' instead of IP for xterm after update. Code to get IP located in "/etc/profile" so assumed common problems with reading profile on update.
Now I test this carefully and found that /usr/local/lib avaliable only for:
console session (/dev/tty*)
or "xterm" (only with "-ls" option).
Don't know is it bug or feature.
Offline
slim.conf has this:
[c]login_cmd exec /bin/sh -l ~/.xinitrc %session[/c]
So a login shell is used to invoke the window manager, and I tested that [c]busybox sh[/c] does source /etc/profile (you may double-check). Is it possible that lxde-session clears environment variables? I don't know how to test this.
Offline
Pages: 1
[ Generated in 0.016 seconds, 7 queries executed - Memory usage: 1.54 MiB (Peak: 1.77 MiB) ]