Postgres Pro
Downloads
Home   >   mailing lists

Thread: Problems with pgxs

Problems with pgxs

From
Thomas Hallgren
Date:
I have some problems when adjusting PL/Java to use PGXS in its 
makefiles. Aside from the Win32 problem I asked about earlier, I also 
have problems using the MODULE_big. When used, it brings in the 
Makefile.shlib and attempts to use the target all-lib. That target is 
defined as:
    all-lib: all-static-lib all-shared-lib
    all-static-lib: $(PTHREAD_H_WIN32)        $(top_builddir)/src/port/pg_config_paths.h lib$(NAME).a
    all-shared-lib: $(PTHREAD_H_WIN32)        $(top_builddir)/src/port/pg_config_paths.h $(shlib)

but the $(top_builddir)/src/port directory is non existant in PostgreSQL 
installation.

I'm not sure if I use pgxs in a completely wrong way or if pgxs needs 
some more work before I can rely on it. Are there any other projects out 
there that have their source completely separate from the PostgreSQL 
source that uses PGXS succesfully? If so, your input on this subject is 
greatly appreciated.

Kind regards,
Thomas Hallgren

Re: Problems with pgxs

From
Tom Lane
Date:
Thomas Hallgren <thhal@mailblocks.com> writes:
> [ Makefile.shlib contains ]

>      all-lib: all-static-lib all-shared-lib

>      all-static-lib: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h lib$(NAME).a

>      all-shared-lib: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h $(shlib)

Would someone explain to me what in the world these targets are doing
demanding either of those as prerequisite?  They certainly did not have
those prereqs in 7.4.  This seems an excessively klugy way of handling
some Windows brokenness or other.
        regards, tom lane

Re: Problems with pgxs

From
Bruce Momjian
Date:
Tom Lane wrote:
> Thomas Hallgren <thhal@mailblocks.com> writes:
> > [ Makefile.shlib contains ]
> 
> >      all-lib: all-static-lib all-shared-lib
> 
> >      all-static-lib: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h lib$(NAME).a
> 
> >      all-shared-lib: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h $(shlib)
> 
> Would someone explain to me what in the world these targets are doing
> demanding either of those as prerequisite?  They certainly did not have
> those prereqs in 7.4.  This seems an excessively klugy way of handling
> some Windows brokenness or other.

$(PTHREAD_H_WIN32) is a dependency of libpq and therefore we had to copy
it into Makefile.shlib when we are compiling from that file rather than
libpq/Makefile.  libpq/Makefile has:
 all: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h def-files all-lib

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073

Re: Problems with pgxs

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> $(PTHREAD_H_WIN32) is a dependency of libpq and therefore we had to copy
> it into Makefile.shlib when we are compiling from that file rather than
> libpq/Makefile.  libpq/Makefile has:

>   all: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h def-files all-lib

Say again?  Why should libpq's dependencies be propagated to every shlib
in the system?  And when is libpq built without using libpq/Makefile?
        regards, tom lane

Re: Problems with pgxs

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > $(PTHREAD_H_WIN32) is a dependency of libpq and therefore we had to copy
> > it into Makefile.shlib when we are compiling from that file rather than
> > libpq/Makefile.  libpq/Makefile has:
> 
> >   all: $(PTHREAD_H_WIN32) $(top_builddir)/src/port/pg_config_paths.h def-files all-lib
> 
> Say again?  Why should libpq's dependencies be propagated to every shlib
> in the system?  And when is libpq built without using libpq/Makefile?

No idea.  I just know it fixed the problem. The problem report was that
you could not build all-static-lib under MinGW.  I confirmed that using
my MinGW here and developed the following patch:****************** 245,253 ****  all-lib: all-static-lib
all-shared-lib!all-static-lib: lib$(NAME).a! all-shared-lib: $(shlib)  ifneq ($(PORTNAME), cygwin)  ifneq ($(PORTNAME),
win32)---245,253 ----  all-lib: all-static-lib all-shared-lib! all-static-lib: $(PTHREAD_H_WIN32)
$(top_srcdir)/src/port/pg_config_paths.hlib$(NAME).a! all-shared-lib: $(PTHREAD_H_WIN32)
$(top_srcdir)/src/port/pg_config_paths.h$(shlib)  ifneq ($(PORTNAME), cygwin)  ifneq ($(PORTNAME), win32)
 

The problem was that building libpq.a was not generating the include
file dependencies.  The cause I think is that we have a separate Win32
build rule for a static lib in Makefile.shlib:# win32 case$(shlib) lib$(NAME).a: $(OBJS)ifndef DLL_DEFFILE
$(DLLTOOL)--export-all $(DLLTOOL_DEFFLAGS) --output-def $(NAME).def $(OBJS)        $(DLLWRAP) $(LDFLAGS_SL) -o $(shlib)
--dllname$(shlib) $(DLLWRAP_FLAGS) --def $(NAME).def $(OBJS) $(SHLIB_LINK)        $(DLLTOOL) --dllname $(shlib)
$(DLLTOOL_LIBFLAGS)--def $(NAME).def --output-lib lib$(NAME).aelse        $(DLLWRAP) $(LDFLAGS_SL) -o $(shlib)
--dllname$(shlib) $(DLLWRAP_FLAGS) --def $(DLL_DEFFILE) $(OBJS) $(SHLIB_LINK)        $(DLLTOOL) --dllname $(shlib)
$(DLLTOOL_LIBFLAGS)--def $(DLL_DEFFILE) --output-lib lib$(NAME).aendif
 

and that rule discusses only the OBJ files and doesn't know about the
*.h files that are needed.

Ideas?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073