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: (view raw, whole thread or download thread mbox)
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 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 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 in ../libpq
prevented the linker from marking as being dependent on, 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

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

			regards, tom lane


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-2017 The PostgreSQL Global Development Group