You are not logged in.
Pages: 1
I've just installed some shared libraries and I'm trying to write some code to access them. The libraries are in /usr/local/lib and the headers are in /usr/local/include .
My C code can find the headers but when I try to compile it I get a load of "undefined reference to" errors referring to the functions which come from the library. At the end I get
collect2: ld returned 1 exit status
This is when I use gcc as a compiler.
I've ran ldconfig since installing the libraries.
What do I need to do to use the libraries?
Offline
You need to use the -L and -l flags to gcc when linking - if you provide your current command line, I can show you.
Offline
By setting -L and -l I managed to get it to compile. The command line ended up like this:
cc man.c -L /usr/local/lib/liborcon.la/ -lorcon
but to run the executable I had to do this first
export LD_LIBRARY_PATH=/usr/local/lib/liborcon.la/
Obviously it is telling application where to find the libraries but would I have to set a very long path if I installed more libraries in different directories. Is there a better way to do this?
By the way, I didn't put the libraries in this directory, that is where the installer put them.
Offline
export LD_LIBRARY_PATH=/usr/local/lib/liborcon.la/
Obviously it is telling application where to find the libraries but would I have to set a very long path if I installed more libraries in different directories. Is there a better way to do this?
By the way, I didn't put the libraries in this directory, that is where the installer put them.
/etc/ld.so.conf is where the standard runtime loader finds these libraries. You can add your custom paths there.
Offline
I've done that and it worked, thanks.
Should the package installer add that line? If so I'll let them know.
Offline
Well, possibly - there's a handful of ways to do it. One, for instance, is setting the LD_LIBRARY_PATH environment variable. There should also be a /etc/ld.so.d/ directory which contains any number of files exactly like ld.so.conf
Either way, I don't know if it's a good idea for the installer of the library to do that, but the installer of an _app_ should.
Offline
OK. I'll just set my own environment and if I do release an app then I'll make sure I modify the ld.so.conf.
Offline
I wouldn't do so. There are reason why there are libraries, and you can simply depend on libs (as most things in linux do anyway). If you don't want the deps, and say it's a distributed 1-exe-baby (as oracle) link them statically.
Usually, you can speicfy in the installer where the libs shall go. Also, a .la file is compiled with libtool. I don't know if you actually can do so, but i'd try to disable libtools (if it's not binary distributed).
Also, you can simply make a pacman packages of the lib with headers, installing the needed things into the path you need it.
If you're a developer, and develop together with other guys, i'd recommend you to create a package, and build up a own local repository, with the devel packages needed. I've done so here, that's really a nice solution, especially for libs installed like this for which you can create nice pacman packages.
// STi
Ability is nothing without opportunity.
Offline
Not sure what you are saying.
I am going to depend on the libs. I'll build my app which uses the lorcon libs and distribute it. As it needs the libs I'll need to some way to ensure it can find them and adding the entry to ld.so.conf seems like the best way to do it. I don't want to build it statically as that wouldn't allow upgrading of the underlying system and I'm not planning to build any libraries myself so I don't have to worry about putting them anywhere.
Have I missed your point?
Offline
Pages: 1