Re: pgxs/windows

> > 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(at)sollentuna(dot)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:

>"Magnus Hagander" <mha(at)sollentuna(dot)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(at)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(at)alphonso pgsql.head]$

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)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(at)dunslane(dot)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

> regards, tom lane
>
>
>

Andrew Dunstan <andrew(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073