Thread: pgaccess and RH 6.0?
When I try to run pgaccess under RedHat 6.0, I get the following: Error in startup script: couldn't load file "libpgtcl.so": /usr/lib/libpgtcl.so: undefined symbol: crypt while executing "load libpgtcl.so" (procedure "main" line 6) invoked from within "main $argc $argv" (file "/usr/bin/pgaccess" line 4954) Anyone have any ideas on how to fix this? Thanks, -- W. Wade, Hampton <whampton@staffnet.com> "...brought to you by the company that made your computer FAST and RELIABLE...." -- recent MSN/MS ad! Linux is stability, performance, compatibility, flexibility, scalability, and FREE!
> When I try to run pgaccess under RedHat 6.0, I get the
> following:
> Error in startup script: couldn't load file "libpgtcl.so":
> /usr/lib/libpgtcl.so: undefined symbol: crypt
> while executing
> "load libpgtcl.so"
> (procedure "main" line 6)
> invoked from within
> "main $argc $argv"
> (file "/usr/bin/pgaccess" line 4954)
>
> Anyone have any ideas on how to fix this?
Yup. You need to add "-lcrypt" to the Makefile or Makefile.in in the
src/interfaces/libpgtcl/ directory, then in that directory do a "make
clean install". Things should work after that. I added this just after
the "-lpq" in the same file...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Anyone have any ideas on how to fix this?
> Yup. You need to add "-lcrypt" to the Makefile or Makefile.in in the
> src/interfaces/libpgtcl/ directory,
Should be there already if you are using 6.5 --- if so, there might be
something else going on.
regards, tom lane
> >> Anyone have any ideas on how to fix this?
> > Yup. You need to add "-lcrypt" to the Makefile or Makefile.in in the
> > src/interfaces/libpgtcl/ directory,
> Should be there already if you are using 6.5 --- if so, there might be
> something else going on.
Well, what should I look for? Where does the "-lcrypt" come from, if
it "should be there already"? I see a test for it on $(LIBS), but I've
got to add "LIBS+= -lcrypt" to my Makefile.custom for this to work.
I've been pounding on builds from clean sources to try getting a
better linux rpm packaging, and so I've been going back and forth
between the postgresql-6.5.tar.gz and my current cvs tree the last few
days to test this stuff.
So Tom, to change the subject slightly, istm (and probably to you :)
that there is some ugliness in our makefiles which can and should be
cleaned up. I know you've already done a good bit of stuff on this.
I'm planning on doing some more of that sometime soon, for the areas
which turned out to be problematic for the rpm:
1) Our low-level makefiles create soft links for some source files
from other directories. Is there any (good) reason not to use "vpath"
to eliminate these?
2) "make distclean" doesn't, quite, fully clean the distribution. The
only file I've noticed so far is my fault (down in the odbc
directory), but that one might be fixed by fixing (1).
3) Building the Postgres apps (psql, pgaccess, etc) is a pita to do
right, since we don't generate shared libraries until installing the
libraries, but this is typically done *after* the apps are built. So
the apps are always statically-linked. I'm happy with the way the libs
are being done, but we should do something about gracefully phasing a
full install from scratch. btw, this becomes more apparent when trying
to build rpms, since the paradigm is to do a full build in the source
area, and *then* install into a replica of the final destination, and
*then* package the resulting files into the binary rpm. So, I've got
to do a "mini-install" into someplace in the source area to get the
shared libraries to finish off the apps, and *then* do another install
of the same libraries into the "replica tree" (my terminology ;).
4) the psql Makefile is generated from configure, but doesn't use the
configure substitution variables like @top_srcdir@ to set up paths.
Also, it has a reference to the utils directory (presumably to get
"strdup" if a system doesn't have it already) which could/should be
replaced by a vpath. Also, the psql Makefile always points at
$(LIBPQDIR) to find a library to link to, which *never* has a shared
library. I've got patches to test for the existance of shared
libraries in $(LIBDIR), and then pointing there instead. But that
brings up the phasing issue in (3).
5) the libpq Makefile also has a bunch of soft links set up to support
the multi-byte character encoding. Any reason not to make these vpath
references too?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>>>> Yup. You need to add "-lcrypt" to the Makefile or Makefile.in in the
>>>> src/interfaces/libpgtcl/ directory,
>> Should be there already if you are using 6.5 --- if so, there might be
>> something else going on.
> Well, what should I look for? Where does the "-lcrypt" come from, if
> it "should be there already"?
>From this part of libpgtcl's makefile:
# If crypt is a separate library, rather than part of libc, it may need
# to be referenced separately to keep (broken) linkers happy. (This is
# braindead; users of libpq should not need to know what it depends on.)
SHLIB_LINK+= $(findstring -lcrypt,$(LIBS))
> I see a test for it on $(LIBS), but I've
> got to add "LIBS+= -lcrypt" to my Makefile.custom for this to work.
Hmm. configure ought to add -lcrypt to LIBS by itself, if libcrypt
exists on your system. Would you poke into this and find out why it
isn't doing so?
> 1) Our low-level makefiles create soft links for some source files
> from other directories. Is there any (good) reason not to use "vpath"
> to eliminate these?
If you're thinking of libpq's use of dllist.c, I think that vpath would
be a risky solution, because it'd effectively import *all* of the
backend libpq files into the fileset visible during frontend libpq
build. It might or might not work OK right now, but I'd be concerned
about risk of future breakage more than whether it works now. Why do
you think vpath is a better solution than linking the source file?
I have also noticed some of the .h files getting symlinked into places
in src/interfaces, but if we want to fix that it's a job for -I not
vpath ...
> 2) "make distclean" doesn't, quite, fully clean the distribution.
Yeah, I've noticed that too --- there seem to be a few symlinks that
don't get removed. (But please note that the two big yacc output files
are not *supposed* to be removed. Maybe we need to split distclean
into two different targets, distclean and realclean...)
> 3) Building the Postgres apps (psql, pgaccess, etc) is a pita to do
> right, since we don't generate shared libraries until installing the
> libraries, but this is typically done *after* the apps are built. So
> the apps are always statically-linked.
Right. As I said, I think that adopting libtool would be a lot better
answer to this than handcrafting solutions for particular platforms.
> btw, this becomes more apparent when trying
> to build rpms, since the paradigm is to do a full build in the source
> area, and *then* install into a replica of the final destination, and
> *then* package the resulting files into the binary rpm. So, I've got
> to do a "mini-install" into someplace in the source area to get the
> shared libraries to finish off the apps, and *then* do another install
> of the same libraries into the "replica tree" (my terminology ;).
libtool ...
> 4) the psql Makefile is generated from configure, but doesn't use the
> configure substitution variables like @top_srcdir@ to set up paths.
Yes, it'd be a good idea to try to clean those things up a little
better. In a lot of ways, the existing makefiles haven't been updated
to be good citizens in a configure-driven world. One thing I'd
particularly like to see is being able to configure and build in a
separate object directory tree without modifying anything in the source
tree. (That's what vpath is really for, of course.)
> 5) the libpq Makefile also has a bunch of soft links set up to support
> the multi-byte character encoding. Any reason not to make these vpath
> references too?
See above comments about dllist.c.
regards, tom lane
> >>>> Yup. You need to add "-lcrypt" to the Makefile or Makefile.in in the
> >>>> src/interfaces/libpgtcl/ directory,
> >> Should be there already if you are using 6.5 --- if so, there might be
> >> something else going on.
> >From this part of libpgtcl's makefile:
> # If crypt is a separate library, rather than part of libc, it may need
> # to be referenced separately to keep (broken) linkers happy. (This is
> # braindead; users of libpq should not need to know what it depends on.)
> SHLIB_LINK+= $(findstring -lcrypt,$(LIBS))
> > I see a test for it on $(LIBS), but I've
> > got to add "LIBS+= -lcrypt" to my Makefile.custom for this to work.
> Hmm. configure ought to add -lcrypt to LIBS by itself, if libcrypt
> exists on your system. Would you poke into this and find out why it
> isn't doing so?
afaict, $(LIBS) is not the thing to test, because it is not ever
defined or initialized. I suspect that @LIBS@ is what should go in the
Makefile.in, so that configure can substitute it for a string which
*does* happen to contain "-lcrypt".
> Why do you think vpath is a better solution than linking the source file?
I see that many of the Makefiles which scatter soft links around do
not bother removing them during a "clean", and it is a source for
future problems of the same nature. istm that using vpath to find .c
(or perhaps .o) files which are explicitly mentioned in the OBJS list
is not a danger, and it makes for a much cleaner makefile. I'd be
inclined to use them wherever soft links would have been used. Any
hypothetical future breakage due to this is probably the least of our
breakage worries ;)
I'm still working on the "build-then-install" issue, and for this
release and ones in the near future libtools is apparently not an
option. So I'm planning on pursuing this with our existing toolset,
perhaps by incorporating a new rule in the toplevel makefile for, say,
"install-shared", just to get the steps written down somewhere. But I
won't do anything official until I convince myself that minor changes
to the lower-level makefiles won't fix the problem. As an example,
psql doesn't even try to do the right thing at the moment, but it was
fairly easy to get it to look to see if there are installed libraries,
and then point (with -L) at $(LIBDIR) instead of at $(LIBPQDIR), which
as I mentioned never has a shared library.
Comments and suggestions?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Hmm. configure ought to add -lcrypt to LIBS by itself, if libcrypt
>> exists on your system. Would you poke into this and find out why it
>> isn't doing so?
> afaict, $(LIBS) is not the thing to test, because it is not ever
> defined or initialized.
Oy vey, you're right.
> I suspect that @LIBS@ is what should go in the
> Makefile.in, so that configure can substitute it for a string which
> *does* happen to contain "-lcrypt".
No, I think the correct fix is to add to Makefile.global.inLIBS= @LIBS@
which is what I thought was there already, but it ain't. There are
several Makefiles that assume this symbol is provided by
Makefile.global... will fix this ASAP.
>> Why do you think vpath is a better solution than linking the source file?
> I see that many of the Makefiles which scatter soft links around do
> not bother removing them during a "clean", and it is a source for
> future problems of the same nature.
Agreed, but that's just a plain old bug in their clean rules.
> istm that using vpath to find .c
> (or perhaps .o) files which are explicitly mentioned in the OBJS list
> is not a danger, and it makes for a much cleaner makefile.
If we had explicit .o-to-.c dependencies for everything, I'd be
comfortable with that. I'm a lot less comfortable with assuming that
gmake will do the right thing when we are depending on an implicit
dependency. When all gmake knows is that it needs to make foo.o,
you are taking a risk whether it will decide to make it from foo.c
or from something else using some other implicit rule, and the risk
goes up when it has to search multiple directories to find the proper
ancestor file. I have seen vpath makes behave strangely before in this
kind of situation, particularly with older gmake versions. (Even in the
current gmake, I don't trust vpath fully, because it has some behaviors
that are unintuitive if not outright bugs.)
> I'm still working on the "build-then-install" issue, and for this
> release and ones in the near future libtools is apparently not an
> option.
Well, I wouldn't say that. I had figured that I could just leave
well enough alone for another release or so, since people weren't
particularly screaming about the fact that psql &friends aren't built
with shared libraries, and since I had plenty of other tasks to worry
about.
If you are intent on doing something about it Right Now, I'd still say
that your time is better spent on integrating libtool than on developing
(even more) ad-hoc makefile code that will cover some of the same
territory and will eventually need to be thrown away. libtool is not
perfect yet, but it's at least a 90% solution, and it already knows a
lot more than Makefile.shlib does...
regards, tom lane