Re: [INTERFACES] lo_export & pgaccess - Mailing list pgsql-interfaces
From | Tom Lane |
---|---|
Subject | Re: [INTERFACES] lo_export & pgaccess |
Date | |
Msg-id | 20720.930693094@sss.pgh.pa.us Whole thread Raw |
In response to | Re: [INTERFACES] lo_export & pgaccess ("Ken J. Wright" <ken@ori-ind.com>) |
Responses |
Re: [INTERFACES] lo_export & pgaccess
|
List | pgsql-interfaces |
"Ken J. Wright" <ken@ori-ind.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
pgsql-interfaces by date: