Re: [INTERFACES] pgaccess and RH 6.0?

> >> 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California