Understanding Libraries

[edge87]

Hello all,

I've recently begun working with C++ under Linux and have been using Eclipse CDT as my development environment and I have a few questions about the platform. I've been downloading and trying out different libraries (SFML - http://www.sfml-dev.org ) and when I go to compile after linking to the folder where the libraries are included with the package, the compiler is unable to find them. It isn't until I use apt to download the SFML package from the repository and let it install it into the system library paths that it is able to find them.

My question boils down to not understanding why the compiler isn't looking where it was instructed to for the libraries and if it can't, how I should be handling libraries that aren't included in repositories. I also don't understand how the compiler knows the extension of the library. For example, the SFML System library is -lsfml-system, but the file is called libsfml-system.so.1.6. I'm not sure how the compiler knows that linking to sfml-system should be found in the file named differently.

[james147]

The compiler looks in /lib and /usr/lib for libraries by default. To specify other locations for it to look set LD_LIBRARY_PATH to the location of the library:

export LD_LIBRARY_PATH="/path/to/first/lib:/path/to/second/lib"

However, the error messages you are getting and the commands you are using would be helpful.

[GreyGeek]

The compiler looks in /lib and /usr/lib for libraries by default. To specify other locations for it to look set LD_LIBRARY_PATH to the location of the library:

export LD_LIBRARY_PATH="/path/to/first/lib:/path/to/second/lib"

....

Using the export command in that manner will overwrite any existing contents of LD_LIBRARY_PATH. if it contains anything.

[B][FONT=courier new]LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath:/newpath2 [/FONT][/B]

would preserve the existing contents of an environmental variable. And, that change is available only for the shell it was created in and for as long as that shell is open or has focus. When the shell closes the change is lost. To make changes permanent put them in ~/.profile.

[james147]

Using the export command in that manner will overwrite any existing contents of LD_LIBRARY_PATH. if it contains anything.

[B][FONT=courier new]LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/newpath:/newpath2 [/FONT][/B]

would preserve the existing contents of an environmental variable. And, that change is available only for the shell it was created in and for as long as that shell is open or has focus. When the shell closes the change is lost. To make changes permanent put them in ~/.profile.

By default the variable is empty, and if not you will want to set your paths before the paths already set so it should be:

[B][FONT=courier new]LD_LIBRARY_PATH=/newpath:/newpath2:[/FONT][/B][B][FONT=courier new]$LD_LIBRARY_PATH[/FONT][/B]

[blobfish]

For example, the SFML System library is -lsfml-system, but the file is called libsfml-system.so.1.6. I'm not sure how the compiler knows that linking to sfml-system should be found in the file named differently.

Most of the time this is taken care of with symbolic links from the debian package. On my system in /usr/lib there a 3 files dealing with libslv2 (no idea what it's for just an example). The 3 files are libslv2.so, libslv2.so.9 and libslv2.so.9.2.0.... libslv2.so points to libslv2.so.9 which points to libslv2.so.9.2.0. So when you link libslv2 the linker looks for libslv2.so and resolves the symbolic links and actually links libslv2.so.9.2.0.

[edge87]

I guess what I was thinking is that Eclipse CDT would take care of the LD_LIBRARY_PATH changes as required because you define library locations within the application, but that might not be the case. I did install it from the Kubuntu repositories so it should be correctly configured for this distro. I'm also publishing a query with the Eclipse community to ensure i'm using it correctly to identify library paths.

[edge87]

Most of the time this is taken care of with symbolic links from the debian package. On my system in /usr/lib there a 3 files dealing with libslv2 (no idea what it's for just an example). The 3 files are libslv2.so, libslv2.so.9 and libslv2.so.9.2.0.... libslv2.so points to libslv2.so.9 which points to libslv2.so.9.2.0. So when you link libslv2 the linker looks for libslv2.so and resolves the symbolic links and actually links libslv2.so.9.2.0.

So should I have renamed the files that came with package to what the compiler was looking for?

[blobfish]

So should I have renamed the files that came with package to what the compiler was looking for?

No I wouldn't rename the file. I would first try to create a symbolic link in the same directory as your lib file. Something like:

ln -s ./libsfml-system.so.1.6 ./libsfml-system.so

if this doesn't cure the problem then the folder is not getting added to the library path(see other posts. LD_LIBRARY_PATH). Not familiar with eclipse, so I can't comment on how well it controls the gcc compile and link paths.

[edge87]

Solved

No I wouldn't rename the file. I would first try to create a symbolic link in the same directory as your lib file. Something like:

ln -s ./libsfml-system.so.1.6 ./libsfml-system.so

if this doesn't cure the problem then the folder is not getting added to the library path(see other posts. LD_LIBRARY_PATH). Not familiar with eclipse, so I can't comment on how well it controls the gcc compile and link paths.

Fantastic this worked great. The issue appears that the maintainers of SFML 1.6 distribute the libraries named libsfml-<package>.so.<version> and to make it work I needed to build a symlink from the libsfml-<package>.so.<version> to sfml-<package> .

Example (for any body else who may come across this)

libsfml-system.so.1.6 needs a symlink of sfml-system in the folder that you tell Eclipse CDT about.

ln -s libsfml-system.so.1.6 sfml-system

Thank you to everybody who helped, each part given was a piece to the larger puzzle.

[blobfish]

Fantastic this worked great. The issue appears that the maintainers of SFML 1.6 distribute the libraries named libsfml-<package>.so.<version>

I think versioned shared objects is the standard on linux. It helps avoid dll hell.