Re: [INTERFACES] pgaccess and RH 6.0? - Mailing list pgsql-interfaces

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