Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am working with a virtual machine (CentOS 5.3) that has very little storage space on the main drive (which includes /usr, /usr/local, etc). Most of the storage space is available on a separate drive that is mounted to /mnt. Consequently, on this drive I have created a basic installation directory (with subdirectories like bin, include, lib, etc) and installed a library there.

[standage@vm142-46 ~]$ ls -lhp /mnt/lib
total 33M
-rw-r--r-- 1 standage iplant-everyone 21M Dec 21 16:29 libgenometools.a
-rwxr-xr-x 1 standage iplant-everyone 13M Dec 21 16:29 libgenometools.so

I then tried to link to that library with code that I had written, but it gave me the following message.

/usr/bin/ld: cannot find -lgenometools

I realized I had not updated ldconfig with the new installation directory I had created, so I went ahead and added /mnt/lib to /etc/ld.so.conf and ran /sbin/ldconfig. However, when I tried to link my code again I got the same error.

I was eventually able to get the libraries to link by creating symlinks to /usr/local/lib64...

[standage@vm142-46 ~]$ sudo ln -s /mnt/lib/libgenometools.a /usr/local/lib64
[standage@vm142-46 ~]$ sudo ln -s /mnt/lib/libgenometools.so /usr/local/lib64

...but this doesn't really solve my original problem, it's just a duct-tape solution. What did I do wrong originally and how can I link to the library I've installed?

share|improve this question
1  
Apart from that is was the wrong place to do it - "ld.so.conf" is also the wrong place to put your own path. use the directory "ld.so.conf.d" and create a *.conf file there. ld.so.conf is a file from the glibc library. If it ever gets updated you might run into trouble (although it is marked as config-file in the rpm). –  Nils Dec 24 '11 at 22:32
add comment

2 Answers 2

up vote 1 down vote accepted

/etc/ld.so.conf only influences the dynamic linker, i.e. where libraries are looked for at run time. When you build an executable, what matters is the paths where ld looks for the library. The usual way to specify these is to pass the -L option; most configure scripts have a way to pass additional -L options. There usually isn't a way to change the default search path for ld. You might look into changing the gcc spec file, but that will involve changing a file under /usr, not under /etc.

Given your slightly awkward setup, you may want to look into a union mount of /mnt above /usr. I don't know what union mount possibilities CentOS offers if any (of course, there are third-party options, native or based on FUSE).

share|improve this answer
    
Thanks for clarifying regarding /etc/ld.so.conf. I've taught myself most of what I know about compiling, linking, makefiles, etc., and for some reason I thought /etc/ld.so.conf and ldconfig affect both compile-time and run-time behavior. I extended my makefile so that the user can provide additional -L flags, and this seems to be a good long-term solution. Thanks! –  Daniel Standage Dec 22 '11 at 17:12
add comment

You can use ldconfig -v to see, if ldconfig know about a new library. I pretend, that message /usr/bin/ld: cannot find -lgenometools is during linking phase of compiling program, isn't it? Then you must say to linker, where it may find a library using a -L/mnt/lib parameter.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.