pgxs/windows

SOme time ago I wrote:

... seems to be behaving oddly:

dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lpostgres

should we be pointing to the bin directory or the lib directory?

ISTR we've seen something like this before.

any thoughts?

I think I've got to the bottom of this.

Makefiles.win32 contains this:

ifdef PGXS
BE_DLLLIBS= -L$(DESTDIR)$(bindir) -lpostgres
else
BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres
endif

However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
$(DESTDIR)/$(libdir) and when I make that change in the installed
makefile my module builds happily.

My question is: if I make this change will anything else break?
Alternatively, should we have both in this line? I see the cygwin
makefile has a similar line. I haven't tried with cygwin because I am
waiting for the upcoming cygwin release - my install is currently busted.

I also had to filter out -Wdeclaration-after-statement and
-Wendif-labels from the CFLAGS, since they are not supported by my
compiler. This is a bit of a PGXS gotcha, ISTM - we use the CFLAGS that
were detected as valid on the original build machine rather than the
current machine.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
$(DESTDIR)/$(libdir) and when I make that change in the installed
makefile my module builds happily.

My question is: if I make this change will anything else break?

Offhand that seems like it may just be a thinko in the original makefile
coding. Has anyone tried to use PGXS on windows before?

I also had to filter out -Wdeclaration-after-statement and
-Wendif-labels from the CFLAGS, since they are not supported by my
compiler. This is a bit of a PGXS gotcha, ISTM - we use the CFLAGS that
were detected as valid on the original build machine rather than the
current machine.

In general you are supposed to use the same compiler as the installation
was built with. We are not going to try to support other cases ---
CFLAGS are barely the tip of the iceberg of the issues that would arise.

regards, tom lane

However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
$(DESTDIR)/$(libdir) and when I make that change in the installed
makefile my module builds happily.

My question is: if I make this change will anything else break?

Offhand that seems like it may just be a thinko in the
original makefile coding. Has anyone tried to use PGXS on
windows before?

I have, it works for me. I get for example:

dlltool --export-all --output-def dblink-ldap.def dblink-ldap.o
dllwrap -o libdblink-ldap.dll --dllname libdblink-ldap.dll --def
dblink-ldap.def dblink-ldap.o -LD:/msys/1.0/local/pgsql/bin
-LD:/msys/1.0/local/pgsql/lib -L/f/krb5/lib/i386/mingw -lwldap32
-lpostgres
dlltool --dllname libdblink-ldap.dll --def dblink-ldap.def --output-lib
libdblink-ldap.a

As you see, it adds both bin and lib. This is from a fresh cvs install
on my local msys - not installed from installer, and all building is
from msys.

That said, it still doesn't look right in the makefile :-)

//Magnus

Magnus Hagander wrote:

However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
$(DESTDIR)/$(libdir) and when I make that change in the installed
makefile my module builds happily.

My question is: if I make this change will anything else break?

Offhand that seems like it may just be a thinko in the
original makefile coding. Has anyone tried to use PGXS on
windows before?

I have, it works for me. I get for example:

dlltool --export-all --output-def dblink-ldap.def dblink-ldap.o
dllwrap -o libdblink-ldap.dll --dllname libdblink-ldap.dll --def
dblink-ldap.def dblink-ldap.o -LD:/msys/1.0/local/pgsql/bin
-LD:/msys/1.0/local/pgsql/lib -L/f/krb5/lib/i386/mingw -lwldap32
-lpostgres
dlltool --dllname libdblink-ldap.dll --def dblink-ldap.def --output-lib
libdblink-ldap.a

As you see, it adds both bin and lib. This is from a fresh cvs install
on my local msys - not installed from installer, and all building is
from msys.

That said, it still doesn't look right in the makefile :-)

Well, the whole point was to test against postgres from the installer -
that case sure didn't work, as the output I posted showed.

I suggest I change HEAD and we test - if nothing breaks we can backport it.

cheers

andrew

"Magnus Hagander" <mha@sollentuna.net> writes:

As you see, it adds both bin and lib.

Is the bin part even necessary?

It looks to me like the -L for libdir is coming from Makefile.global.in:

# add location of libpgport.a to LDFLAGS
ifdef PGXS
override LDFLAGS := -L$(libdir) $(LDFLAGS)
else
override LDFLAGS := -L$(top_builddir)/src/port $(LDFLAGS)
endif

Comparing that to the code in Makefile.win32, one of them is wrong
about the need for $(DESTDIR). Perhaps that has something to do with
it not working for Andrew?

regards, tom lane

Tom Lane wrote:

In general you are supposed to use the same compiler as the installation
was built with. We are not going to try to support other cases ---
CFLAGS are barely the tip of the iceberg of the issues that would arise.

Right down to the version? I know we can get that from select version(),
but maybe we should output that from pg_config also.

cheers

andrew

Tom Lane wrote:

"Magnus Hagander" <mha@sollentuna.net> writes:

As you see, it adds both bin and lib.

Is the bin part even necessary?

It looks to me like the -L for libdir is coming from Makefile.global.in:

# add location of libpgport.a to LDFLAGS
ifdef PGXS
override LDFLAGS := -L$(libdir) $(LDFLAGS)
else
override LDFLAGS := -L$(top_builddir)/src/port $(LDFLAGS)
endif

Comparing that to the code in Makefile.win32, one of them is wrong
about the need for $(DESTDIR). Perhaps that has something to do with
it not working for Andrew?

I doubt DESTDIR is having an effect. From what I can see we hardly use
it so it will mostly be blank:

[andrew@alphonso pgsql.head]$ grep -r DESTDIR.\*= .
./src/test/regress/pg_regress.sh: $GMAKE -C "$top_builddir"
DESTDIR="$temp_install/install" install with_perl=no with_python=no

"$LOGDIR/install.log" 2>&1

[andrew@alphonso pgsql.head]$

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

I doubt DESTDIR is having an effect. From what I can see we hardly use
it so it will mostly be blank:

Yes, it is often an empty string, which doubtless explains how an error
of this sort could sneak in. But I think there's no doubt that one or
the other of those definitions is wrong. I'm not completely sure which
though. DESTDIR should be included if we are referencing the
installation tree at build time, but perhaps not for post-install
purposes, which is the environment that PGXS should deal with.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

I doubt DESTDIR is having an effect. From what I can see we hardly use
it so it will mostly be blank:

Yes, it is often an empty string, which doubtless explains how an error
of this sort could sneak in. But I think there's no doubt that one or
the other of those definitions is wrong. I'm not completely sure which
though. DESTDIR should be included if we are referencing the
installation tree at build time, but perhaps not for post-install
purposes, which is the environment that PGXS should deal with.

Right.

So we should probably change $(DESTDIR)$(bindir) to $(libdir) in the
following places:

Makefile.aix:BE_DLLLIBS=
-Wl,-bI:$(DESTDIR)$(bindir)/postgres/$(POSTGRES_IMP)
Makefile.cygwin:BE_DLLLIBS= -L$(DESTDIR)$(bindir) -lpostgres
Makefile.darwin:BE_DLLLIBS= -bundle_loader $(DESTDIR)$(bindir)/postgres
Makefile.win32:BE_DLLLIBS= -L$(DESTDIR)$(bindir) -lpostgres

But I'm punting slightly on AIX and Darwin, as I know nothing of
building there.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

So we should probably change $(DESTDIR)$(bindir) to $(libdir) in the
following places:

For the cygwin/win32 cases, shouldn't we just remove the -L flag from
BE_DLLLIBS altogether? It seems redundant given what Makefile.global
is doing.

In the Darwin case, it should still be $(bindir) because we are pointing
at the postgres executable, not a library file. I agree that $(DESTDIR)
probably should go away though.

Dunno about AIX --- anyone familiar with that port?

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

So we should probably change $(DESTDIR)$(bindir) to $(libdir) in the
following places:

For the cygwin/win32 cases, shouldn't we just remove the -L flag from
BE_DLLLIBS altogether? It seems redundant given what Makefile.global
is doing.

We don't seem to pick that up. Not sure why. building my pgxs module on
mingw I just get:

-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres

That's the one from BE_DLLLIBS.

dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
either.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
either.

I wouldn't expect it to handle everything that might appear in LDFLAGS,
but maybe it ought to be given the -L items from LDFLAGS (compare the
way we copy just those items into SHLIB_LINK).

What's confusing me at the moment is that it seems to work for Magnus.
Are you maybe working from different source trees? I believe we changed
around the handling of these switches recently. Maybe in his copy, the
-L items from LDFLAGS are making it into the dllwrap command via
SHLIB_LINK.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
either.

I wouldn't expect it to handle everything that might appear in LDFLAGS,
but maybe it ought to be given the -L items from LDFLAGS (compare the
way we copy just those items into SHLIB_LINK).

What's confusing me at the moment is that it seems to work for Magnus.
Are you maybe working from different source trees? I believe we changed
around the handling of these switches recently. Maybe in his copy, the
-L items from LDFLAGS are making it into the dllwrap command via
SHLIB_LINK.

I am working against 8.1 from the installer - he is working against a
local mingw install.

Also, he might be working from a later toolset - I have gcc3.2.4 while
gcc 3.4.2 is the latest mingw release - some other tools might also be
mildly out of date.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

What's confusing me at the moment is that it seems to work for Magnus.

Also, he might be working from a later toolset - I have gcc3.2.4 while
gcc 3.4.2 is the latest mingw release - some other tools might also be
mildly out of date.

I can't imagine any way that gcc version differences would affect the
way that the Makefiles build command lines. There's something strange
going on here, and we ought to make sure we understand exactly what it
is before we try to fix it.

regards, tom lane

Andrew Dunstan wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
either.

I wouldn't expect it to handle everything that might appear in LDFLAGS,
but maybe it ought to be given the -L items from LDFLAGS (compare the
way we copy just those items into SHLIB_LINK).

What's confusing me at the moment is that it seems to work for Magnus.
Are you maybe working from different source trees? I believe we changed
around the handling of these switches recently. Maybe in his copy, the
-L items from LDFLAGS are making it into the dllwrap command via
SHLIB_LINK.

I am working against 8.1 from the installer - he is working against a
local mingw install.

Also, he might be working from a later toolset - I have gcc3.2.4 while
gcc 3.4.2 is the latest mingw release - some other tools might also be
mildly out of date.

Could this be related to the fact that pre-8.2 makefiles were not
space-safe? I am unsure how pgxs worked on Win32 without being
space-safe.

-- 
  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, Pennsylvania 19073

Bruce Momjian wrote:

Could this be related to the fact that pre-8.2 makefiles were not
space-safe? I am unsure how pgxs worked on Win32 without being
space-safe.

I don't see how. In fact, pgxs seems to use short form paths anyway.
Example (from previous email):

dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres

No spaces there. The problem is it says "bin" instead of "lib" before
"-lpostgres".

cheers

andrew

Andrew Dunstan wrote:

Bruce Momjian wrote:

Could this be related to the fact that pre-8.2 makefiles were not
space-safe? I am unsure how pgxs worked on Win32 without being
space-safe.

I don't see how. In fact, pgxs seems to use short form paths anyway.
Example (from previous email):

dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres

No spaces there. The problem is it says "bin" instead of "lib" before
"-lpostgres".

OK, thanks. Next question --- are the installed file locations the same
for a MinGW install and a pginstaller install? I don't think
pginstaller does a MinGW install because it doesn't have the build
environment in the tarball.

However, the big difference seems to be that Magnus has -Llib and -Lbin,
while you have only the -Lbin. I have MinGW and pginstaller installed
here. How can I set things up to test this?

-- 
  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, Pennsylvania 19073

Bruce Momjian wrote:

Andrew Dunstan wrote:

Bruce Momjian wrote:

Could this be related to the fact that pre-8.2 makefiles were not
space-safe? I am unsure how pgxs worked on Win32 without being
space-safe.

I don't see how. In fact, pgxs seems to use short form paths anyway.
Example (from previous email):

dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres

No spaces there. The problem is it says "bin" instead of "lib" before
"-lpostgres".

OK, thanks. Next question --- are the installed file locations the same
for a MinGW install and a pginstaller install? I don't think
pginstaller does a MinGW install because it doesn't have the build
environment in the tarball.

However, the big difference seems to be that Magnus has -Llib and -Lbin,
while you have only the -Lbin. I have MinGW and pginstaller installed
here. How can I set things up to test this?

Now looking at the Makefile.global in the 8.1.2 pginstaller install, in
Makefile.global, $libdir is set in a pgxs-specific block:

libdir := $(shell pg_config --libdir)

and that seems to work:

C:\Program Files\PostgreSQL\8.1\bin>pg_config --libdir
C:/PROGRA~1/POSTGR~1/8.1/lib

and that is set to LDFLAGS, which is later propogated to SHLIB_LINK,
though SHLIB_LINK moves all the -L flags to the front, so what you see
on the link line is not the ordering used to create the value.

Andrew, can you try echoing $libdir and $SHLIB_LINK in the Makefile to
find those values?

-- 
  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, Pennsylvania 19073

Bruce Momjian wrote:

OK, thanks. Next question --- are the installed file locations the same
for a MinGW install and a pginstaller install? I don't think
pginstaller does a MinGW install because it doesn't have the build
environment in the tarball.

However, the big difference seems to be that Magnus has -Llib and -Lbin,
while you have only the -Lbin. I have MinGW and pginstaller installed
here. How can I set things up to test this?

Now looking at the Makefile.global in the 8.1.2 pginstaller install, in
Makefile.global, $libdir is set in a pgxs-specific block:

libdir := $(shell pg_config --libdir)

and that seems to work:

C:\Program Files\PostgreSQL\8.1\bin>pg_config --libdir
C:/PROGRA~1/POSTGR~1/8.1/lib

and that is set to LDFLAGS, which is later propogated to SHLIB_LINK,
though SHLIB_LINK moves all the -L flags to the front, so what you see
on the link line is not the ordering used to create the value.

Andrew, can you try echoing $libdir and $SHLIB_LINK in the Makefile to
find those values?

here is a test case log (including a test makefile). I ran the tests as
you can see with both installer 8.1 and mingw installed CVS tip, with
the same results.

cheers

andrew

$ touch foo.c
$ cat Makefile

MODULES = foo
SRCS += foo.c
OBJS = $(SRCS:.c=.o)
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
override CFLAGS := $(filter-out -Wendif-labels
-Wdeclaration-after-statement, $(shell pg_config --cflags))
showme:
@echo libdir = $(libdir)
@echo SHLIB_LINK = $(SHLIB_LINK)
$ which pg_config
/c/Program Files/PostgreSQL/8.1/bin/pg_config
$ rm -f foo.dll
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -I. -Ic:/PROGRA~1/POSTGR~1/8.1/include/server
-Ic:/PROGRA~1/POSTGR~1/8.1/include/internal -I./src/include/port/win32
-DEXEC_BACKEND -I/mingw/include/krb5
"-Ic:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/include/port/win32"
-Ic:/PROGRA~1/POSTGR~1/8.1/include/server/port/win32 -c -o foo.o foo.c
dlltool --export-all --output-def foo.def foo.o
dllwrap -o foo.dll --def foo.def foo.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lpostgres
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
make: *** [foo.dll] Error 1
rm foo.o
$ make showme
libdir = c:/PROGRA~1/POSTGR~1/8.1/lib
SHLIB_LINK = -Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
$ export PATH=/usr/local/pgsql/bin:$PATH
$ which pg_config
/usr/local/pgsql/bin/pg_config
$ rm -f foo.dll
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -I. -IC:/msys/1.0/local/pgsql/include/server
-IC:/msys/1.0/local/pgsql/include/internal -I./src/include/port/win32
-DEXEC_BACKEND
"-IC:/msys/1.0/local/pgsql/lib/pgxs/src/MAKEFI~1/../../src/include/port/win32"
-IC:/msys/1.0/local/pgsql/include/server/port/win32 -c -o foo.o foo.c
dlltool --export-all --output-def foo.def foo.o
dllwrap -o foo.dll --def foo.def foo.o
C:/msys/1.0/local/pgsql/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-LC:/msys/1.0/local/pgsql/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lpostgres
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
make: *** [foo.dll] Error 1
rm foo.o
$ make showme
libdir = C:/msys/1.0/local/pgsql/lib
SHLIB_LINK = -LC:/msys/1.0/local/pgsql/bin -lpostgres

OK, I found the cause. Using tests from Magnus and Andrew, I could
reproduce Magnus's success and Andrew's failure in an 8.1.2 pginstaller
install using MinGW. The difference between Magnus's and Andrew's is
that Magnus used MODULE_big (which means create a shared library), while
Andrew used MODULES. So, Magnus's only worked because he was creating a
DLL and that brought in the -L from MODULE_big.

I have applied the following patch to change /bin to /lib for Cygwin and
Win32. Looking at Darwin and AIX, both those are pointing to the
postgres binary, so they should be using /bin, so we are OK on those.

I patched CVS HEAD, and 8.1.X and 8.0.X. Earlier releases didn't
support pgxs.

---------------------------------------------------------------------------

Andrew Dunstan wrote:

Bruce Momjian wrote:

OK, thanks. Next question --- are the installed file locations the same
for a MinGW install and a pginstaller install? I don't think
pginstaller does a MinGW install because it doesn't have the build
environment in the tarball.

However, the big difference seems to be that Magnus has -Llib and -Lbin,
while you have only the -Lbin. I have MinGW and pginstaller installed
here. How can I set things up to test this?

Now looking at the Makefile.global in the 8.1.2 pginstaller install, in
Makefile.global, $libdir is set in a pgxs-specific block:

libdir := $(shell pg_config --libdir)

and that seems to work:

C:\Program Files\PostgreSQL\8.1\bin>pg_config --libdir
C:/PROGRA~1/POSTGR~1/8.1/lib

and that is set to LDFLAGS, which is later propogated to SHLIB_LINK,
though SHLIB_LINK moves all the -L flags to the front, so what you see
on the link line is not the ordering used to create the value.

Andrew, can you try echoing $libdir and $SHLIB_LINK in the Makefile to
find those values?

here is a test case log (including a test makefile). I ran the tests as
you can see with both installer 8.1 and mingw installed CVS tip, with
the same results.

cheers

andrew

$ touch foo.c
$ cat Makefile

MODULES = foo
SRCS += foo.c
OBJS = $(SRCS:.c=.o)
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
override CFLAGS := $(filter-out -Wendif-labels
-Wdeclaration-after-statement, $(shell pg_config --cflags))
showme:
@echo libdir = $(libdir)
@echo SHLIB_LINK = $(SHLIB_LINK)
$ which pg_config
/c/Program Files/PostgreSQL/8.1/bin/pg_config
$ rm -f foo.dll
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -I. -Ic:/PROGRA~1/POSTGR~1/8.1/include/server
-Ic:/PROGRA~1/POSTGR~1/8.1/include/internal -I./src/include/port/win32
-DEXEC_BACKEND -I/mingw/include/krb5
"-Ic:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/include/port/win32"
-Ic:/PROGRA~1/POSTGR~1/8.1/include/server/port/win32 -c -o foo.o foo.c
dlltool --export-all --output-def foo.def foo.o
dllwrap -o foo.dll --def foo.def foo.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lpostgres
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
make: *** [foo.dll] Error 1
rm foo.o
$ make showme
libdir = c:/PROGRA~1/POSTGR~1/8.1/lib
SHLIB_LINK = -Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
$ export PATH=/usr/local/pgsql/bin:$PATH
$ which pg_config
/usr/local/pgsql/bin/pg_config
$ rm -f foo.dll
$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -I. -IC:/msys/1.0/local/pgsql/include/server
-IC:/msys/1.0/local/pgsql/include/internal -I./src/include/port/win32
-DEXEC_BACKEND
"-IC:/msys/1.0/local/pgsql/lib/pgxs/src/MAKEFI~1/../../src/include/port/win32"
-IC:/msys/1.0/local/pgsql/include/server/port/win32 -c -o foo.o foo.c
dlltool --export-all --output-def foo.def foo.o
dllwrap -o foo.dll --def foo.def foo.o
C:/msys/1.0/local/pgsql/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-LC:/msys/1.0/local/pgsql/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lpostgres
c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
make: *** [foo.dll] Error 1
rm foo.o
$ make showme
libdir = C:/msys/1.0/local/pgsql/lib
SHLIB_LINK = -LC:/msys/1.0/local/pgsql/bin -lpostgres

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  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, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The difference between Magnus's and Andrew's is
that Magnus used MODULE_big (which means create a shared library), while
Andrew used MODULES. So, Magnus's only worked because he was creating a
DLL and that brought in the -L from MODULE_big.

Ah, good catch.

I have applied the following patch to change /bin to /lib for Cygwin and
Win32.

What about the question of whether $(DESTDIR) belongs there or not?
I think we had concluded that PGXS shouldn't ever use $(DESTDIR),
because that's only for install-time stuff.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The difference between Magnus's and Andrew's is
that Magnus used MODULE_big (which means create a shared library), while
Andrew used MODULES. So, Magnus's only worked because he was creating a
DLL and that brought in the -L from MODULE_big.

Ah, good catch.

I have applied the following patch to change /bin to /lib for Cygwin and
Win32.

What about the question of whether $(DESTDIR) belongs there or not?
I think we had concluded that PGXS shouldn't ever use $(DESTDIR),
because that's only for install-time stuff.

I considered that a separate issue and didn't explore it, but I think
you are right that $(DESTDIR) makes no sense so I will remove it.

Patch attached.

-- 
  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, Pennsylvania 19073

On Thu, 2006-01-19 at 15:33 -0500, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

The difference between Magnus's and Andrew's is
that Magnus used MODULE_big (which means create a shared library), while
Andrew used MODULES. So, Magnus's only worked because he was creating a
DLL and that brought in the -L from MODULE_big.

Ah, good catch.

As I understand the docs, one can use either to produce a dll. The
difference is how it processes the name.

I have applied the following patch to change /bin to /lib for Cygwin and
Win32.

What about the question of whether $(DESTDIR) belongs there or not?
I think we had concluded that PGXS shouldn't ever use $(DESTDIR),
because that's only for install-time stuff.

Looks that way to me - IIRC it's only used by the regression suite.

cheers

andrew

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

What about the question of whether $(DESTDIR) belongs there or not?
I think we had concluded that PGXS shouldn't ever use $(DESTDIR),
because that's only for install-time stuff.

I considered that a separate issue and didn't explore it, but I think
you are right that $(DESTDIR) makes no sense so I will remove it.

Patch attached.

If these are bogus then so are the uses in Makefile.aix and
Makefile.darwin.

I'm a bit bothered by the ones in pgxs.mk, too, although I suspect we
have to leave those there for the benefit of contrib?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

What about the question of whether $(DESTDIR) belongs there or not?
I think we had concluded that PGXS shouldn't ever use $(DESTDIR),
because that's only for install-time stuff.

I considered that a separate issue and didn't explore it, but I think
you are right that $(DESTDIR) makes no sense so I will remove it.

Patch attached.

If these are bogus then so are the uses in Makefile.aix and
Makefile.darwin.

Done, and backpatched.

I'm a bit bothered by the ones in pgxs.mk, too, although I suspect we
have to leave those there for the benefit of contrib?

No idea, sorry.

-- 
  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, Pennsylvania 19073