Обсуждение: PostgreSQL 9.5 Alpha 1 build fail with perl 5.22
On 7/2/2015 5:16 PM, Dave Page wrote: > The PostgreSQL Global Development Group announces that the alpha > release of PostgreSQL 9.5, the latest version of the world's leading > open source database, is available today. This release contains > previews of all of the features which will be available in the final > release of version 9.5, although some details will change before then. > Please download, test, and report what you find. > > Help Test for Bugs > ------------------ building on cygwin and $ perl --version This is perl 5, version 22, subversion 0 (v5.22.0) built for cygwin-thread-multi-64int build fail here, anyone seeing the same on other platforms ? make -C hstore_plperl all make[1]: Entering directory '/cygdrive/e/cyg_pub/devel/postgresql/prova/postgres ql-9.5alpha1-1.i686/build/contrib/hstore_plperl' gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -We ndif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -f wrapv -fexcess-precision=standard-ggdb -O2 -pipe -Wimplicit-function-declaratio n -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5a lpha1/src/pl/plperl -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr c/postgresql-9.5alpha1/contrib/hstore -I. -I/pub/devel/postgresql/prova/postgres ql-9.5alpha1-1.i686/src/postgresql-9.5alpha1/contrib/hstore_plperl -I../../src/i nclude -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql- 9.5alpha1/src/include -I/usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE -c -o hstore_plperl.o /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/p ostgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c In file included from /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:6:0: /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 /contrib/hstore/hstore.h:79:0:warning: "HS_KEY" redefined #define HS_KEY(arr_,str_,i_) ((str_) + HSE_OFF((arr_)[2*(i_)])) ^ In file included from /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/perl.h: 3730:0, from /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr c/postgresql-9.5alpha1/src/pl/plperl/plperl.h:48, from /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:4: /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/util.h:221:0: note: this is t he location of the previous definition # define HS_KEY(setxsubfn, popmark, apiver, xsver)\ ^ gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -We ndif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -f wrapv -fexcess-precision=standard-ggdb -O2 -pipe -Wimplicit-function-declaratio n -shared -o hstore_plperl.dll -Wl,--out-implib=libhstore_plperl.a hstore_plpe rl.o -L../../src/port -L../../src/common -Wl,-no-undefined -Wl,--allow-multiple -definition -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed -L../.. /src/backend -lpostgres -lpgcommon -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lldap hstore_plperl.o: In function `hstore_to_plperl': /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 /contrib/hstore_plperl/hstore_plperl.c:16: undefined reference to `hstoreUpgrade '
On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri <marco.atzeri@gmail.com> wrote: > On 7/2/2015 5:16 PM, Dave Page wrote: >> >> The PostgreSQL Global Development Group announces that the alpha >> release of PostgreSQL 9.5, the latest version of the world's leading >> open source database, is available today. This release contains >> previews of all of the features which will be available in the final >> release of version 9.5, although some details will change before then. >> Please download, test, and report what you find. >> >> Help Test for Bugs >> ------------------ > > > > > building on cygwin and > > $ perl --version > > This is perl 5, version 22, subversion 0 (v5.22.0) built for > cygwin-thread-multi-64int > > build fail here, anyone seeing the same on other platforms ? > > make -C hstore_plperl all > make[1]: Entering directory > '/cygdrive/e/cyg_pub/devel/postgresql/prova/postgres > ql-9.5alpha1-1.i686/build/contrib/hstore_plperl' > gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -We ndif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -f wrapv > -fexcess-precision=standard -ggdb -O2 -pipe -Wimplicit-function-declaratio > n > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5a > lpha1/src/pl/plperl > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore -I. > -I/pub/devel/postgresql/prova/postgres > ql-9.5alpha1-1.i686/src/postgresql-9.5alpha1/contrib/hstore_plperl > -I../../src/i nclude > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql- > 9.5alpha1/src/include -I/usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE > -c -o hstore_plperl.o > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/p > ostgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c > In file included from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:6:0: > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 > /contrib/hstore/hstore.h:79:0: warning: "HS_KEY" redefined > #define HS_KEY(arr_,str_,i_) ((str_) + HSE_OFF((arr_)[2*(i_)])) > ^ > In file included from > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/perl.h: > 3730:0, > from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/src/pl/plperl/plperl.h:48, > from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:4: > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/util.h:221:0: note: this > is t he location of the previous definition > # define HS_KEY(setxsubfn, popmark, apiver, xsver) \ > ^ > gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -We ndif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -f wrapv > -fexcess-precision=standard -ggdb -O2 -pipe -Wimplicit-function-declaratio > n -shared -o hstore_plperl.dll -Wl,--out-implib=libhstore_plperl.a > hstore_plpe rl.o -L../../src/port > -L../../src/common -Wl,-no-undefined -Wl,--allow-multiple > -definition -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed > -L../.. /src/backend -lpostgres -lpgcommon > -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt > -lldap > hstore_plperl.o: In function `hstore_to_plperl': > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 > /contrib/hstore_plperl/hstore_plperl.c:16: undefined reference to > `hstoreUpgrade ' Hm. dangomushi is using perl 5.22 and the build does not fail: -- Michael
On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri <marco.atzeri@gmail.com> wrote: > On 7/2/2015 5:16 PM, Dave Page wrote: >> >> The PostgreSQL Global Development Group announces that the alpha >> release of PostgreSQL 9.5, the latest version of the world's leading >> open source database, is available today. This release contains >> previews of all of the features which will be available in the final >> release of version 9.5, although some details will change before then. >> Please download, test, and report what you find. >> >> Help Test for Bugs >> ------------------ > > > > > building on cygwin and > > $ perl --version > > This is perl 5, version 22, subversion 0 (v5.22.0) built for > cygwin-thread-multi-64int > > build fail here, anyone seeing the same on other platforms ? > > make -C hstore_plperl all > make[1]: Entering directory > '/cygdrive/e/cyg_pub/devel/postgresql/prova/postgres > ql-9.5alpha1-1.i686/build/contrib/hstore_plperl' > gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -We ndif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -f wrapv > -fexcess-precision=standard -ggdb -O2 -pipe -Wimplicit-function-declaratio > n > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5a > lpha1/src/pl/plperl > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore -I. > -I/pub/devel/postgresql/prova/postgres > ql-9.5alpha1-1.i686/src/postgresql-9.5alpha1/contrib/hstore_plperl > -I../../src/i nclude > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql- > 9.5alpha1/src/include -I/usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE > -c -o hstore_plperl.o > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/p > ostgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c > In file included from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:6:0: > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 > /contrib/hstore/hstore.h:79:0: warning: "HS_KEY" redefined > #define HS_KEY(arr_,str_,i_) ((str_) + HSE_OFF((arr_)[2*(i_)])) > ^ > In file included from > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/perl.h: > 3730:0, > from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/src/pl/plperl/plperl.h:48, > from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:4: > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/util.h:221:0: note: this > is t he location of the previous definition > # define HS_KEY(setxsubfn, popmark, apiver, xsver) \ > ^ > gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -We ndif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -f wrapv > -fexcess-precision=standard -ggdb -O2 -pipe -Wimplicit-function-declaratio > n -shared -o hstore_plperl.dll -Wl,--out-implib=libhstore_plperl.a > hstore_plpe rl.o -L../../src/port > -L../../src/common -Wl,-no-undefined -Wl,--allow-multiple > -definition -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed > -L../.. /src/backend -lpostgres -lpgcommon > -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt > -lldap > hstore_plperl.o: In function `hstore_to_plperl': > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 > /contrib/hstore_plperl/hstore_plperl.c:16: undefined reference to > `hstoreUpgrade ' So... dangomushi is able to build it at least. Here are the logs to the last build for example: http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=dangomushi&dt=2015-07-02%2019%3A19%3A39&stg=make-contrib What is the name of the library generated in hstore? Perhaps there is a mismatch here. -- Michael
On 7/3/2015 8:19 AM, Michael Paquier wrote: > On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri <marco.atzeri@gmail.com> wrote: >> On 7/2/2015 5:16 PM, Dave Page wrote: >>> >> -lldap >> hstore_plperl.o: In function `hstore_to_plperl': >> /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 >> /contrib/hstore_plperl/hstore_plperl.c:16: undefined reference to >> `hstoreUpgrade ' > > So... dangomushi is able to build it at least. Here are the logs to > the last build for example: > http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=dangomushi&dt=2015-07-02%2019%3A19%3A39&stg=make-contrib > What is the name of the library generated in hstore? Perhaps there is > a mismatch here. OK thanks for the feedback. It may be a cygwin perl specific issue. I will investigate Regards Marco
On 07/03/2015 01:47 AM, Marco Atzeri wrote: > On 7/2/2015 5:16 PM, Dave Page wrote: >> The PostgreSQL Global Development Group announces that the alpha >> release of PostgreSQL 9.5, the latest version of the world's leading >> open source database, is available today. This release contains >> previews of all of the features which will be available in the final >> release of version 9.5, although some details will change before then. >> Please download, test, and report what you find. >> >> Help Test for Bugs >> ------------------ > > > > building on cygwin and > > $ perl --version > > This is perl 5, version 22, subversion 0 (v5.22.0) built for > cygwin-thread-multi-64int > > build fail here, anyone seeing the same on other platforms ? > > make -C hstore_plperl all > make[1]: Entering directory > '/cygdrive/e/cyg_pub/devel/postgresql/prova/postgres > ql-9.5alpha1-1.i686/build/contrib/hstore_plperl' > gcc -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -We ndif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -f > wrapv -fexcess-precision=standard -ggdb -O2 > -pipe -Wimplicit-function-declaratio n > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5a > lpha1/src/pl/plperl > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore -I. > -I/pub/devel/postgresql/prova/postgres > ql-9.5alpha1-1.i686/src/postgresql-9.5alpha1/contrib/hstore_plperl > -I../../src/i nclude > -I/pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql- > 9.5alpha1/src/include > -I/usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE -c > -o hstore_plperl.o > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/p > ostgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c > In file included from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:6:0: > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 > /contrib/hstore/hstore.h:79:0: warning: > "HS_KEY" redefined > #define HS_KEY(arr_,str_,i_) ((str_) + HSE_OFF((arr_)[2*(i_)])) > ^ > In file included from > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/perl.h: > 3730:0, > from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/src/pl/plperl/plperl.h:48, > from > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/sr > c/postgresql-9.5alpha1/contrib/hstore_plperl/hstore_plperl.c:4: > /usr/lib/perl5/5.22/i686-cygwin-threads-64int/CORE/util.h:221:0: note: > this is t he location of the previous > definition > # define HS_KEY(setxsubfn, popmark, apiver, xsver) \ > ^ > gcc -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -We ndif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -f > wrapv -fexcess-precision=standard -ggdb -O2 > -pipe -Wimplicit-function-declaratio n > -shared -o hstore_plperl.dll -Wl,--out-implib=libhstore_plperl.a > hstore_plpe rl.o -L../../src/port > -L../../src/common -Wl,-no-undefined -Wl,--allow-multiple > -definition -Wl,--enable-auto-import -L/usr/local/lib > -Wl,--as-needed -L../.. /src/backend > -lpostgres -lpgcommon -lpgport -lintl -lssl -lcrypto -lz -lreadline > -lcrypt -lldap > hstore_plperl.o: In function `hstore_to_plperl': > /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 > /contrib/hstore_plperl/hstore_plperl.c:16: undefined reference to > `hstoreUpgrade ' > > That #define clash is annoying, We should probably #undefine HS_KEY if it's defined before including hstore.h. cheers andrew
On 7/3/2015 2:31 PM, Marco Atzeri wrote: > On 7/3/2015 8:19 AM, Michael Paquier wrote: >> On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri <marco.atzeri@gmail.com> >> wrote: >>> On 7/2/2015 5:16 PM, Dave Page wrote: >>>> >>> -lldap >>> hstore_plperl.o: In function `hstore_to_plperl': >>> /pub/devel/postgresql/prova/postgresql-9.5alpha1-1.i686/src/postgresql-9.5alpha1 >>> >>> /contrib/hstore_plperl/hstore_plperl.c:16: undefined reference to >>> `hstoreUpgrade ' >> for what I see the hstore_plperl link has a double problem. It requires a link to hstore as it also requires a link to perl. Attached patch for solving this and a similar issue with python. Regards MArco
Вложения
Marco Atzeri <marco.atzeri@gmail.com> writes:
> for what I see the hstore_plperl link has a double problem.
> It requires a link to hstore
> as it also requires a link to perl.
> Attached patch for solving this and a similar issue with python.
> +ifeq ($(PORTNAME), cygwin)
> +# This means we need an in-tree build on Windows, not a pgxs build
> +SHLIB_LINK += -L../hstore -lhstore -L$(perl_archlibexp)/CORE -lperl
> +endif
> [ and likewise for the other contrib transform modules ]
I wondered how come we had not seen this problem in the buildfarm,
but the answer appears to be that our only working Cygwin critter
(brolga) doesn't build any of the optional PLs, so it skips these
modules altogether. Seems like we need to improve that situation.
Also, I noted that the "regular win32" path in these makefiles
says, eg,
ifeq ($(PORTNAME), win32)
# these settings are the same as for plperl
override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
# This means we need an in-tree build on Windows, not a pgxs build
SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plperl/libperl*.a)
endif
It's not apparent to me how that works at all. It seems to specify
hard-linking a copy of hstore as well as a copy of plperl into the
shlib for hstore_plperl. Then at runtime, there will *also* be the
hstore and plperl shlibs in memory. At best that means substantial
memory bloat, but it seems likely to me that it would fail altogether,
particular for plperl which has got a substantial amount of semantically-
important static storage. Two copies of that storage will not end well.
regards, tom lane
On 07/04/2015 11:02 AM, Tom Lane wrote: > Marco Atzeri <marco.atzeri@gmail.com> writes: >> for what I see the hstore_plperl link has a double problem. >> It requires a link to hstore >> as it also requires a link to perl. >> Attached patch for solving this and a similar issue with python. >> +ifeq ($(PORTNAME), cygwin) >> +# This means we need an in-tree build on Windows, not a pgxs build >> +SHLIB_LINK += -L../hstore -lhstore -L$(perl_archlibexp)/CORE -lperl >> +endif >> [ and likewise for the other contrib transform modules ] > I wondered how come we had not seen this problem in the buildfarm, > but the answer appears to be that our only working Cygwin critter > (brolga) doesn't build any of the optional PLs, so it skips these > modules altogether. Seems like we need to improve that situation. > > Also, I noted that the "regular win32" path in these makefiles > says, eg, > > ifeq ($(PORTNAME), win32) > # these settings are the same as for plperl > override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment > # This means we need an in-tree build on Windows, not a pgxs build > SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plperl/libperl*.a) > endif > > It's not apparent to me how that works at all. It seems to specify > hard-linking a copy of hstore as well as a copy of plperl into the > shlib for hstore_plperl. Then at runtime, there will *also* be the > hstore and plperl shlibs in memory. At best that means substantial > memory bloat, but it seems likely to me that it would fail altogether, > particular for plperl which has got a substantial amount of semantically- > important static storage. Two copies of that storage will not end well. > > Windows finds the DLL in its path. I just tested this by removing the intree pl DLLs after installing and then running contrib installcheck, and it worked fine. Whether or not it actually loads the DLL twice when it can find the intree DLL I don't know for sure, maybe someone with more Windows-fu than me can inform our ignorance. cheers andrew
On 07/04/2015 11:02 AM, Tom Lane wrote: > > I wondered how come we had not seen this problem in the buildfarm, > but the answer appears to be that our only working Cygwin critter > (brolga) doesn't build any of the optional PLs, so it skips these > modules altogether. Seems like we need to improve that situation. > > brolga has been on life support for quite a long time. The reason it hasn't been retired is that for a long time I was unable to get a buildfarm member running successfully on a more modern Cygwin. That now appears to have resolved itself, so in a week or so I will set up a Cygwin buildfarm member running on a modern Cygwin on Windows 8.1, and build with perl, python, openssl, libxml and libxslt. Note that I have only tested 32 bit Cygwin - 64-bit might well be a whole different story. cheers andrew
On 7/5/2015 11:35 PM, Andrew Dunstan wrote: > > On 07/04/2015 11:02 AM, Tom Lane wrote: >> >> I wondered how come we had not seen this problem in the buildfarm, >> but the answer appears to be that our only working Cygwin critter >> (brolga) doesn't build any of the optional PLs, so it skips these >> modules altogether. Seems like we need to improve that situation. >> >> > > brolga has been on life support for quite a long time. The reason it > hasn't been retired is that for a long time I was unable to get a > buildfarm member running successfully on a more modern Cygwin. That now > appears to have resolved itself, so in a week or so I will set up a > Cygwin buildfarm member running on a modern Cygwin on Windows 8.1, and > build with perl, python, openssl, libxml and libxslt. Note that I have > only tested 32 bit Cygwin - 64-bit might well be a whole different story. Hi Andrew, I have not seen any particular difference between the two cygwin flavors I am running both versions on my W7 64 bit. The only trick is to have two different names for the cygserver service to avoid collision. Those services are capable to run at the same time. E.G. from 64 bit point of view: $ cygrunsrv.exe -L (cygserver) cygserver64 (sshd) in brackets the 32bit services. Let me know if you need any support > cheers > > andrew Regards Marco
On 07/04/2015 01:09 PM, Andrew Dunstan wrote: > > On 07/04/2015 11:02 AM, Tom Lane wrote: >> Marco Atzeri <marco.atzeri@gmail.com> writes: >>> for what I see the hstore_plperl link has a double problem. >>> It requires a link to hstore >>> as it also requires a link to perl. >>> Attached patch for solving this and a similar issue with python. >>> +ifeq ($(PORTNAME), cygwin) >>> +# This means we need an in-tree build on Windows, not a pgxs build >>> +SHLIB_LINK += -L../hstore -lhstore -L$(perl_archlibexp)/CORE -lperl >>> +endif >>> [ and likewise for the other contrib transform modules ] >> I wondered how come we had not seen this problem in the buildfarm, >> but the answer appears to be that our only working Cygwin critter >> (brolga) doesn't build any of the optional PLs, so it skips these >> modules altogether. Seems like we need to improve that situation. >> >> Also, I noted that the "regular win32" path in these makefiles >> says, eg, >> >> ifeq ($(PORTNAME), win32) >> # these settings are the same as for plperl >> override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment >> # This means we need an in-tree build on Windows, not a pgxs build >> SHLIB_LINK += ../hstore/libhstore.a $(wildcard >> ../../src/pl/plperl/libperl*.a) >> endif >> >> It's not apparent to me how that works at all. It seems to specify >> hard-linking a copy of hstore as well as a copy of plperl into the >> shlib for hstore_plperl. Then at runtime, there will *also* be the >> hstore and plperl shlibs in memory. At best that means substantial >> memory bloat, but it seems likely to me that it would fail altogether, >> particular for plperl which has got a substantial amount of >> semantically- >> important static storage. Two copies of that storage will not end well. >> >> > > > > Windows finds the DLL in its path. I just tested this by removing the > intree pl DLLs after installing and then running contrib installcheck, > and it worked fine. Whether or not it actually loads the DLL twice > when it can find the intree DLL I don't know for sure, maybe someone > with more Windows-fu than me can inform our ignorance. > BTW, the .a files being linked to above are not like Unix .a static archives - they are import library files, which I think they are only used at link time, not run time. The path to the DLLs isn't being hardcoded. Unless there is further argument I propose to commit something very like Marco's suggestion for hstore_plperl, hstore_plpython and ltree_plpython cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
>> On 07/04/2015 11:02 AM, Tom Lane wrote:
>>> It's not apparent to me how that works at all.
> BTW, the .a files being linked to above are not like Unix .a static
> archives - they are import library files, which I think they are only
> used at link time, not run time. The path to the DLLs isn't being hardcoded.
Ah, I see. So then what Marco is suggesting is copying a coding pattern
that does work.
> Unless there is further argument I propose to commit something very like
> Marco's suggestion for hstore_plperl, hstore_plpython and ltree_plpython
No objection here.
regards, tom lane
On Sun, Jul 12, 2015 at 05:02:51PM -0400, Andrew Dunstan wrote: > >>Marco Atzeri <marco.atzeri@gmail.com> writes: > >>>for what I see the hstore_plperl link has a double problem. > >>>It requires a link to hstore > >>>as it also requires a link to perl. > >>>Attached patch for solving this and a similar issue with python. > >>>+ifeq ($(PORTNAME), cygwin) > >>>+# This means we need an in-tree build on Windows, not a pgxs build > >>>+SHLIB_LINK += -L../hstore -lhstore -L$(perl_archlibexp)/CORE -lperl > >>>+endif That's the right general strategy, agreed. > Unless there is further argument I propose to commit something very like > Marco's suggestion for hstore_plperl, hstore_plpython and ltree_plpython Would you post the final patch for review? Thanks, nm
On 07/12/2015 05:06 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>>> On 07/04/2015 11:02 AM, Tom Lane wrote:
>>>> It's not apparent to me how that works at all.
>> BTW, the .a files being linked to above are not like Unix .a static
>> archives - they are import library files, which I think they are only
>> used at link time, not run time. The path to the DLLs isn't being hardcoded.
> Ah, I see. So then what Marco is suggesting is copying a coding pattern
> that does work.
>
>> Unless there is further argument I propose to commit something very like
>> Marco's suggestion for hstore_plperl, hstore_plpython and ltree_plpython
> No objection here.
>
>
OK, I tried the attached patch.
but when trying to build with python 3 I get this (no such problems with
python2, which builds and tests fine):
make -C hstore_plpython all
make[1]: Entering directory
'/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython'
ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -g -O2 -I../../src/pl/plpython
-I/usr/include/python3.4m -I../../contrib/hstore -I. -I.
-I../../src/include -I/usr/include/libxml2 -c -o hstore_plpython.o
hstore_plpython.c
ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -g -O2 -shared -o
hstore_plpython3.dll hstore_plpython.o -L../../src/port
-L../../src/common -Wl,--allow-multiple-definition
-Wl,--enable-auto-import -L/usr/lib -L/usr/local/lib
-Wl,--as-needed -L../../src/backend -lpostgres -L../hstore
-lhstore -L../../src/pl/plpython -lplpython3
-L/usr/lib/python3.4/config-3.4m -lpython3.4m -lpgcommon -lpgport
-lxslt -lxml2 -lssl -lcrypto -lz -lreadline -lcrypt
hstore_plpython.o: In function `hstore_to_plpython':
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35:
undefined reference to `PLyUnicode_FromStringAndSize'
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35:(.text+0x99):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`PLyUnicode_FromStringAndSize'
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:28:
undefined reference to `PLyUnicode_FromStringAndSize'
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:28:(.text+0xf1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`PLyUnicode_FromStringAndSize'
hstore_plpython.o: In function `plpython_to_hstore':
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:96:
undefined reference to `PLyObject_AsString'
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:96:(.text+0x2cc):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`PLyObject_AsString'
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:84:
undefined reference to `PLyObject_AsString'
/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:84:(.text+0x321):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`PLyObject_AsString'
collect2: error: ld returned 1 exit status
../../src/Makefile.shlib:358: recipe for target
'hstore_plpython3.dll' failed
make[1]: *** [hstore_plpython3.dll] Error 1
make[1]: Leaving directory
'/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython'
Makefile:92: recipe for target 'all-hstore_plpython-recurse' failed
make: *** [all-hstore_plpython-recurse] Error 2
I'd like to get that fixed before applying anything. Marco, any ideas?
To build with python 3, set the environment like this:
PYTHON=/usr/bin/python3 - this can be done in the config file.
cheers
andrew
Вложения
On 7/13/2015 5:36 PM, Andrew Dunstan wrote: > > On 07/12/2015 05:06 PM, Tom Lane wrote: >> Andrew Dunstan <andrew@dunslane.net> writes: >>>> On 07/04/2015 11:02 AM, Tom Lane wrote: >>>>> It's not apparent to me how that works at all. >>> BTW, the .a files being linked to above are not like Unix .a static >>> archives - they are import library files, which I think they are only >>> used at link time, not run time. The path to the DLLs isn't being >>> hardcoded. >> Ah, I see. So then what Marco is suggesting is copying a coding pattern >> that does work. >> >>> Unless there is further argument I propose to commit something very like >>> Marco's suggestion for hstore_plperl, hstore_plpython and ltree_plpython >> No objection here. >> >> > > OK, I tried the attached patch. > > but when trying to build with python 3 I get this (no such problems with > python2, which builds and tests fine): > > make -C hstore_plpython all > make[1]: Entering directory > '/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython' > ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing > -fwrapv -fexcess-precision=standard -g -O2 -I../../src/pl/plpython > -I/usr/include/python3.4m -I../../contrib/hstore -I. -I. > -I../../src/include -I/usr/include/libxml2 -c -o hstore_plpython.o > hstore_plpython.c > ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing > -fwrapv -fexcess-precision=standard -g -O2 -shared -o > hstore_plpython3.dll hstore_plpython.o -L../../src/port > -L../../src/common -Wl,--allow-multiple-definition > -Wl,--enable-auto-import -L/usr/lib -L/usr/local/lib > -Wl,--as-needed -L../../src/backend -lpostgres -L../hstore > -lhstore -L../../src/pl/plpython -lplpython3 > -L/usr/lib/python3.4/config-3.4m -lpython3.4m -lpgcommon -lpgport > -lxslt -lxml2 -lssl -lcrypto -lz -lreadline -lcrypt > hstore_plpython.o: In function `hstore_to_plpython': > > /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35: > > undefined reference to `PLyUnicode_FromStringAndSize' > [cut] > I'd like to get that fixed before applying anything. Marco, any ideas? > > To build with python 3, set the environment like this: > PYTHON=/usr/bin/python3 - this can be done in the config file. I am only building with python2, but on cygwin there is an additional "intl" library for python3 binding $ python2-config --libs -lpython2.7 -ldl $ python3-config --libs -lpython3.4m -lintl -ldl > cheers > > andrew Regards Marco
On 07/13/2015 11:53 AM, Marco Atzeri wrote: > On 7/13/2015 5:36 PM, Andrew Dunstan wrote: >> >> On 07/12/2015 05:06 PM, Tom Lane wrote: >>> Andrew Dunstan <andrew@dunslane.net> writes: >>>>> On 07/04/2015 11:02 AM, Tom Lane wrote: >>>>>> It's not apparent to me how that works at all. >>>> BTW, the .a files being linked to above are not like Unix .a static >>>> archives - they are import library files, which I think they are only >>>> used at link time, not run time. The path to the DLLs isn't being >>>> hardcoded. >>> Ah, I see. So then what Marco is suggesting is copying a coding >>> pattern >>> that does work. >>> >>>> Unless there is further argument I propose to commit something very >>>> like >>>> Marco's suggestion for hstore_plperl, hstore_plpython and >>>> ltree_plpython >>> No objection here. >>> >>> >> >> OK, I tried the attached patch. >> >> but when trying to build with python 3 I get this (no such problems with >> python2, which builds and tests fine): >> >> make -C hstore_plpython all >> make[1]: Entering directory >> '/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython' >> ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith >> -Wdeclaration-after-statement -Wendif-labels >> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing >> -fwrapv -fexcess-precision=standard -g -O2 -I../../src/pl/plpython >> -I/usr/include/python3.4m -I../../contrib/hstore -I. -I. >> -I../../src/include -I/usr/include/libxml2 -c -o hstore_plpython.o >> hstore_plpython.c >> ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith >> -Wdeclaration-after-statement -Wendif-labels >> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing >> -fwrapv -fexcess-precision=standard -g -O2 -shared -o >> hstore_plpython3.dll hstore_plpython.o -L../../src/port >> -L../../src/common -Wl,--allow-multiple-definition >> -Wl,--enable-auto-import -L/usr/lib -L/usr/local/lib >> -Wl,--as-needed -L../../src/backend -lpostgres -L../hstore >> -lhstore -L../../src/pl/plpython -lplpython3 >> -L/usr/lib/python3.4/config-3.4m -lpython3.4m -lpgcommon -lpgport >> -lxslt -lxml2 -lssl -lcrypto -lz -lreadline -lcrypt >> hstore_plpython.o: In function `hstore_to_plpython': >> >> /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35: >> >> >> undefined reference to `PLyUnicode_FromStringAndSize' >> > [cut] >> I'd like to get that fixed before applying anything. Marco, any ideas? >> >> To build with python 3, set the environment like this: >> PYTHON=/usr/bin/python3 - this can be done in the config file. > > I am only building with python2, but on cygwin > there is an additional "intl" library for python3 binding > > $ python2-config --libs > -lpython2.7 -ldl > > $ python3-config --libs > -lpython3.4m -lintl -ldl > No this doesn't seem to be the problem. For some reason it's apparently not finding the symbol in plpython3.dll, where it should definitely exist, unless I'm completely off base. So I'm rather confused. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> On 07/13/2015 11:53 AM, Marco Atzeri wrote:
>> On 7/13/2015 5:36 PM, Andrew Dunstan wrote:
>>> hstore_plpython.o: In function `hstore_to_plpython':
>>> /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35:
>>> undefined reference to `PLyUnicode_FromStringAndSize'
> No this doesn't seem to be the problem. For some reason it's apparently
> not finding the symbol in plpython3.dll, where it should definitely
> exist, unless I'm completely off base. So I'm rather confused.
Could hstore_plpython and plpython somehow have been built with different
ideas about PY_MAJOR_VERSION? PLyUnicode_FromStringAndSize is
conditionally compiled, and the reference to it from hstore_plpython
depends on a conditionally-defined macro, and this error would make plenty
of sense if those conditions somehow diverged. So I'd look for instance
at whether identical -I paths were used in both parts of the build.
regards, tom lane
On 07/13/2015 05:18 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 07/13/2015 11:53 AM, Marco Atzeri wrote: >>> On 7/13/2015 5:36 PM, Andrew Dunstan wrote: >>>> hstore_plpython.o: In function `hstore_to_plpython': >>>> /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35: >>>> undefined reference to `PLyUnicode_FromStringAndSize' >> No this doesn't seem to be the problem. For some reason it's apparently >> not finding the symbol in plpython3.dll, where it should definitely >> exist, unless I'm completely off base. So I'm rather confused. > Could hstore_plpython and plpython somehow have been built with different > ideas about PY_MAJOR_VERSION? PLyUnicode_FromStringAndSize is > conditionally compiled, and the reference to it from hstore_plpython > depends on a conditionally-defined macro, and this error would make plenty > of sense if those conditions somehow diverged. So I'd look for instance > at whether identical -I paths were used in both parts of the build. Not AFAICT. Here is the contrib build: ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -I../../src/pl/plpython -I/usr/include/python3.4m -I../../contrib/hstore -I. -I. -I../../src/include -I/usr/include/libxml2 -c -o hstore_plpython.o hstore_plpython.c ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -shared -o hstore_plpython3.dll hstore_plpython.o -L../../src/port -L../../src/common -Wl,--allow-multiple-definition -Wl,--enable-auto-import -L/usr/lib -L/usr/local/lib -Wl,--as-needed -L../../src/backend -lpostgres -L../hstore -lhstore -L../../src/pl/plpython -lplpython3 -L/usr/lib/python3.4/config-3.4m -lpython3.4m -lpgcommon -lpgport -lxslt -lxml2 -lssl -lcrypto -lz -lreadline-lcrypt and here is the plpython build: ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -I. -I. -I/usr/include/python3.4m -I../../../src/include -I/usr/include/libxml2 -DUSE_DL_IMPORT -c -o plpy_util.o plpy_util.c ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 -shared -o plpython3.dll plpy_cursorobject.o plpy_elog.o plpy_exec.o plpy_main.o plpy_planobject.o plpy_plpymodule.o plpy_procedure.o plpy_resultobject.o plpy_spi.o plpy_subxactobject.o plpy_typeio.o plpy_util.o -L../../../src/port -L../../../src/common -Wl,--allow-multiple-definition -Wl,--enable-auto-import -L/usr/lib -L/usr/local/lib -Wl,--as-needed-L/usr/lib/python3.4/config-3.4m -lpython3.4m -lintl -ldl -L../../../src/backend -lpostgres -lpgcommon-lpgport -lxslt -lxml2 -lssl -lcrypto -lz -lreadline -lcrypt The functions are in fact apparently built - the names are present in the object file and the DLL. cheers andrew > > regards, tom lane >
Andrew Dunstan <andrew@dunslane.net> writes:
> Not AFAICT. Here is the contrib build:
Hm ... what does -DUSE_DL_IMPORT do?
regards, tom lane
On 07/13/2015 07:33 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Not AFAICT. Here is the contrib build: > Hm ... what does -DUSE_DL_IMPORT do? > > NFI - I tried building with that but it made no difference. cheers andrew
On Tue, Jul 14, 2015 at 8:49 AM, Andrew Dunstan <andrew@dunslane.net> wrote: > > On 07/13/2015 07:33 PM, Tom Lane wrote: >> >> Andrew Dunstan <andrew@dunslane.net> writes: >>> >>> Not AFAICT. Here is the contrib build: >> >> Hm ... what does -DUSE_DL_IMPORT do? > > NFI - I tried building with that but it made no difference. Is your python3 build a 32b version? -- Michael
On 07/13/2015 07:55 PM, Michael Paquier wrote: > On Tue, Jul 14, 2015 at 8:49 AM, Andrew Dunstan <andrew@dunslane.net> wrote: >> On 07/13/2015 07:33 PM, Tom Lane wrote: >>> Andrew Dunstan <andrew@dunslane.net> writes: >>>> Not AFAICT. Here is the contrib build: >>> Hm ... what does -DUSE_DL_IMPORT do? >> NFI - I tried building with that but it made no difference. > Is your python3 build a 32b version? No, this is all 64 bit. cheers andrew
On Mon, Jul 13, 2015 at 06:19:49PM -0400, Andrew Dunstan wrote: > >>>On 7/13/2015 5:36 PM, Andrew Dunstan wrote: > >>>>hstore_plpython.o: In function `hstore_to_plpython': > >>>>/home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35: > >>>>undefined reference to `PLyUnicode_FromStringAndSize' > The functions are in fact apparently built - the names are present in the > object file and the DLL. Per "objdump -x src/pl/plpython/plpython3.dll | less -pOrdinal/Name", those symbols aren't exported. The Cygwin toolchain appears to export every function until you mark one with __declspec (dllexport), after which it exports just the ones so marked. Since plpython3.dll has an explicit __declspec on PyInit_plpy(), that's the sole function exported. Adding -Wl,--export-all-symbols to the PL/Python link lets the build complete; I have not researched whether it is a proper fix.