Thread: Re: [INTERFACES] lo_export & pgaccess
Ok, back to it now..... I have always had to add the -crypt info to Makefile.shlib because I also use libpq in other projects. I don't believe this is a crypt problem, because ldd for libpgtcl.so shows the dependency on libcrypt.so.1. pgaccess will run with the old libpgtcl.so.1 library accept for some new status features that cause it to bomb. But I have yet to be successful with 6.4 or 6.5. 6.4 fails to load libpgtcl.so because of undefined symbol "pgresStatus", and 6.5 fails because of undefined symbol "lo_export". I have these problems on various RedHat 5.2 & 6.0 machines, so it is not specific to one box. Wait, hold on... I just did "ldd libpgtcl.so" on a working 6.4 box & it shows a dependency on libpq.so.1. This seems normal! So why does my present (failing) libpgtcl not have a dependency on libpq built in!!??. Ken At 14:02 06/28/1999 +0000, you wrote: >Tom Lane wrote: >> >> "Ken J. Wright" <ken@ori-ind.com> writes: >> > It fails with or without the symbolic link, as it's finding it's way to the >> > same libpgtcl.so ok. I'm thinking there must be something wrong with the >> > build, but I'm not sure where to look. Are there other options besides >> > --with-tcl that are required? >> >> Try adding -lcrypt to SHLIB_LINK in src/interfaces/libpgtcl/Makefile.in >> (or .../Makefile if you already configured). There is code in there >> that is supposed to do that for you, but it is broken in the 6.5 release >> due to a silly oversight :-( > >I am sorry to say, noone to blame, but that piece of code that is >supposed to do that didn't worked either in 6.4.x or in 6.5 beta x. >As I recall, I checked every version against lcrypt including in linking >but no version worked fine (at least for my RedHat 5.x servers). > >But it ain't such a big problem. As Tom said, just adding -lcrypt to >SHLIB_LINK solve the problem. >PostgreSQL 6.5 is such a great thing so you can pass over those minor >problems! > >-- >Constantin Teodorescu >FLEX Consulting Braila, ROMANIA >
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. 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. 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... Ahh... I'm feeling much better now... really... And yes, I do love 6.5!!! Thanks for all the pointers (no pun, really!) Ken At 11:10 06/29/1999 -0700, you wrote: >Ok, back to it now..... > >I have always had to add the -crypt info to Makefile.shlib because I also >use libpq in other projects. I don't believe this is a crypt problem, >because ldd for libpgtcl.so shows the dependency on libcrypt.so.1. pgaccess >will run with the old libpgtcl.so.1 library accept for some new status >features that cause it to bomb. But I have yet to be successful with 6.4 or >6.5. 6.4 fails to load libpgtcl.so because of undefined symbol >"pgresStatus", and 6.5 fails because of undefined symbol "lo_export". I >have these problems on various RedHat 5.2 & 6.0 machines, so it is not >specific to one box. > >Wait, hold on... I just did "ldd libpgtcl.so" on a working 6.4 box & it >shows a dependency on libpq.so.1. This seems normal! So why does my present >(failing) libpgtcl not have a dependency on libpq built in!!??. > >Ken > >At 14:02 06/28/1999 +0000, you wrote: >>Tom Lane wrote: >>> >>> "Ken J. Wright" <ken@ori-ind.com> writes: >>> > It fails with or without the symbolic link, as it's finding it's way >to the >>> > same libpgtcl.so ok. I'm thinking there must be something wrong with the >>> > build, but I'm not sure where to look. Are there other options besides >>> > --with-tcl that are required? >>> >>> Try adding -lcrypt to SHLIB_LINK in src/interfaces/libpgtcl/Makefile.in >>> (or .../Makefile if you already configured). There is code in there >>> that is supposed to do that for you, but it is broken in the 6.5 release >>> due to a silly oversight :-( >> >>I am sorry to say, noone to blame, but that piece of code that is >>supposed to do that didn't worked either in 6.4.x or in 6.5 beta x. >>As I recall, I checked every version against lcrypt including in linking >>but no version worked fine (at least for my RedHat 5.x servers). >> >>But it ain't such a big problem. As Tom said, just adding -lcrypt to >>SHLIB_LINK solve the problem. >>PostgreSQL 6.5 is such a great thing so you can pass over those minor >>problems! >> >>-- >>Constantin Teodorescu >>FLEX Consulting Braila, ROMANIA >> >
"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
At 17:51 06/29/1999 -0400, you wrote: >"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.) This actually (above) is the whole problem. >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. This turns out to have been a typo on my part. In modifying Makefile.shlib to add the -lcrypt, I inadvertently changed the += to a :=. Another case of an end user creating their own problems ;-). But...... this crypt problem has been hanging around for some time. And I do wonder why it can't just be a permanent entry in the *linux* section of Makefile.shlib? >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. Hmm... did not present a problem immediately, but yes, I'm placing a mental bookmark on *risky*. >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. Yes, this seems to be true, and I suppose sensibly so, although it does appear to use /usr/lib as a default path. >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.) Hold on a sec..... YES. Using the distribution make files, all that has to change (for Linux anyway) is to add -lcrypt to SHLIB_LINK in Makefile.shlib and have the extra sym links created. I just did this and all went well. Thanks again, Ken
> > 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
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> 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.
The real issue here is whether the higher-level libraries and apps
need to have the absolute path to the installed copy of libpq embedded
in them, or only the file name of libpq.so.whatever.
On some systems (like HPUX) an absolute path actually is needed :-(
but I was under the impression that this was *not* required for Linux;
instead the ldconfig map is used to locate a shlib based on just its
filename, no?
If so, fixing the build procedure to generate a dummy set of symlinks
in the build directory might eliminate the need for the pushups Thomas
has been working on. I'm guessing that the real problem here is just
that the linker fails to make a reference to libpq.so at all unless
there is a version-numbered symlink in the directory it's told to
look in. (You should be able to check this with ldd...)
> 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.
I will patch Makefile.shlib for this today, and then we'll see what
happens.
regards, tom lane
"Ken J. Wright" <ken@ori-ind.com> writes:
> But...... this crypt problem
> has been hanging around for some time. And I do wonder why it can't just be
> a permanent entry in the *linux* section of Makefile.shlib?
That's not the right fix because it's not a Linux-only problem. The
appropriate fix is in place elsewhere (and, hopefully, will actually
work as intended in 6.5.1 ;-)).
> Hold on a sec..... YES.
> Using the distribution make files, all that has to change (for Linux
> anyway) is to add -lcrypt to SHLIB_LINK in Makefile.shlib and have the
> extra sym links created. I just did this and all went well.
Great! I'll fix the build rule to create those symlinks and then maybe
things will start to work properly...
regards, tom lane
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> 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.
Patches committed, if you want to try it. Note I'd suggest
"make distclean" and configure after pulling the update, to
make sure the changes have propagated into your Makefiles.
BTW, I also fixed the toplevel GNUMakefile's failure to remove
all the symlinks created by "configure" --- as you noted
earlier, there were a few in interfaces/odbc that had been
overlooked.
regards, tom lane