Re: [INTERFACES] pgaccess and RH 6.0?

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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