Re: [INTERFACES] pgaccess and RH 6.0?

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