LinuxQuestions.org - Linking woes, or, gcc is the devil.

- Programming (http://www.linuxquestions.org/questions/programming-9/)

- - Linking woes, or, gcc is the devil. (http://www.linuxquestions.org/questions/programming-9/linking-woes-or-gcc-is-the-devil-750775/)

[SOLVED] Linking woes, or, gcc is the devil.

So I don't understand shared objects very well. I'm trying to install a library called luapgsql, hosted here, that allows lua scripts to interface with a PostgreSQL database. It's a little old, but the only alternative is luasql, which doesn't support parametrized queries and is therefore categorically unacceptable. luapgsql supports everything I need, anyway. I'm building this on NetBSD 5.0/amd64.

luapgsql is distributed as a single luapgsql.c file with a single header file luapgsql.h. It links to libpq via #include libpq-fe.h; the libpq libraries are all stored in /usr/pkg/lib, and libpq-fe.h is stored in /usr/pkg/include, as are lua.h and lauxlib.h (also linked to, but I'm not experiencing issues with them... yet). I'm building it like this:

Code:

gcc -o pgsql.so -O2 -fPIC -I/usr/pkg/include -shared luapgsql.c -L/usr/pkg/lib -lpq

It builds successfully and creates pgsql.so. Now the way lua modules work is you simply copy them into ${prefix}/include/lua/5.1/, and then you can use them via require(<library name>), which is in this case require(pgsql). I copied pgsql.so into /usr/pkg/lib/lua/5.1, and ran the little included test.lua which starts with require(pgsql)

At this point, lua complains "Error in module pgsql: cannot find shared object file libpq.so.5". Now, libpq.so.5 exists in /usr/pkg/lib, which looks like this:

Code:

$ ls /usr/pkg/lib

[...]

libpq.so

libpq.so.5

libpq.so.5.0.1

[...]

which to me should mean that libpq.so.5 is in the expected location; unfortunately, lua disagrees. Does anyone have any idea what I might be doing wrong, and how to fix it? 'twould be very much appreciated.

J

There is a difference between the path used to access the library definitions at link time, and the path used to dynamically load the library at runtime.

The -L flag you gave to gcc gives it a path to search for static libraries and for dynamic libraries for use by the linker, but this does not affect where the executable will search for dynamic libraries (typically only /lib and /usr/lib).

There are several ways of providing a runtime library path. An older method was to use the environment variable LD_LIBRARY_PATH. Now, if you want to provide global access to the /usr/pkg/lib, you would add it to one of the /etc/ld.so.conf.d/ files, and run ldconfig (see 'man ldconfig'). Or if you just want it for a single application you can incorporate it into the executable by using the linker flag '-R /usr/pkg/lib'.

It works!

Thanks a ton.