Building Projects From Anjuta.
Author
Hello, I'm having some problems with Anjuta and hopefully someone here can help me out!
I was using code::blocks but decided to give Anjuta a try, after setting up all the linker and compiler options and running automake and autoconf I built my project. No problems ...
When I try and run the program it tells me it cannot find a shared library (in this case libfmodex.so) even if I put this file in the same directory as the binary it still tells me this.
I don't understand what isn't working here, the program compile and links fine when doing so from code::blocks, is there something wierd going on with automake or autoconf or something?
Thanks for any help advance!
Quote:Original post by AsOne
When I try and run the program it tells me it cannot find a shared library (in this case libfmodex.so) even if I put this file in the same directory as the binary it still tells me this.
Linux will only search for shared objects in certain directories. By default, '.' (your current path) is not one of them. You can temporarily specify the paths to search with the LD_LIBRARY_PATH environment variable, which your former IDE may have been doing for you. (Apparently, you don't have any problems getting your program to find the library during linking, so I won't cover that.)
You can use the program ldd to list the library dependencies of an executable as they would be found (or not found) by Linux.
So, for example:
Your program: /thing/program (which requires libthing)
Your library: /thing/libthing.so.0
Run (if you're not using BASH, convert appropriately): export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/thing
Then, to check that, run: ldd /thing/program
Which should show something along these lines:
... libthing.so.0 => /thing/libthink.so.0 (0xABCDEF01)
It's unlikely to be a problem with your tools.
Linux, at least the Intel variant, uses the ELF object file format. What that means for you in this case is that when an application file is loaded (that is, a file with the execute permission set and a magic of '\177ELF' as the first four bytes is loaded by the exec(2) call), a special header called INTERP is read and if present, used to locate another program segment that is executed first. In you case, that program segment will probably be the DSO /lib/ld-linux.so, which is also known as the dynamic loader. This program segment reads the remaining headers and segments from the ELF file and attempts to resolve unresolved symbols by opening and loading yet more DSOs as listed in the ELF file.
The ELF file contains only the name of the DSO (eg. libc.so.6), not where it's located. For each DSO named, the dynamic linker will iterator through a number of locations, including but not limited to /lib, /usr/lib, /usr/local/lib, the contents of the /etc/ld.so.cache file (which is determined through /etc/ld.so.conf and the ldconfig tool), any files listed in the LD_PRELOAD environment variable, and any directories listed in the LD_LIBRARY_PATH environment variable.
Unlike Windows, neither the current working dorectory nor the directory in which the executable file was located are normally included in the search path.
I suspect Code::Blocks will automatically set LD_LIBRARY_PATH for you, and you're trying to execute from within the IDE. With Anjuta, you don't normally execute programs from within the IDE so you'll either have to copy your shared library into a system directory (like /usr/lib) or better yet, set LD_LIBRARY_PATH to point to its location.
Man, I hope that's clear.
Linux, at least the Intel variant, uses the ELF object file format. What that means for you in this case is that when an application file is loaded (that is, a file with the execute permission set and a magic of '\177ELF' as the first four bytes is loaded by the exec(2) call), a special header called INTERP is read and if present, used to locate another program segment that is executed first. In you case, that program segment will probably be the DSO /lib/ld-linux.so, which is also known as the dynamic loader. This program segment reads the remaining headers and segments from the ELF file and attempts to resolve unresolved symbols by opening and loading yet more DSOs as listed in the ELF file.
The ELF file contains only the name of the DSO (eg. libc.so.6), not where it's located. For each DSO named, the dynamic linker will iterator through a number of locations, including but not limited to /lib, /usr/lib, /usr/local/lib, the contents of the /etc/ld.so.cache file (which is determined through /etc/ld.so.conf and the ldconfig tool), any files listed in the LD_PRELOAD environment variable, and any directories listed in the LD_LIBRARY_PATH environment variable.
Unlike Windows, neither the current working dorectory nor the directory in which the executable file was located are normally included in the search path.
I suspect Code::Blocks will automatically set LD_LIBRARY_PATH for you, and you're trying to execute from within the IDE. With Anjuta, you don't normally execute programs from within the IDE so you'll either have to copy your shared library into a system directory (like /usr/lib) or better yet, set LD_LIBRARY_PATH to point to its location.
Man, I hope that's clear.
Author
OK some odd things must be going on with my system.
I did ldd appname and it listed a bunch of libraries and the two fmod shared objects said file not found beside them, this was expected.
I then checked to see what LD_LIBRARY_PATH was so I did "echo $LD_LIBRARY_PATH" and the result was nothing! I tried changing LD_LIBRARY_PATH to point to where the fmod shared libraries are and then ran ldd again. Still it says file not found, and the program does not run. Also when I built the project from code::blocks the executable did work when running from the command line. When I run ldd with the binrary from code blocks it lists the full path of the two fmod libraries.
I think this might be happening becasue in Anjuta it won't let me specify the entire library path for each library, it forces me to list the libraries only by name, then specify the locations seperatly; whereas in code::blocks I specified the full path for each library.
I did ldd appname and it listed a bunch of libraries and the two fmod shared objects said file not found beside them, this was expected.
I then checked to see what LD_LIBRARY_PATH was so I did "echo $LD_LIBRARY_PATH" and the result was nothing! I tried changing LD_LIBRARY_PATH to point to where the fmod shared libraries are and then ran ldd again. Still it says file not found, and the program does not run. Also when I built the project from code::blocks the executable did work when running from the command line. When I run ldd with the binrary from code blocks it lists the full path of the two fmod libraries.
I think this might be happening becasue in Anjuta it won't let me specify the entire library path for each library, it forces me to list the libraries only by name, then specify the locations seperatly; whereas in code::blocks I specified the full path for each library.
Quote:Original post by AsOne
I think this might be happening becasue in Anjuta it won't let me specify the entire library path for each library, it forces me to list the libraries only by name, then specify the locations seperatly; whereas in code::blocks I specified the full path for each library.
Hmm, if you specify the full path to a static archive (a .a file) you will pick up the static archive. If yu use the -l and -L arguments to resolve libraries and DSOs (.so) are present, those will be used instead. Perhaps that's the difference?
You can watch what shared libraries your app tries to open as it starts using the command strace -e trace=open yourapp. You can see what it tries to open and where it fails. It may not help fix your problem but it helps to understand what's going on.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
