Re: [INTERFACES] pgaccess and RH 6.0? - Mailing list pgsql-interfaces
From | Tom Lane |
---|---|
Subject | Re: [INTERFACES] pgaccess and RH 6.0? |
Date | |
Msg-id | 23913.930269292@sss.pgh.pa.us Whole thread Raw |
In response to | Re: [INTERFACES] pgaccess and RH 6.0? (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
List | pgsql-interfaces |
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
pgsql-interfaces by date: