Re: Re: pgsql + qnx

At 22:57 22.05.01 +0200, Peter Eisentraut wrote:
>Tegge, Bernd writes:
>
> > >The first line looks like a broken compiler installation. The second line
> > >should, if at all, go into the template file. But I don't like us using
> > >arbitrary include paths. If the compiler vendor decides to not go there
> > >by default they had a reason. In any case there would be an equivalent
> > >LDFLAGS setting missing. Also, -I options should go into CPPFLAGS.
> >
> > Could you elaborate ? I am not sure which template file you refer to.
>
>src/template/qnx4

Yes, I agree. That looks like a better place.

> > In case you are thinking of the gcc installation, I guess they could be
> > scrapped. However, Watcom does not search these directories by default.
> > In fact, IIRC a OOB QNX4 install does not even *have* a '/usr/local'. I
> > have included this because TCL and zlib install their headers there.
>
>Only if you tell them to install them there. Which is probably a
>reasonable thing to do, but since /usr/local is not considered an integral
>part of the system we shouldn't force it upon the user. It's just a
>matter of keeping things clean.

Well, if there is no /usr/local the flag will be silently ignored. If
someone really wants to install perl, tcl and zlib in non standard
locations he'll have to fiddle with the setup anyway. I wanted to provide
reasonable defaults that work with the rest of the binary packages mentioned
in the FAQ.
The correct way imho would be to let configure figure it out, but have I
have no idea how to implement that.

> > >The plpgsql issue should be fixed by making the ifneq
> > >($(enable_shared),yes) sections in plpgsql/src/Makefile cover the parts
> > >you don't want to execute. That's what it is for, it just hasn't been
> > >exercised yet.
> >
> > Not really, it's because building the static library kills wlib. It is
> > a platform specific problem similar to the hack in backend/Makefile.
> > Of course I could make this dependant on enable_shared, but I don't like
> > using two different flags to work around the same bug.
>
>I see. But the static lib is kind of useless in this case, so we could
>turn it all off and get rid of the wlib problem at the same time?

That is exactly what I wanted to achieve. There is no reason to even compile
the plpgsql sources at the moment on QNX4. I suppose I could move the hack
into the plpgsql Makefile but that is somewhat tricky because the all-lib
target for building the static lib is in $src/Makefile.shlib:

*** postgresql-7.1.1/src/pl/plpgsql/src/Makefile Fri Apr 6 16:36:36 2001
--- postgresql-7.1.1.qnx4/src/pl/plpgsql/src/Makefile Wed May 23 11:13:50 2001
***************
*** 21,32 ****

OBJS = pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o

all: all-lib

# Shared library stuff
include $(top_srcdir)/src/Makefile.shlib
!
!
# In order to use Makefile.shlib, we allow it to build a static
# library libplpgsql.a, which we just ignore, as well as a shared
# library that it will insist on naming $(shlib). We don't want to
--- 21,37 ----

OBJS = pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o

+ ifeq ($(PORTNAME), qnx4)
all: all-lib

# Shared library stuff
include $(top_srcdir)/src/Makefile.shlib
! else
! all:
! @echo "*****"; \
! echo "* PL/pgSQL was not built due to library manager problems."; \
! echo "*****"
! endif
# In order to use Makefile.shlib, we allow it to build a static
# library libplpgsql.a, which we just ignore, as well as a shared
# library that it will insist on naming $(shlib). We don't want to

*** postgresql-7.1.1/src/template/qnx4 Tue Oct 31 19:16:20 2000
--- postgresql-7.1.1.qnx4/src/template/qnx4 Wed May 23 11:30:55 2001
***************
*** 1,2 ****
! CFLAGS=
LIBS=-lunix
--- 1,2 ----
! CFLAGS=-I/usr/local/include
LIBS=-lunix