GTKPOD file not found error

redness · 01-22-2005, 09:48 PM

HI Peoples,

I have just installed gtkpod from source, and it seems fine, except when I go to run it, it cant find "libmp4v2.so.0" - However I looked around, and its in the /usr/local/lib and is pointing to "libmp4v2.so.0.0.0" via a link. I checked the ./configure file, and it says the the default location is /usr/local/lib so I am assuming its looking there. All files in there have read-exec premissions on everybody so I dont think its that.

I am running slackware 10 on an upgraded kernel 2.6.10. X is installed and working with KDE. I also installed libmp4v2 successfully, and gktpod detected it when configuring.

Any Help greatly appreciated

Redness

redness · 01-23-2005, 01:36 AM

Heres the actual error message

Quote:

gtkpod: error while loading shared libraries: libmp4v2.so.0: cannot open shared object file: No such file or directory

and here's the ls of /usr/local/lib

Code:

______@___:/usr/local/lib$ ls
libh264util.a          libmp4av.la*                 libmpeg4ipSDL.a
libh264util.la*        libmp4av.so@                 libmpeg4ipSDL.la*
libh264util.so@        libmp4av.so.0@               libmpeg4ipSDL.so@
libh264util.so.0@      libmp4av.so.0.0.0*           libmsg_queue.a
libh264util.so.0.0.0*  libmp4util.a                 libmsg_queue.la*
libhttp.a              libmp4util.la*               libmsg_queue.so@
libhttp.la*            libmp4util.so@               libmsg_queue.so.0@
libhttp.so@            libmp4util.so.0@             libmsg_queue.so.0.0.0*
libhttp.so.0@          libmp4util.so.0.0.0*         libsdp.a
libhttp.so.0.0.0*      libmp4v2.a                   libsdp.la*
libmp4.a               libmp4v2.la*                 libsdp.so@
libmp4.la*             libmp4v2.so@                 libsdp.so.0@
libmp4.so@             libmp4v2.so.0@               libsdp.so.0.0.0*
libmp4.so.0@           libmp4v2.so.0.0.0*           mp4player_plugin/
libmp4.so.0.0.0*       libmpeg4ipSDL-1.2.so.0@      php/
libmp4av.a             libmpeg4ipSDL-1.2.so.0.7.0*  php.ini

ls -l

lrwxr-xr-x   1 root root       19 2005-01-23 11:48 libmp4v2.so.0 -> libmp4util.so.0.0.0*
-rwxr-xr-x   1 root root    66288 2005-01-23 11:48 libmp4v2.so.0.0.0*

Please help, if im doing something stupid, please tell me

redness

__J · 01-23-2005, 02:00 AM

have you run ldconfig?

redness · 01-23-2005, 02:26 AM

wot does that do?

and was it stupid for me not to?

redness

*edit*

hmm...considering it fixed it...and it was quick...i think its deserved that I slap myself

thanks for that btw

*/edit*

__J · 01-23-2005, 02:33 AM

I should have clarified that sorry.

ldconfig ( which must be run as root) opens the file /etc/ld.so.conf and reads the directories listed in there to cache libraries. Whenever you add libraries to the system in a directory other than /usr/lib/ or /lib, you must run it before it will see the new libs. it creates a file called /etc/ld.so.cache (do not edit this file).

So in your example, since your library was installed in /usr/local/lib, you will need to run ldconfig (remember to run it as root) for the new libraries to be seen by the system ( you only need to do this once after installing/uninstalling libraries).

__J · 01-23-2005, 02:33 AM

I should have clarified that sorry.

ldconfig ( which must be run as root) opens the file /etc/ld.so.conf and reads the directories listed in there to cache libraries. Whenever you add libraries to the system in a directory other than /usr/lib/ or /lib, you must run it before it will see the new libs. it creates a file called /etc/ld.so.cache (do not edit this file).

So in your example, since your library was installed in /usr/local/lib, you will need to run ldconfig (remember to run it as root) for the new libraries to be seen by the system ( you only need to do this once after installing/uninstalling libraries).

and no your not stupid for not doing this, its all just part of the learning process.

redness · 01-23-2005, 02:47 AM

well thanks again,

it works now, and even better I have managed to see my ipod correctly etc, so again thanks

redness

__J · 01-23-2005, 02:49 AM

no problem, glad to help

daihard · 01-23-2005, 04:18 AM

Quote:

Originally posted by __J
no problem, glad to help

May I ask you a related question?

What is the role of the file /etc/ld.so.conf? I thought it had the list of directories an application looks at when it needs to load a shared library. If that is in fact the correct understanding and if your /etc/ld.so.conf includes /usr/local/lib, do you still need to run ldconfig each time you add libraries to /usr/local/lib?

And if that is true, does the environment variable LD_LIBRARY_PATH help solve that problem?

TIA,
Dai

__J · 01-23-2005, 04:35 AM

when you run ldconfig, it caches the libraries that are there at the moment. So if you add a lib 5 minutes later, the system has no idea the library exist until you run ldconfig. As far as it's role, it specifies a list of directories ldconfig looks at when caching new libraries added to the system. When an application loads, it consults ld-linux.so.2 (which is the dynamic library linker (may be a different name depending on the platform you are running on)) to load the shared libraries for it.

To see what an application requires ld-linux.so.2 to load for it type:

Code:

ldd <application name>

if you want to see what libraries are being cached during the ldconfig process:

Code:

ldconfig -v | more

will show you what directories it is searching (which are /lib and /usr/lib + the library paths specified in /etc/ld.so.conf) and caching.

LD_LIBRARY_PATH is different. Depending on the source of information, it is considered both good and bad and can be misused if you are carelessly using it. More or less, it is used to override the default library linker path to something else before the standard locations. for example, I run a gnome-1.4 desktop on my slackware 10 distro. When I build gnome-1.4, I install everything in my home directory under $HOME/gnome-1.4 so in order for the system not to link the orbit-0.5.17 that came with slack but mine in in $HOME/gnome-1.4/lib if have to override it with LD_LIBRARY_PATH like follows:

Code:

export LD_LIBRARY_PATH=$HOME/gnome-1.4/lib:$LD_LIBRARY_PATH

this ensures that libraries in $HOME/gnome-1.4/lib are loaded by ld-linux.so.2 before even the same lib in /usr/lib. To add the desired directory to the end of the library search path:

Code:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/gnome-1.4/lib

would have been used but in my case would not work cause I need my libs loaded first.
Check out the garnome README for an example of this. This is how garnome works, by altering the different paths to make sure everything installed by it is loaded before your default system installed stuff is loaded.

daihard · 01-23-2005, 05:46 AM

Thanks much for the explanations.

Assuming that I understand it, my next question is, can I just include /usr/local/lib in my LD_LIBRARY_PATH variable instead of having to remember to run ldconfig each time I add a new library to /usr/local/lib?

I created a simple shared library. I first placed it in /home/daihard/mylib/ just for testing. I created another program, which calls the function defined in that library. I placed it in /home/daihard/bin. Let's call the library libDai.so and the executable "testDai."

The first time I ran testDai, it complained that it could not "open shared object file: No such file or directory." I then added /home/daihard/mylib to my LD_LIBRARY_PATH as follows:

Code:

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/daihard/mylib

The next time I ran testDai, it ran successfully, calling the function defined in libDai.so and exited normally.

From this, I'd conclude that I could do the same to /usr/local/lib. Since the libraries loaded by an application will be loaded onto the memory, I don't think this method is too much less efficient than caching the libraries beforehand.

I hope I'm not missing something fundamental here...

Dai

__J · 01-23-2005, 06:00 AM

yes your understanding is correct. The LD_LIBRARY_PATH variable is used to override the default shared library path whereas the ldconfig method is used to add new libraries to the system in a more permanent method. Really, In my opinion, I would use either way ( keep in mind this is my opinion, and depending on who the information comes from, LD_LIBRARY_PATH can either be good or bad, and also, that unless you add LD_LIBRARY_PATH to something permanent, like /etc/profile, /etc/bashrc, etc.., it would have to be defined every time you wished to run the particular program the depends on the libraries).

We could conclude that it actually makes no difference in which method you choose( LD_LIBRARY_PATH or ldconfig) depending on what you want to use it for. The "right" way, technically is to use /etc/ld.so.conf but this area gets kinda muddy considering there are multiple ways to do something on a Linux system and get the same result.

EDIT: another good resource is the prebuilt binary packages of firefox and mozilla. You'll notice that the actual binary is called firefox-bin but you execute "firefox", open up firefox in a text editor and you'll notice it's just a shell script to set up the environment ( including LD_LIBRARY_PATH since the shared libraries come with it and are installed in the same folder) and call firefox-bin. This is kinda the windows approach, give everything the user will need, including shared libraries, and (hopefully) the user will not have to worry about anything but running the executable.