Matthew Hagerty <matthew@venux.net> writes:
> I am trying to get a simple C program to compile and run without having to
> define the LD_LIBRARY_PATH environment variable.
On what platform? Unix shared-library support is so variable across
different systems that it's hard to give any generic advice.
> With LD_LIBRARY_PATH defined the program runs fine, without LD_LIBRARY_PATH
> defined I get this error:
> ld.so failed: Can't find shared library "libpq.so.2.0"
Yup, not surprising. Your platform might have another way to inform the
dynamic linker where to find shared libraries besides LD_LIBRARY_PATH;
for example, if you have ldconfig then you probably want to add
/usr/local/pgsql/lib to its config file.
> So, I added -lcrypt to the whole mess, like this:
> gcc -o test -I/usr/local/pgsql/include -lcrypt test.c
> /usr/local/pgsql/lib/libpq.a
> Then I get the following warning:
> ld: symbol __GLOBAL_OFFSET_TABLE_ remains undefined
I'd expect that you need to put -lcrypt *after* the reference to
libpq.a, although that error message isn't exactly helpful.
> As a last ditch effort I added symbolic links in my /usr/local/lib
> directory to libpq.a, libpq.so and libpq.so.2, and compiled like this:
> gcc -o test -I/usr/local/pgsql/include -lpq test.c
That'll probably link to the shared-library version of libpq, since
that's usually the default choice on systems that have shared libraries.
Dunno about the weird version-number warning; possibly the linker is
expecting to find "libpq.so.2.0" not "libpq.so.2".
regards, tom lane