Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.2/8.9.1) with ESMTP id NAA68615
	for <pgsql-interfaces@postgreSQL.org>;
	Fri, 5 Feb 1999 13:29:05 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA18289;
	Fri, 5 Feb 1999 13:28:24 -0500 (EST)
To: Matthew Hagerty <matthew@venux.net>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Using libpq without LD_LIBRARY_PATH 
In-reply-to: Your message of Fri, 05 Feb 1999 13:13:14 -0500
	<4.1.19990205125048.00995ac0@mail.venux.net>
Date: Fri, 05 Feb 1999 13:28:24 -0500
Message-ID: <18287.918239304@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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