Обсуждение: Using libpq without LD_LIBRARY_PATH
Greetings, I am trying to get a simple C program to compile and run without having to define the LD_LIBRARY_PATH environment variable. First I tried this: gcc -o test -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpq test.c 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" So, I changed my compiler like to this: gcc -o test -I/usr/local/pgsql/include test.c /usr/local/pgsql/lib/libpq.a This produced a linker error like this: fe-auth.o: Undefined symbol `_crypt' referenced from text segment *** Error code 1 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 Where does all this stop? Can I static link with libpq? If so, how is it done? 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 This compiled okay, but when I run the program I get this warning: /usr/libexec/ld.so: warning: /usr/local/lib/libpq.so.2: minor version -1 older than expected 0, using it anyway Any insight would be greatly appreciated. Thank you, Matthew Hagerty
I compile and run my C program this way: gcc -O -o prog2 prog2.c -L/usr/local/postgres/lib -L/usr/local/postgres/include -lecpg -lpq -lcrypt -lnsl -lsocket -L/usr/local/kth-krb4-0.9.9/lib -lkrb -ldes -lresolv -I/usr/local/postgres/include -I/usr/local/postgres/lib But I know nothing about LD_LIBRARY_PATH environment variable - I just begin to work with all this stuff. -Margarita On Fri, 5 Feb 1999, Matthew Hagerty wrote: > Greetings, > > I am trying to get a simple C program to compile and run without having to > define the LD_LIBRARY_PATH environment variable. First I tried this: > > gcc -o test -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lpq test.c > > Any insight would be greatly appreciated. > > Thank you, > Matthew Hagerty > > >
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
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@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
On Fri, 5 Feb 1999, Matthew Hagerty wrote: > Greetings, > > I am trying to get a simple C program to compile and run without having to > define the LD_LIBRARY_PATH environment variable. First I tried this: > Depending on your OS you may have an /etc/ld.so.conf file. Simply add what you normally put in your LD_LIBRARY_PATH into that file. Then do a ldconfig -v as root (-v optional but you can see it working) and the libs will be available without the var set. This is what I do on my linux systems and it works well. On my solaris systems I've stuck with what the set up created before I got here. A shell script is called by all users logins. It defines the LD_LIBRARY_PATH for everyone when they log in. I have no idea if there is a better way as this works so I've never bothered to mess with it. ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas State University Department of Mathematics ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson wrote: > On Fri, 5 Feb 1999, Matthew Hagerty wrote: > > > Greetings, > > > > I am trying to get a simple C program to compile and run without having to > > define the LD_LIBRARY_PATH environment variable. First I tried this: > > > > Depending on your OS you may have an /etc/ld.so.conf file. > Simply add what you normally put in your LD_LIBRARY_PATH into that file. > Then do a ldconfig -v as root (-v optional but you can see it working) and > the libs will be available without the var set. This is what I do on my > linux systems and it works well. > > On my solaris systems I've stuck with what the set up created before I got > here. A shell script is called by all users logins. It defines the > LD_LIBRARY_PATH for everyone when they log in. I have no idea if there is > a better way as this works so I've never bothered to mess with it. > I belive that on Solaris you can define LD_RUN_PATH to the library paths to search and they will be embedded into the executalble so that LD_LIBRARY_PATH will not be needed. I know this is the case with UnixWare. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |