Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] lo_export & pgaccess

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ken J(dot) Wright" <ken(at)ori-ind(dot)com>
Cc: pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] lo_export & pgaccess
Date: 1999-06-29 21:51:34
Message-ID: 20720.930693094@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-interfaces
"Ken J. Wright" <ken(at)ori-ind(dot)com> writes:
> Got it!!!
> libpgtcl's Makefile points to ../libpq -lpq, but 2 things:

> 1) there is not a sym link to libpq.so.2.0 in this directory, so it fails.

Hmm.  Now that you mention it, that does sound like it could be a
problem.  (Perhaps this is what Tom Lockhart has been complaining about
when he asserts that the shlib is not built until install time --- it
*is* built, but the makefile doesn't create a full set of symlink
aliases for it in the libpq source directory.  That might be a problem
on some systems.)

> 2) Makefile.shlib is included *after* this line & re-defines SHLIB_LINK
> without -lpq. Some testing showed that make used the last definition as
> opposed to the first (although I remember it is as just the opposite, will
> have to consult the make book). I had to move the line containing
> Makefile.shlib *above* the one containing the SHLIB_LINK declaration.

Say what?  Makefile.shlib does not "redefine" SHLIB_LINK.  For linux
(only) it does do
	  SHLIB_LINK		+= -lc
which *adds onto* any preexisting definition of SHLIB_LINK.

It seems to me that if you did reshuffle the commands as you suggest,
you'd end up with "-lc" before "-lpq" and "-lcrypt", which I'd expect
not to work, or at least be risky.

> So after creating a sym link to libpq.so and shuffling the above 2 lines,
> it finally linked correctly! Apparently, ld does not use the cache that
> ldconfig maintains, because the cache contained the proper pointers to
> /usr/local/pgsql/lib...

I'm not a Linux guru, but I suspect that ldconfig's cache is used at
execution time by the dynamic shlib loader, *not* at link time.
Probably, the lack of a correctly named link to libpq.so in ../libpq
prevented the linker from marking libpgtcl.so as being dependent on
libpq.so, with the result that the dynamic loader didn't know to load
libpq (from anywhere) before loading libpgtcl, with the result that you
get these "symbol not found" messages for libpgtcl's references to
libpq.

At this point I believe that the correct fix is for libpq's Makefile
to create the extra symlinks in the libpq source directory at build time,
not merely in the install directory at install time.  (Actually, this
probably ought to happen for all the shlibs, so we really want to modify
Makefile.shlib to do it.)  I believe that it should *not* be necessary
to modify libpgtcl's Makefile.  Would you try that and see if it works?
(If you don't want to mess with Makefile.shlib, just create the extra
symlinks by hand after building libpq, then see if libpgtcl's Makefile
creates a working libpgtcl.so.)

			regards, tom lane

Responses

pgsql-interfaces by date

Next:From: Jim LemonDate: 1999-06-29 21:59:10
Subject: Problem with regression test
Previous:From: Pablo Saul Salazar - CESERCOMPDate: 1999-06-29 20:56:08
Subject: Help me with libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group