Re: [INTERFACES] lo_export & pgaccess - Mailing list pgsql-interfaces

> > 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.)

No, that is not what I was complaining about at first, but that is
what I *should* have been complaining about :) I've got Makefile
patches which will allow the apps and libraries to be built using
shared libraries, though the sequence to do that is not pretty (yet)
since it involves building the interfaces to get libpq, installing
them to get libpq.so, and then cleaning and rebuilding to make sure
that the other interfaces and apps see this new shared library.

> > 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.

Right. You have to set the "-L" flag to get the library linked
correctly. Got patches coming to help with this...

> 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.)

That definitely would make things easier, if we want to be able to
decouple "make" from "make install". At the moment you have to cycle
back and forth between them to get shared libraries.

> 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.)

If you modify Makefile.shlib to do the soft links, then perhaps my
patches to have the linker look in "$(LIBDIR)" (if it finds
$(LIBDIR)/libpq.*) instead of "$(LIBPQDIR)" are not necessary. I'll
hold off on patching until we decide the best approach.
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California