On 2/29/12, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 29 February 2012 08:05, Marc Glisse wrote: >> On Tue, 28 Feb 2012, Marco Ricci wrote: >> >>> I built gtk locally on my computer and the build went fine, but when I >>> wrote a small test program and tried to link it to the library that I >>> built, >>> it compiled fine, but behind the scenes, it actually linked to the file >>> in >>> /usr/lib. >> >> >> I guess you checked that with ldd on your program, not strace on the >> build? >> >> >>> I've tried everything, -L option, compiling with the full path of the >>> library file and even googling for the answer. I see that others have had >>> the same problem but there are no satisfactory responses. I tried >>> -nostdlib >>> option with gcc but then it started complaining about other libraries. >> >> >> There are 2 operations called linking. One is when you create the binary >> file. Another one is when you run it. -L tells where to look for libraries >> during the first one. -rpath (it is a linker option, so you want -Wl, in >> front) tells where to look during the second one. > > As an alternative to using -rpath you can set the LD_LIBRARY_PATH > environment variable so that the executable looks in that path for the > libraries it needs. > > gcc -L /foo/bar -lgtk -o prog source.c > ./prog # uses /usr/lib/libgtk.so > export LD_LIBRARY_PATH=/foo/bar > ./prog # uses /foo/bar/libgtk.so > > Some people prefer to use -rpath to set the path at link-time, some > prefer to use LD_LIBRARY_PATH to provide the path at run-time. You > can decide which solution is right for you based on how you want to > use the libraries and the executable. > If I may ask a follow up question here: If I use the -rpath thing to point at my library, what happens if it can't find it (it got deleted or stolen)? Will the ld.so thingy go try the /usr/lib or /lib one if the sonames are ... compatible? Thanks. kevin