Thread: pgxs/windows
... 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? cheers andrew
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 > regards, tom lane > > >
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, Pennsylvania19073
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, Pennsylvania19073
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 --libdirC:/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, Pennsylvania19073
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