Re: [INTERFACES] Using libpq without LD_LIBRARY_PATH

Sorry, I forgot to specify versions, etc.

PostgreSQL-6.4.2
FreeBSD-3.0-Stable
gcc-2.7.2.1

Matthew

At 01:28 PM 2/5/99 -0500, Tom Lane wrote:
>Matthew Hagerty <matthew(at)venux(dot)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