Re: [HACKERS] initdb initalization failure for collation "ja_JP"
On 20/06/2017 17:37, Tom Lane wrote: I wrote: Marco Atzeri <marco.atz...@gmail.com> writes: Building on Cygwin latest 10 beta1 or head sourece, make check fails as: ... performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists Hmph. Could we see the results of "locale -a | grep ja_JP" ? Despite the lack of followup from the OP, I'm pretty troubled by this report. It shows that the reimplementation of OS collation data import as pg_import_system_collations() is a whole lot more fragile than the original coding. We have never before trusted "locale -a" to not produce duplicate outputs, not since the very beginning in 414c5a2e. AFAICS, the current coding has also lost the protections we added very shortly after that in 853c1750f; and it has also lost the admittedly rather arbitrary, but at least deterministic, preference order for conflicting short aliases that was in the original initdb code. Hi Tom, I raised the duplication issue on the cygwin mailing list, and one of the core developer reports that they saw the same issues on Linux in the past. https://cygwin.com/ml/cygwin/2017-06/msg00253.html regards, tom lane Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] initdb initalization failure for collation "ja_JP"
On 18/06/2017 16:48, Tom Lane wrote: Marco Atzeri <marco.atz...@gmail.com> writes: Building on Cygwin latest 10 beta1 or head sourece, make check fails as: ... performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists Hmph. Could we see the results of "locale -a | grep ja_JP" ? regards, tom lane $ locale -a |grep -i ja ja_JP ja_JP ja_JP.utf8 ja_JP.ujis ja_JP@cjknarrow ja_JP.utf8@cjknarrow japanese japanese.euc japanese.sjis $ locale -a |grep -i "euc" japanese.euc korean.euc Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] initdb initalization failure for collation "ja_JP"
Building on Cygwin latest 10 beta1 or head sourece, make check fails as: -initdb.log - The database cluster will be initialized with locales COLLATE: en_US.UTF-8 CTYPE:en_US.UTF-8 MESSAGES: C MONETARY: en_US.UTF-8 NUMERIC: en_US.UTF-8 TIME: en_US.UTF-8 The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". Data page checksums are disabled. creating directory /cygdrive/e/cyg_pub/devel/postgresql/prova/postgresql-10.0-0.1.x86_64/build/src/test/regress/./tmp_check/data ... ok creating subdirectories ... ok selecting default max_connections ... 30 selecting default shared_buffers ... 128MB selecting dynamic shared memory implementation ... sysv creating configuration files ... ok running bootstrap script ... ok performing post-bootstrap initialization ... 2017-05-31 23:23:22.214 CEST [16860] FATAL: collation "ja_JP" for encoding "EUC_JP" already exists - This does not happen on 9.6.x. Any idea what to look ? Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question and suggestion about application binary compatibility policy
On 31/05/2016 08:10, Tsunakawa, Takayuki wrote: From: Michael Meskes [mailto:mes...@postgresql.org] Yes, but Windows users probably don't understand or know it. So, I suggested explicitly describing the application binary compatibility policy in the PostgreSQL manual. What do you think about it? Couldn't you point your customer to the system documentation? Personally I don't think standard system behavior should be documented for each application relying on it but ymmv. I couldn't find appropriate system documentation. Regarding Linux, I remember I saw some HOWTO on tldp.org website which explains the concept of shared library soname, but it's not very friendly for users who just want to know the application binary compatibility policy of PostgreSQL. And I don't think there's suitable documentation on Windows. Even if there is any, users will not be sure whether PostgreSQL follows those platform-specific conventions. They may have doubts about it, because even the product version "PostgreSQL x.y.z" causes misconception that x is the major version and y is the minor one. So, I suggested documenting the compatibility policy for clarification and user friendliness as in the Oracle Database documentation below. http://docs.oracle.com/database/121/UPGRD/app.htm#UPGRD12547 BTW, although this may be a separate topic, it may be better that we add the major version in the library names like libpq5.dll and libecpg6.dll, so that the application can fail to run with the incompatible versions of libpq and libecpg. FYI: https://en.wikipedia.org/wiki/Side-by-side_assembly [Excerpt] Microsoft Visual C++ 2005 and 2008 employ SxS with all C runtime libraries. However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name, which means that different versions of one DLL will technically be completely different DLLs now. Any comments on these? If there's no strong objection, I think I'll submit a documentation patch in the future. Regards Takayuki Tsunakawa Hi, on cygwin the postgresql binary package already include the library versions: /usr/bin/cygecpg-6.dll /usr/bin/cygecpg_compat-3.dll /usr/bin/cygpgtypes-3.dll /usr/bin/cygpq-5.dll attached the patch used for the build. Regards Marco --- origsrc/postgresql-9.4.2/src/Makefile.shlib 2015-05-20 00:33:58.0 +0200 +++ src/Makefile.shlib 2015-05-27 23:01:09.379468300 +0200 @@ -267,7 +267,7 @@ endif ifeq ($(PORTNAME), cygwin) LINK.shared = $(CC) -shared ifdef SO_MAJOR_VERSION -shlib = cyg$(NAME)$(DLSUFFIX) +shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif haslibarule = yes endif @@ -359,12 +359,9 @@ ifeq ($(PORTNAME), cygwin) # Cygwin case $(shlib): $(OBJS) | $(SHLIB_PREREQS) - $(CC) $(CFLAGS) -shared -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE) + $(CC) $(CFLAGS) -shared -o $@ -Wl,--out-implib=$(stlib) $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE) -$(stlib): $(OBJS) | $(SHLIB_PREREQS) - rm -f $@ - $(LINK.static) $@ $^ - $(RANLIB) $@ +$(stlib): $(shlib) ; else --- origsrc/postgresql-9.4.2/src/interfaces/libpq/Makefile 2015-05-20 00:33:58.0 +0200 +++ src/interfaces/libpq/Makefile 2015-05-27 22:56:43.193200600 +0200 @@ -45,7 +45,7 @@ OBJS += ip.o md5.o OBJS += encnames.o wchar.o ifeq ($(PORTNAME), cygwin) -override shlib = cyg$(NAME)$(DLSUFFIX) +override shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif ifeq ($(PORTNAME), win32) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin
On 18/01/2016 18:32, Andrew Dunstan wrote: On 01/14/2016 12:38 AM, Michael Paquier wrote: Hi all, Beginning a new thread seems more adapted regarding $subject but that's mentioned here as well: http://www.postgresql.org/message-id/CAB7nPqQXghm_SdB5iniupz1atzMxk=95gv9a8ocdo83sxcn...@mail.gmail.com Marco, as I think you do some packaging for Postgres in Cygwin, and others, does that sound acceptable? I think we can be a bit more adventurous and remove all the Cygwin-specific code. See attached patch, which builds fine on buildfarm cockatiel. cheers andrew builds fine also here on 64bit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin
On 14/01/2016 06:38, Michael Paquier wrote: Hi all, Beginning a new thread seems more adapted regarding $subject but that's mentioned here as well: http://www.postgresql.org/message-id/CAB7nPqQXghm_SdB5iniupz1atzMxk=95gv9a8ocdo83sxcn...@mail.gmail.com It happens based on some investigation from Andrew that cygwin does not need to use the service-related code, aka register/unregister options or similar that are proper to WIN32 and rely instead on cygrunsrv with a SYSV-like init file to manage the service. Based on my tests with cygwin, I am able to see as well that a server started within a cygwin session is able to persist even after it is closed, which is kind of nice and I think that it is a additional reason to not use the service-related code paths. Hence what about the following patch, that makes cygwin behave like any *nix OS when using pg_ctl? This simplifies a bit the code. Marco, as I think you do some packaging for Postgres in Cygwin, and others, does that sound acceptable? Regards, In general cygwin to behave like any *nix OS is the preferred solution. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22
On 7/13/2015 5:36 PM, Andrew Dunstan wrote: On 07/12/2015 05:06 PM, Tom Lane wrote: Andrew Dunstan and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] postgresql-9.5alpha1 packaging
As there are additional or moved binaries in comparison to 9.4 -usr/bin/pg_archivecleanup.exe -usr/bin/pg_rewind.exe -usr/bin/pg_test_fsync.exe -usr/bin/pg_test_timing.exe -usr/bin/pg_upgrade.exe -usr/bin/pg_xlogdump.exe -usr/bin/pgbench.exe any suggestion where to fit them ? Current split on cygwin packages is: $ cygcheck -l postgresql |grep exe /usr/sbin/initdb.exe /usr/sbin/pg_controldata.exe /usr/sbin/pg_ctl.exe /usr/sbin/pg_resetxlog.exe /usr/sbin/postgres.exe $ cygcheck -l postgresql-client |grep exe /usr/bin/clusterdb.exe /usr/bin/createdb.exe /usr/bin/dropdb.exe /usr/bin/pg_dump.exe /usr/bin/pg_dumpall.exe /usr/bin/pg_basebackup.exe /usr/bin/pg_isready.exe /usr/bin/pg_receivexlog.exe /usr/bin/pg_recvlogical.exe /usr/bin/psql.exe /usr/bin/reindexdb.exe /usr/sbin/createlang.exe /usr/sbin/createuser.exe /usr/sbin/droplang.exe /usr/sbin/dropuser.exe /usr/sbin/pg_restore.exe /usr/sbin/vacuumdb.exe cygcheck -l postgresql-contrib |grep exe /usr/lib/postgresql/bin/oid2name.exe /usr/lib/postgresql/bin/pgbench.exe /usr/lib/postgresql/bin/pg_archivecleanup.exe /usr/lib/postgresql/bin/pg_standby.exe /usr/lib/postgresql/bin/pg_test_fsync.exe /usr/lib/postgresql/bin/pg_test_timing.exe /usr/lib/postgresql/bin/pg_upgrade.exe /usr/lib/postgresql/bin/pg_xlogdump.exe /usr/lib/postgresql/bin/vacuumlo.exe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22
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.atz...@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 --- origsrc/postgresql-9.5alpha1/contrib/hstore_plperl/Makefile 2015-06-29 21:42:18.0 +0200 +++ src/postgresql-9.5alpha1/contrib/hstore_plperl/Makefile 2015-07-04 08:20:54.077873800 +0200 @@ -30,6 +30,12 @@ override CPPFLAGS += -DPLPERL_HAVE_UID_G SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plperl/libperl*.a) endif +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 + + # As with plperl we need to make sure that the CORE directory is included # last, probably because it sometimes contains some header files with names # that clash with some of ours, or with some that we include, notably on --- origsrc/postgresql-9.5alpha1/contrib/hstore_plpython/Makefile 2015-06-29 21:42:18.0 +0200 +++ src/postgresql-9.5alpha1/contrib/hstore_plpython/Makefile 2015-07-04 08:39:30.343835200 +0200 @@ -28,6 +28,12 @@ ifeq ($(PORTNAME), win32) SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plpython/libpython*.a) $(wildcard ../../src/pl/plpython/libplpython*.a) endif +ifeq ($(PORTNAME), cygwin) +# This means we need an in-tree build on Windows, not a pgxs build +SHLIB_LINK += -L../hstore -lhstore -L../../src/pl/plpython -lplpython2 $(python_libspec) +endif + + REGRESS_OPTS += --load-extension=hstore ifeq ($(python_majorversion),2) REGRESS_OPTS += --load-extension=plpythonu --load-extension=hstore_plpythonu --- origsrc/postgresql-9.5alpha1/contrib/ltree_plpython/Makefile 2015-06-29 21:42:18.0 +0200 +++ src/postgresql-9.5alpha1/contrib/ltree_plpython/Makefile2015-07-04 08:40:09.328303700 +0200 @@ -28,6 +28,12 @@ ifeq ($(PORTNAME), win32) SHLIB_LINK += $(wildcard ../../src/pl/plpython/libpython*.a) endif +ifeq ($(PORTNAME), cygwin) +# This means we need an in-tree build on Windows, not a pgxs build +SHLIB_LINK += -L../../src/pl/plpython -lplpython2 $(python_libspec) +endif + + REGRESS_OPTS += --load-extension=ltree ifeq ($(python_majorversion),2) REGRESS_OPTS += --load-extension=plpythonu --load-extension=ltree_plpythonu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22
On 7/3/2015 8:19 AM, Michael Paquier wrote: On Fri, Jul 3, 2015 at 2:47 PM, Marco Atzeri marco.atz...@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=dangomushidt=2015-07-02%2019%3A19%3A39stg=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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 ' -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] About that re-release ...
On 5/28/2015 7:10 PM, Josh Berkus wrote: On 05/28/2015 02:37 AM, Marco Atzeri wrote: On 5/28/2015 5:00 AM, Tom Lane wrote: Assuming that we can get a fix for the fsync-failure-during-restart problem committed by the end of the week, there will be a new set of back-branch minor releases next week. Usual schedule, wrap Monday for public announcement Thursday. regards, tom lane Tom, thanks for the advise. I will postpone the deployment of new packages for cygwin until 9.4.3 will be available. You're doing the cygwin packages? You should probably be on the packagers list, then, no? There is a dedicate packagers mailing list ? I don't see one on: http://www.postgresql.org/list/ Could you clarify ? Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test failure on latest source
On 16/04/2014 18:55, Marco Atzeri wrote: On 16/04/2014 17:40, Tom Lane wrote: The bigger picture though is that this code isn't failing on the buildfarm. So what we need to ask is what's different about Marco's machine. good question. I checked again and I found that the fault is only on the cygwin 64 bit build but not on the cygwin 32 bit one. I was sure to have tested both, but it seems this time I missed the comparison. regards, tom lane Regards Marco to close the issue, we have identified the fault in the getaddrinfo system call on cygwin64. What happens is that the field ai_addrlen is defined as socklen_t in POSIX, but as size_t in the W32 API. On 64 bit, socklen_t is 4 bytes while size_t is 8 bytes. Setting all the hintp members manually (in contrast to calloc'ing it or memset'ing it to 0) leaves the 4 upper bytes of the ai_addrlen untouched. This in turn leads to a high probability that ai_addrlen has an invalid value when entering Winsock's getsockopt. Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test failure on latest source
On 13/04/2014 18:09, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 16:35:48 -0400, Tom Lane wrote: In principle, that commit shouldn't have affected behavior for pg_hba entries with numeric address fields ... Hm. getaddrinfo.c has this bit: /* Unsupported flags. */ if (flags NI_NAMEREQD) return EAI_AGAIN; Yeah, and that flag is only ever specified when attempting to do reverse lookup on a client address to see if it matches a non-numeric pg_hba entry. regards, tom lane just to recap, as I think no one have yet proposed/implemented a solution. first failure I see on cygwin is from - $ git log |head commit fc752505a99a4e2c781a070d3d42a25289c22e3c Author: Tom Lane t...@sss.pgh.pa.us Date: Wed Apr 2 17:11:24 2014 -0400 Fix assorted issues in client host name lookup. [cut] --- previous one is fine -- commit f33a71a7865a1dd54f04b370e2637f88665f8db8 Author: Tom Lane t...@sss.pgh.pa.us Date: Wed Apr 2 14:30:08 2014 -0400 De-anonymize the union in JsonbValue. Needed for strict C89 compliance. error log cat /pub/devel/postgresql/prova/build_orig/src/test/regress/log/postmaster.log LOG: could not resolve localhost: Non-recoverable failure in name resolution LOG: disabling statistics collector for lack of working socket WARNING: autovacuum not started because of misconfiguration HINT: Enable the track_counts option. LOG: invalid IP address 127.0.0.1: Non-recoverable failure in name resolution CONTEXT: line 86 of configuration file /pub/devel/postgresql/prova/build_orig/src/test/regress/./tmp_check/data/pg_hba.conf FATAL: could not load pg_hba.conf --- and of course localhost and 127.0.0.1 are valid $ ping localhost Pinging GE-MATZERI-EU [127.0.0.1] with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time1ms TTL=128 [cut] $ ping 127.0.0.1 Pinging 127.0.0.1 with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time1ms TTL=128 Reply from 127.0.0.1: bytes=32 time1ms TTL=128 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test failure on latest source
On 16/04/2014 17:14, Alvaro Herrera wrote: Marco Atzeri wrote: On 13/04/2014 18:09, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 16:35:48 -0400, Tom Lane wrote: In principle, that commit shouldn't have affected behavior for pg_hba entries with numeric address fields ... Hm. getaddrinfo.c has this bit: /* Unsupported flags. */ if (flags NI_NAMEREQD) return EAI_AGAIN; Yeah, and that flag is only ever specified when attempting to do reverse lookup on a client address to see if it matches a non-numeric pg_hba entry. I don't know if this is relevant, but perhaps we're defining the constants in a way that conflicts with the values defined by cygwin. A very quick search finds a 2007 patch for Mutt[1] that seems to have NI_NAMEREQD defined as 8 somewhere, while 4 is NI_NOFQDN. But we have this in getaddrinfo.h: #ifndef NI_NAMEREQD #define NI_NAMEREQD 4 #endif So maybe we're doing something wrong. Indeed, my system has in /usr/include/netdb.h # define NI_NAMEREQD8 /* Don't return numeric addresses. */ You'd do well to research this more, I think. [1] http://marc.info/?l=mutt-devm=117752314512877w=2 on cygwin both 32 and 64 bit I see netdb.h:#define NI_NAMEREQD 0x4 /* Not being able to resolve is an error. */ same on w32api/ws2tcpip.h:#define NI_NAMEREQD 0x04 curiosly I see also on roken-common.h:#define NI_NAMEREQD 0x02 $ cygcheck -f /usr/include/roken-common.h libkrb5-devel-1.5.3-1 not sure if it has any relevance at all in this case. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test failure on latest source
On 16/04/2014 17:40, Tom Lane wrote: The bigger picture though is that this code isn't failing on the buildfarm. So what we need to ask is what's different about Marco's machine. good question. I checked again and I found that the fault is only on the cygwin 64 bit build but not on the cygwin 32 bit one. I was sure to have tested both, but it seems this time I missed the comparison. regards, tom lane Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] test failure on latest source
Anyone seeing similar failure ? testing on latest $ git log |head commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2 Author: Bruce Momjian br...@momjian.us Date: Thu Apr 10 17:16:22 2014 -0400 docs: psql '--' comments are not passed to the server C-style block comments are passed to the server. $ cat /pub/devel/postgresql/prova/build_orig/src/test/regress /log/postmaster.log LOG: could not resolve localhost: Non-recoverable failure in name resolution LOG: disabling statistics collector for lack of working socket WARNING: autovacuum not started because of misconfiguration HINT: Enable the track_counts option. LOG: invalid IP address 127.0.0.1: Non-recoverable failure in name resolution CONTEXT: line 86 of configuration file /pub/devel/postgresql/prova/build_orig/src/test/regress/./tmp_check/data/pg_hba.conf FATAL: could not load pg_hba.conf built as usual on cygwin with ../postgresql_orig/configure LDFLAGS=-Wl,-no-undefined --enable-nls --with-openssl --with-perl --with-python --with-ldap Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test failure on latest source
On 12/04/2014 19:11, Andrew Dunstan wrote: Why can't it resolve localhost? That's a local issue you need to fix. cheers andrew Andrew, just to be clear - localhost is resolved to 127.0.0.1 - 127.0.0.1 is pingable - same test on 9.3.4 works All 135 tests passed. - same test, few days ago, on trunk was fine so it is only failing on recent trunk Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test failure on latest source
On 12/04/2014 19:48, Andres Freund wrote: On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: - same test, few days ago, on trunk was fine so it is only failing on recent trunk Does it work on a commit before fc752505a99a4e2c781a070d3d42a25289c22e3c? E.g. f33a71a7865a1dd54f04b370e2637f88665f8db8? f33a71a7865a1dd54f04b370e2637f88665f8db8 works. Greetings, Andres Freund I will look on bisecting from there Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 16/02/2014 15:43, Andres Freund wrote: Marco, Andrew: On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote: ../../src/timezone/localtime.o ../../src/timezone/strftime.o ../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a ../../src/common/libpgcommon_srv.a -lintl -lssl -lcrypto -lcrypt -lldap -o postgres libpq/auth.o:auth.c:(.text+0x1940): undefined reference to `in6addr_any' libpq/auth.o:auth.c:(.text+0x1954): undefined reference to `in6addr_any' libpq/auth.o:auth.c:(.text+0x196d): undefined reference to `in6addr_any' libpq/auth.o:auth.c:(.text+0x1979): undefined reference to `in6addr_any' /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: libpq/auth.o: bad reloc address 0xce4 in section `.rdata' collect2: error: ld returned 1 exit status Makefile:66: recipe for target 'postgres' failed make[2]: *** [postgres] Error 1 make[2]: Leaving directory '/pub/devel/postgresql/git/postgresql_build/src/backend' Could either of you try whether compiling with the attached hack fixes anything on cygwin? Greetings, Andres Freund on cygwin32 bit it works, but it stops later on --- sl -lcrypto -lz -lreadline -lcrypt -o psql.exe tab-complete.o:tab-complete.c:(.text+0xa98): undefined reference to `rl_line_buffer' tab-complete.o:tab-complete.c:(.text+0xa387): undefined reference to `rl_attempted_completion_function' tab-complete.o:tab-complete.c:(.text+0xa391): undefined reference to `rl_basic_word_break_characters' tab-complete.o:tab-complete.c:(.text+0xa3a4): undefined reference to `rl_readline_name' /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: tab-complete.o: bad reloc address 0x30ec in section `.rdata' /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: final link failed: Invalid operation collect2: error: ld returned 1 exit status Makefile:33: recipe for target 'psql' failed --- on cygwin 64bit, that I was not testing before, something is strange -- -lintl -lssl -lcrypto -lcrypt -lldap -lwsock32 -lws2_32 -o postgres postmaster/postmaster.o:postmaster.c:(.rdata$.refptr.environ[.refptr.environ]+0x0): undefined reference to `environ' collect2: error: ld returned 1 exit status Makefile:68: recipe for target 'postgres' failed make[2]: *** [postgres] Error 1 --- of course 9.3.2 builds fine on cygwin 64bit. Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 12/02/2014 17:39, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-02-12 11:26:56 -0500, Tom Lane wrote: Hm. So if we're giving up on the idea of ever getting rid of PGDLLIMPORT, we ought to actually remove that, so that the Cygwin build works more like the other Windows builds? Hm, I don't see a big advantage in detecting the errors as It won't hugely increase the buildfarm coverage. But --auto-import seems to require marking the .text sections as writable, avoiding that seems to be a good idea if we don't need it anymore. Given the rather small number of Windows machines in the buildfarm, I'd really like them all to be on the same page about what's valid and what isn't. Having to wait ~24 hours to find out if they're all happy with something isn't my idea of a good time. In any case, as long as we have discrepancies between them, I'm not going to be entirely convinced that any of them are telling the full truth. I'm going to go remove that switch and see if brolga starts failing. If it does, I'll be satisfied that we understand the issues here. regards, tom lane disabling is not working on cygwin gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard zic.o ialloc.o scheck.o localtime.o -L../../src/port -L../../src/common -Wl,--allow-multiple-definition -Wl,--disable-auto-import -L/usr/local/lib -Wl,--as-needed -lpgcommon -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -o zic.exe zic.o:zic.c:(.text.startup+0xc9): undefined reference to `optarg' zic.o:zic.c:(.text.startup+0x10d): undefined reference to `optarg' /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: zic.o: bad reloc address 0x10d in section `.text.startup' /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: final link failed: Invalid operation collect2: error: ld returned 1 exit status just removing -Wl,--disable-auto-import and everything works $ gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard zic.o ialloc.o scheck.o localtime.o -L../../src/port -L../../src/common -Wl,--allow-multiple-definition -L/usr/local/lib -Wl,--as-needed -lpgcommon -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -o zic.exe Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 15/02/2014 21:54, Andres Freund wrote: Please pull and retry, that already might fix it. The reason it's probably failing is the warnings about declspec you reported earlier. See 60ff2fdd9970ba29f5267317a5e7354d2658c1e5 Greetings, Andres Freund that is fine. there is a different one, later on [cut] ../../src/timezone/localtime.o ../../src/timezone/strftime.o ../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a ../../src/common/libpgcommon_srv.a -lintl -lssl -lcrypto -lcrypt -lldap -o postgres libpq/auth.o:auth.c:(.text+0x1940): undefined reference to `in6addr_any' libpq/auth.o:auth.c:(.text+0x1954): undefined reference to `in6addr_any' libpq/auth.o:auth.c:(.text+0x196d): undefined reference to `in6addr_any' libpq/auth.o:auth.c:(.text+0x1979): undefined reference to `in6addr_any' /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: libpq/auth.o: bad reloc address 0xce4 in section `.rdata' collect2: error: ld returned 1 exit status Makefile:66: recipe for target 'postgres' failed make[2]: *** [postgres] Error 1 make[2]: Leaving directory '/pub/devel/postgresql/git/postgresql_build/src/backend' Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 15/02/2014 23:37, Andres Freund wrote:
On 2014-02-15 17:26:30 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-15 22:11:37 +0100, Marco Atzeri wrote:
../../src/timezone/localtime.o ../../src/timezone/strftime.o
../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a
../../src/common/libpgcommon_srv.a -lintl -lssl -lcrypto -lcrypt -lldap -o
postgres
libpq/auth.o:auth.c:(.text+0x1940): undefined reference to `in6addr_any'
Could you try additionally linking with -lwsock32?
The interesting question here is why it used to work. There is no
extern for in6addr_any in our code, so there must have been a
declaration of that constant in some system header. Which one, and
what linkage is it defining, and where was the linkage getting
resolved before?
mingwcompat.c has the following ugly as heck tidbit:
#ifndef WIN32_ONLY_COMPILER
/*
* MingW defines an extern to this struct, but the actual struct isn't present
* in any library. It's trivial enough that we can safely define it
* ourselves.
*/
const struct in6_addr in6addr_any = {{{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0}}};
I think when that was added the problem might just have been
misanalyzed, but due to the auto import magic this probably wasn't
noticed...
Greetings,
Andres Freund
on cygwin header in /usr/include
32 $ grep -rH in6addr_any *
cygwin/in6.h:extern const struct in6_addr in6addr_any;
cygwin/version.h: in6addr_any, in6addr_loopback.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 12/02/2014 17:26, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-02-12 10:58:20 -0500, Tom Lane wrote: Anybody know *exactly* what --enable-auto-import does? The name is, um, suggestive. My ld(1)'s manpage has three screen's worth of details... Most of it seems to be on http://www.freebsd.org/cgi/man.cgi?query=ldsektion=1 It's essentially elf like shared library linking in pe-coff through dirty tricks. Hm. So if we're giving up on the idea of ever getting rid of PGDLLIMPORT, we ought to actually remove that, so that the Cygwin build works more like the other Windows builds? regards, tom lane If I am not wrong --enable-auto-import is already the default on cygwin build chain ( binutils = 2.19.51 ) so it should make no difference on latest cygwin. Not sure for you 1.7.7 build enviroment. About PGDLLIMPORT , my build log is full of warning: ‘optarg’ redeclared without dllimport attribute: previous dllimport ignored I suspect that removing will also make no difference. Marco PS: we aim unix-like builds not windows one -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 12/02/2014 19:19, Andres Freund wrote: On 2014-02-12 19:13:07 +0100, Marco Atzeri wrote: On 12/02/2014 17:26, Tom Lane wrote: Hm. So if we're giving up on the idea of ever getting rid of PGDLLIMPORT, we ought to actually remove that, so that the Cygwin build works more like the other Windows builds? If I am not wrong --enable-auto-import is already the default on cygwin build chain ( binutils = 2.19.51 ) so it should make no difference on latest cygwin. Not sure for you 1.7.7 build enviroment. We're *disabling* not *enabling* it. remove is not disable if enable is already the default inside binutils and gcc. Or I am missing something ? About PGDLLIMPORT , my build log is full of warning: ‘optarg’ redeclared without dllimport attribute: previous dllimport ignored That should be fixed then. I guess cygwin's getopt.h declares it that way? from /usr/include/getopt.h #ifndef __INSIDE_CYGWIN__ extern int __declspec(dllimport) opterr;/* if error message should be printed */ extern int __declspec(dllimport) optind;/* index into parent argv vector */ extern int __declspec(dllimport) optopt;/* character checked for validity */ extern int __declspec(dllimport) optreset; /* reset getopt */ extern char __declspec(dllimport) *optarg; /* argument associated with option */ #endif I suspect that removing will also make no difference. The committed patch explicitly disables the functionality. PS: we aim unix-like builds not windows one Well, there are a significant number of caveats around the auto import functionality, so there seems little benefit in using it if all the declspec's have to be there anyway. I think that I am not currently using anymore the declspec in the build. But I could be wrong, as the the postgresql build way is the most complicated between all the ones I am dealing with. Greetings, Andres Freund Cheers Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 13/02/2014 00:17, Craig Ringer wrote: On 02/13/2014 12:39 AM, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-02-12 11:26:56 -0500, Tom Lane wrote: Hm. So if we're giving up on the idea of ever getting rid of PGDLLIMPORT, we ought to actually remove that, so that the Cygwin build works more like the other Windows builds? Hm, I don't see a big advantage in detecting the errors as It won't hugely increase the buildfarm coverage. But --auto-import seems to require marking the .text sections as writable, avoiding that seems to be a good idea if we don't need it anymore. Given the rather small number of Windows machines in the buildfarm, I'd really like them all to be on the same page about what's valid and what isn't. Having to wait ~24 hours to find out if they're all happy with something isn't my idea of a good time. In any case, as long as we have discrepancies between them, I'm not going to be entirely convinced that any of them are telling the full truth. I'm going to go remove that switch and see if brolga starts failing. If it does, I'll be satisfied that we understand the issues here. I wouldn't assume that _anything_ Cygwin does makes sense, or is consistent with anything else. Of course, I disagree ;-) Its attempts to produce UNIX-like behaviour on Windows cause some truly bizarre behaviour at times. unfortunately our baseground (Windows) is limiting us. It is not totally unfair to compare the level of weirdness of Cygwin to that of WINE, though they operate in completely different ways. I wouldn't suggest making any conclusions about the _other_ platforms based on Cygwin. My personal experience is that a UNIX-vanilla source build 99% right on recent cygwin. The problem with postgreql make/build system is that it tries to guess platform behavior and that is not fix in time. Porting a new platform to postgresql from scratch will be a very hard effort Automake/Autoconf makes it much more simple; as its aim is to test features not platforms. Cmake also makes it right, now. We teach it that cygwin is a unix platform not a win32 platform I am biased, of course. Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 11/02/2014 18:15, Tom Lane wrote: Marco Atzeri marco.atz...@gmail.com writes: On 09/02/2014 14:10, Andrew Dunstan wrote: On 02/09/2014 01:12 AM, Marco Atzeri wrote: we should have get rid of dlltool on cygwin. At least it is not used on my build The send in a patch. The patch you sent in previously did not totally remove it IIRC. attached patch versus latest git. I've committed this with some fixes. However, I omitted the hunks that change the names of generated shared libraries (to add SO_MAJOR_VERSION). I think that requires some policy discussion around whether we want to do it or not, and in any case it's unrelated to the issues being discussed in this thread. If you still want that, please submit it as a separate patch in a new thread, with some discussion as to why it's a good idea. regards, tom lane Noted. On cygwin the shared libraries are using the SO_MAJOR_VERSION by long time. cd /usr/bin $ ls cyggcc*dll cyggcc_s-1.dll cyggccpp-1.dll $ ls cygfo*dll cygfontconfig-1.dll cygform-10.dll cygform-8.dll cygformw-10.dll cygfontenc-1.dll cygform7.dllcygform-9.dll In this way we allow coexistence of several release, similar to /usr/lib/libpq.so.5 on unix. Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 09/02/2014 14:10, Andrew Dunstan wrote: On 02/09/2014 01:12 AM, Marco Atzeri wrote: On 09/02/2014 00:06, Andrew Dunstan wrote: On 02/08/2014 05:34 PM, Tom Lane wrote: Hiroshi Inoue in...@tpf.co.jp writes: Though I'm not a MINGW expert at all, I know dllwrap is a deprecated tool and dlltool is almost a deprecated tool. Cygwin port is removing the use of dllwrap and dlltool now. Isn't it better for MINGW port to follow it? Only way to make that happen is to prepare and test a patch ... Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We did get rid of dllwrap. But I agree this is worth trying for Mingw. we should have get rid of dlltool on cygwin. At least it is not used on my build Regards Marco The send in a patch. The patch you sent in previously did not totally remove it IIRC. cheers andrew attached patch versus latest git. except prepared_xacts test all others are fine === All 140 tests passed. === Regards Marco diff --git a/src/Makefile.global.in b/src/Makefile.global.in index e0e9b79..eaf6ddf 100644 --- a/src/Makefile.global.in +++ b/src/Makefile.global.in @@ -518,6 +518,11 @@ ifeq ($(PORTNAME),win32) LIBS += -lws2_32 -lshfolder endif +# missing for link on cygwin ? +ifeq ($(PORTNAME),cygwin) +libpq_pgport += $(LDAP_LIBS_FE) +endif + # Not really standard libc functions, used by the backend. TAS = @TAS@ diff --git a/src/Makefile.shlib b/src/Makefile.shlib index a95e4d6..3d4b989 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -273,7 +273,7 @@ endif ifeq ($(PORTNAME), cygwin) LINK.shared = $(CC) -shared ifdef SO_MAJOR_VERSION -shlib = cyg$(NAME)$(DLSUFFIX) +shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif haslibarule = yes endif diff --git a/src/backend/Makefile b/src/backend/Makefile index 356890d..bc744b9 100644 --- a/src/backend/Makefile +++ b/src/backend/Makefile @@ -62,18 +62,8 @@ endif ifeq ($(PORTNAME), cygwin) -postgres: $(OBJS) postgres.def libpostgres.a - $(DLLTOOL) --dllname $@$(X) --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -o $@$(X) -Wl,--base-file,$@.base $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - $(DLLTOOL) --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -Wl,--stack,$(WIN32_STACK_RLIMIT) -o $@$(X) $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - rm -f $@.exp $@.base - -postgres.def: $(OBJS) - $(DLLTOOL) --export-all --output-def $@ $(call expand_subsys,$^) - -libpostgres.a: postgres.def - $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ +postgres libpostgres.a: $(OBJS) + $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) $(export_dynamic) $(call expand_subsys,$^) $(LIBS) -o $@ -Wl,--stack,$(WIN32_STACK_RLIMIT) -Wl,--export-all-symbols -Wl,--out-implib=libpostgres.a endif # cygwin diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile index 7f2d901..721e248 100644 --- a/src/interfaces/libpq/Makefile +++ b/src/interfaces/libpq/Makefile @@ -45,7 +45,7 @@ OBJS += ip.o md5.o OBJS += encnames.o wchar.o ifeq ($(PORTNAME), cygwin) -override shlib = cyg$(NAME)$(DLSUFFIX) +override shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif ifeq ($(PORTNAME), win32) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] narwhal and PGDLLIMPORT
On 09/02/2014 00:06, Andrew Dunstan wrote: On 02/08/2014 05:34 PM, Tom Lane wrote: Hiroshi Inoue in...@tpf.co.jp writes: Though I'm not a MINGW expert at all, I know dllwrap is a deprecated tool and dlltool is almost a deprecated tool. Cygwin port is removing the use of dllwrap and dlltool now. Isn't it better for MINGW port to follow it? Only way to make that happen is to prepare and test a patch ... Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We did get rid of dllwrap. But I agree this is worth trying for Mingw. cheers andrew we should have get rid of dlltool on cygwin. At least it is not used on my build Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgresql for cygwin - 3rd
On 01/02/2014 22:57, Andrew Dunstan wrote: On 01/25/2014 01:23 PM, Andrew Dunstan wrote: * isolation tests fail with an indefinite hang on newer Cygwin * prepared_xacts test fails with an indefinite hang on newer Cygwin if run in parallel with other tests * tsearch tests fail on non-C locale (or at least on en_US.utf8). It turns out this is actually an old bug, and can be reproduced on my old Cygwin instance. I wonder if it's caused by faulty locale files? Andrew, is it possible the tsearch test never worked on en_US.utf8 but only on C locale ? See my finding on http://www.postgresql.org/message-id/52ed5627.4070...@gmail.com And these are where we need help, especially from the Cygwin community. The fact that things that work on older Cygwins now fail is annoying. cheers andrew Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgresql for cygwin - 3rd
On 25/01/2014 19:23, Andrew Dunstan wrote: On 01/24/2014 07:50 AM, Marco Atzeri wrote: Those two issues need to be fixed. And yes, they are regressions from my Cygwin 1.7.7 setup where they pass consistently, just about every day. See http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolgabr=HEAD 1.7.7 is 3.5 years hold. In the mean time we added 64 bit and moved to gcc-4.8.x No doubt, but that doesn't mean that extra things failing is OK. Andrew, I never wrote that. You don't get to choose which regression tests you're going to pass and which you're not. Disabling the tests or providing nonsensical results files are unacceptable. This is a Cygwin behavior issue and needs to be fixed. some indication where to look for in the code will help. Distributing broken binary that crashes after standard rebase, it is also not acceptable and it is also worst. Your farm is not testing this case, I presume. Quite so. But this is not a case of either/or. No, but I spent a lot of time on understanding that DLLTOLL/DLLWRAP produce buggy binaries, and that was a CRITICAL failure. I have now tested the central part of the proposed changes on both old and new Cygwin installations, and they appear to work. I'm going to commit them and backpatch back to 9.0, which is where we currently have buildfarm coverage (and 8.4 will be at EOL in a few months anyway). That will take care of your rebase issue. That leaves several issues to be handled: * LDAP libraries - the way you have proposed surely isn't right. What we want is something more like this in the Makefile.global.in: ifeq ($(PORTNAME), cygwin) libpq_pgport += $(LDAP_LIBS_FE) endif I will test in this way. I have no preferance on the implemented solution. * isolation tests fail with an indefinite hang on newer Cygwin * prepared_xacts test fails with an indefinite hang on newer Cygwin if run in parallel with other tests It hangs also stand alone. I guess some race or deadlock issue. * tsearch tests fail on non-C locale (or at least on en_US.utf8). It turns out this is actually an old bug, and can be reproduced on my old Cygwin instance. I wonder if it's caused by faulty locale files? Tested tsearch with export LANG=C works export LANG=C.utf8 fails export LANG=it_IT works export LANG=it_IT.utf8 fails faulty locale or wrong assumption on utf8 implementation ? Really, for a properly working port all these need to be fixed. No objection. Step by step I am available to work on tests regression, but I am not a postgresql expert so do not expect all the job from my side. We can help you some, but very few people in the community run Cygwin, and my time to spend on it is fairly limited. For the time being, I can run tests and builds. cheers andrew cheers Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgresql for cygwin - 3rd
On 25/01/2014 22:42, Marco Atzeri wrote: On 25/01/2014 19:23, Andrew Dunstan wrote: On 01/24/2014 07:50 AM, Marco Atzeri wrote: * LDAP libraries - the way you have proposed surely isn't right. What we want is something more like this in the Makefile.global.in: ifeq ($(PORTNAME), cygwin) libpq_pgport += $(LDAP_LIBS_FE) endif I will test in this way. I have no preferance on the implemented solution. your proposal builds fine. --- origsrc/postgresql-9.3.2/src/Makefile.global.in 2013-12-02 21:57:48.0 +0100 +++ src/postgresql-9.3.2/src/Makefile.global.in 2014-01-25 22:46:36.484816700 +0100 @@ -508,6 +508,11 @@ ifeq ($(PORTNAME),win32) LIBS += -lws2_32 -lshfolder endif +# missing for link on cygwin ? +ifeq ($(PORTNAME),cygwin) +libpq_pgport += $(LDAP_LIBS_FE) +endif + # Not really standard libc functions, used by the backend. Of course no difference on test results, as expected Attached full patch as I am currently testing on 9.3.2 Regards Marco --- origsrc/postgresql-9.3.2/src/Makefile.global.in 2013-12-02 21:57:48.0 +0100 +++ src/postgresql-9.3.2/src/Makefile.global.in 2014-01-25 22:46:36.484816700 +0100 @@ -508,6 +508,11 @@ ifeq ($(PORTNAME),win32) LIBS += -lws2_32 -lshfolder endif +# missing for link on cygwin ? +ifeq ($(PORTNAME),cygwin) +libpq_pgport += $(LDAP_LIBS_FE) +endif + # Not really standard libc functions, used by the backend. TAS = @TAS@ --- origsrc/postgresql-9.3.2/src/Makefile.shlib 2013-12-02 21:57:48.0 +0100 +++ src/postgresql-9.3.2/src/Makefile.shlib 2014-01-24 23:05:08.601675200 +0100 @@ -281,8 +281,9 @@ ifeq ($(PORTNAME), unixware) endif ifeq ($(PORTNAME), cygwin) + LINK.shared = $(CC) -shared ifdef SO_MAJOR_VERSION -shlib = cyg$(NAME)$(DLSUFFIX) +shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif haslibarule = yes endif @@ -371,6 +372,12 @@ else # PORTNAME == cygwin || PORTNAME == # If SHLIB_EXPORTS is set, the rules below will build a .def file from # that. Else we build a temporary one here. +ifeq ($(PORTNAME), cygwin) +$(shlib) $(stlib): $(OBJS) | $(SHLIB_PREREQS) + $(CC) $(CFLAGS) -shared -o $(shlib) -Wl,--out-implib=$(stlib) $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE) + + +else ifeq (,$(SHLIB_EXPORTS)) DLL_DEFFILE = lib$(NAME)dll.def exports_file = $(DLL_DEFFILE) @@ -387,6 +394,7 @@ $(shlib): $(OBJS) $(DLL_DEFFILE) | $(SHL $(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS) $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE) --output-lib $@ +endif # PORTNAME == cygwin endif # PORTNAME == cygwin || PORTNAME == win32 --- origsrc/postgresql-9.3.2/src/backend/Makefile 2013-12-02 21:57:48.0 +0100 +++ src/postgresql-9.3.2/src/backend/Makefile 2014-01-24 23:05:08.621675200 +0100 @@ -62,18 +62,8 @@ endif ifeq ($(PORTNAME), cygwin) -postgres: $(OBJS) postgres.def libpostgres.a - $(DLLTOOL) --dllname $@$(X) --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -o $@$(X) -Wl,--base-file,$@.base $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - $(DLLTOOL) --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -Wl,--stack,$(WIN32_STACK_RLIMIT) -o $@$(X) $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - rm -f $@.exp $@.base - -postgres.def: $(OBJS) - $(DLLTOOL) --export-all --output-def $@ $(call expand_subsys,$^) - -libpostgres.a: postgres.def - $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ +postgres libpostgres.a: $(OBJS) + $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) $(export_dynamic) $(call expand_subsys,$^) $(LIBS) -o $@ -Wl,--stack,$(WIN32_STACK_RLIMIT) -Wl,--export-all-symbols -Wl,--out-implib=libpostgres.a endif # cygwin --- origsrc/postgresql-9.3.2/src/interfaces/libpq/Makefile 2013-12-02 21:57:48.0 +0100 +++ src/postgresql-9.3.2/src/interfaces/libpq/Makefile 2014-01-24 23:05:08.621675200 +0100 @@ -45,7 +45,7 @@ OBJS += ip.o md5.o OBJS += encnames.o wchar.o ifeq ($(PORTNAME), cygwin) -override shlib = cyg$(NAME)$(DLSUFFIX) +override shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif ifeq ($(PORTNAME), win32) --- origsrc/postgresql-9.3.2/src/makefiles/Makefile.cygwin 2013-12-02 21:57:48.0 +0100 +++ src/postgresql-9.3.2/src/makefiles/Makefile.cygwin 2014-01-24 23:05:08.641675200 +0100 @@ -1,6 +1,4 @@ # src/makefiles/Makefile.cygwin -DLLTOOL= dlltool -DLLWRAP= dllwrap ifdef PGXS BE_DLLLIBS= -L$(libdir) -lpostgres else @@ -44,6 +42,4 @@ endif # Rule for building a shared library from a single .o file %.dll: %.o - $(DLLTOOL) --export-all --output-def $*.def
Re: [HACKERS] Postgresql for cygwin - 3rd
On 24/01/2014 12:56, Andrew Dunstan wrote: On 01/24/2014 01:20 AM, Marco Atzeri wrote: AFAICT the regression is in Cygwin. The buildfarm passes because it's using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I have brought the regression the athe attention of the Cygwin people in the past, but without response. which issue ? During my package tests I have only two issues: tsearch ... FAILED and test: prepared_xacts must be skipped as it never completes Those two issues need to be fixed. And yes, they are regressions from my Cygwin 1.7.7 setup where they pass consistently, just about every day. See http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=brolgabr=HEAD 1.7.7 is 3.5 years hold. In the mean time we added 64 bit and moved to gcc-4.8.x You don't get to choose which regression tests you're going to pass and which you're not. Disabling the tests or providing nonsensical results files are unacceptable. This is a Cygwin behavior issue and needs to be fixed. Distributing broken binary that crashes after standard rebase, it is also not acceptable and it is also worst. Your farm is not testing this case, I presume. Until I took over there was NO recent cygwin package at all in the distribution, so do not complain that my binary is not perfect, I already know, but for me almost working is better than NOT available or BROKEN. cheers andrew I am available to work on tests regression, but I am not a postgresql expert so do not expect all the job from my side. Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgresql for cygwin - 3rd
On 24/01/2014 05:28, Andrew Dunstan wrote: On 01/23/2014 10:50 PM, Bruce Momjian wrote: On Thu, Jan 23, 2014 at 10:48:01PM -0500, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Andrew, should this configuration/code patch be applied to 9.4? http://www.postgresql.org/message-id/51b59794.3000...@gmail.com I think we would have to make Cygwin-specific regression output to handle the regression failures, but frankly I am not even sure if they are right. Those regression failures certainly say there is something broken in the submitter's build, so this needs to be taken with a grain of salt. I'm not qualified to evaluate the proposed changes, but I wonder why they're needed given that we have successful cygwin builds in the buildfarm. Yes, that confuses me too. Unless we get more details, we should ignore the patches. Thanks. Andrew, nice to see, the question rises again. I dropped from the pgsql-hackers@postgresql.org some time ago, as no one was following the issue; I just rejoined. As explained here: http://cygwin.com/ml/cygwin/2013-03/msg00217.html http://cygwin.com/ml/cygwin/2013-03/msg00050.html 1) Using DLLTOOL/DLLWRAP postgresql dll's allocation table are partially wrong, so they fail at load after a rebase. the build farm can not test this rebase failure, as it will happen after installation at any rebase. DLLTOOL/DLLWRAP usage is really deprecated on cygwin as it produces damaged binaries that 2) I am the currently package mantainer for cygwin last I packged was postgresql-9.2.4 9.3.2 is on my TODO list AFAICT the regression is in Cygwin. The buildfarm passes because it's using an oldish Cygwin release, 1.7.7 rather than the current 1.7.27. I have brought the regression the athe attention of the Cygwin people in the past, but without response. which issue ? During my package tests I have only two issues: tsearch ... FAILED and test: prepared_xacts must be skipped as it never completes The build system changes have slipped off my radar, unfortunately. Not sure when I can get to them. Regars Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] install libpq.dll in bin directory on Windows / Cygwin
Il 7/25/2013 11:02 PM, Alvaro Herrera ha scritto: Andrew Dunstan wrote: Jeff Janes asked me about this, and Bruce just tripped up on it. Usually on Windows it's necessary to have libpq.dll/cygpq.dll either in the PATH or in the same directory as client .exe files. The buildfarm client has for many years simply copied this dll from the installation lib to the installation bin directory after running make install. But I can't really see why we don't do that as part of make install anyway. I haven't tested but I think something like this patch would achieve this goal - it would fix something that's tripped a lot of people up over the years. Seems a reasonable workaround for a silly platform bug. Do you need to patch the MSVC stuff as well? Comments? If we do this, should it be backported? To 9.3, sure, but not further back, as there's probably little point. on cygwin no need to go before 9.3 . We already moved them during the package build as workaround. +ifneq (,$findstring($(PORTNAME), win32 cygwin)) + $(INSTALL_DATA) $(shlib) '$(DESTDIR)$(bindir)/$(shlib)' +endif I wonder if someday we will create a win64 $(PORTNAME) value, or something like that, and then we'll have to update the port list on which these hacks are applied all over the place. Not complaining about this patch in particular, just an idle thought. Andrew, are you planning to include also http://www.postgresql.org/message-id/e1uqoyt-0007qc...@wrigleys.postgresql.org http://www.postgresql.org/message-id/51b59794.3000...@gmail.com to get rid of dllwrap ? Regards Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Postgresql for cygwin - 3rd
Il 3/6/2013 11:46 PM, Andrew Dunstan ha scritto: Excellent. Will test it out soon. cheers andrew Andrew, please find attached a full patch for cygwin relative to 9.3beta1 : - DLLTOLL/DLLWRAP are not used anymore, replaced by gcc also for postgres.exe (*) - DLL versioning is added Check failures: - prepared_xacts is still freezing The cygwin failure you highlighted was solved, so it should be something else - attached the 2 regressions diffs tsearch ... FAILED without_oid ... FAILED The second one seems a new one, not sure cygwin specific Regards Marco *) http://www.cygwin.com/ml/cygwin/2013-03/msg00032.html --- origsrc/postgresql-9.3beta1/src/Makefile.global.in 2013-05-06 22:57:06.0 +0200 +++ src/postgresql-9.3beta1/src/Makefile.global.in 2013-06-08 15:33:28.587266200 +0200 @@ -508,6 +508,11 @@ ifeq ($(PORTNAME),win32) LIBS += -lws2_32 -lshfolder endif +# missing for link on cygwin ? +ifeq ($(PORTNAME),cygwin) +LIBS += $(LDAP_LIBS_BE) +endif + # Not really standard libc functions, used by the backend. TAS = @TAS@ --- origsrc/postgresql-9.3beta1/src/Makefile.shlib 2013-05-06 22:57:06.0 +0200 +++ src/postgresql-9.3beta1/src/Makefile.shlib 2013-06-08 15:33:28.613267700 +0200 @@ -281,8 +281,9 @@ ifeq ($(PORTNAME), unixware) endif ifeq ($(PORTNAME), cygwin) + LINK.shared = $(CC) -shared ifdef SO_MAJOR_VERSION -shlib = cyg$(NAME)$(DLSUFFIX) +shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif haslibarule = yes endif @@ -371,6 +372,12 @@ else # PORTNAME == cygwin || PORTNAME == # If SHLIB_EXPORTS is set, the rules below will build a .def file from # that. Else we build a temporary one here. +ifeq ($(PORTNAME), cygwin) +$(shlib) $(stlib): $(OBJS) | $(SHLIB_PREREQS) + $(CC) $(CFLAGS) -shared -o $(shlib) -Wl,--out-implib=$(stlib) $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) $(LDAP_LIBS_BE) + + +else ifeq (,$(SHLIB_EXPORTS)) DLL_DEFFILE = lib$(NAME)dll.def exports_file = $(DLL_DEFFILE) @@ -387,6 +394,7 @@ $(shlib): $(OBJS) $(DLL_DEFFILE) | $(SHL $(stlib): $(shlib) $(DLL_DEFFILE) | $(SHLIB_PREREQS) $(DLLTOOL) --dllname $(shlib) $(DLLTOOL_LIBFLAGS) --def $(DLL_DEFFILE) --output-lib $@ +endif # PORTNAME == cygwin endif # PORTNAME == cygwin || PORTNAME == win32 --- origsrc/postgresql-9.3beta1/src/backend/Makefile2013-05-06 22:57:06.0 +0200 +++ src/postgresql-9.3beta1/src/backend/Makefile2013-06-08 15:33:28.633268800 +0200 @@ -62,18 +62,8 @@ endif ifeq ($(PORTNAME), cygwin) -postgres: $(OBJS) postgres.def libpostgres.a - $(DLLTOOL) --dllname $@$(X) --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -o $@$(X) -Wl,--base-file,$@.base $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - $(DLLTOOL) --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def - $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) -Wl,--stack,$(WIN32_STACK_RLIMIT) -o $@$(X) $@.exp $(call expand_subsys,$(OBJS)) $(LIBS) - rm -f $@.exp $@.base - -postgres.def: $(OBJS) - $(DLLTOOL) --export-all --output-def $@ $(call expand_subsys,$^) - -libpostgres.a: postgres.def - $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ +postgres libpostgres.a: $(OBJS) + $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_EX) $(export_dynamic) $(call expand_subsys,$^) $(LIBS) -o $@ -Wl,--stack,$(WIN32_STACK_RLIMIT) -Wl,--export-all-symbols -Wl,--out-implib=libpostgres.a endif # cygwin --- origsrc/postgresql-9.3beta1/src/interfaces/libpq/Makefile 2013-05-06 22:57:06.0 +0200 +++ src/postgresql-9.3beta1/src/interfaces/libpq/Makefile 2013-06-08 15:33:28.65427 +0200 @@ -45,7 +45,7 @@ OBJS += ip.o md5.o OBJS += encnames.o wchar.o ifeq ($(PORTNAME), cygwin) -override shlib = cyg$(NAME)$(DLSUFFIX) +override shlib = cyg$(NAME)-$(SO_MAJOR_VERSION)$(DLSUFFIX) endif ifeq ($(PORTNAME), win32) --- origsrc/postgresql-9.3beta1/src/makefiles/Makefile.cygwin 2013-05-06 22:57:06.0 +0200 +++ src/postgresql-9.3beta1/src/makefiles/Makefile.cygwin 2013-06-08 16:03:24.065961700 +0200 @@ -1,6 +1,4 @@ # src/makefiles/Makefile.cygwin -DLLTOOL= dlltool -DLLWRAP= dllwrap ifdef PGXS BE_DLLLIBS= -L$(libdir) -lpostgres else @@ -44,6 +42,4 @@ endif # Rule for building a shared library from a single .o file %.dll: %.o - $(DLLTOOL) --export-all --output-def $*.def $ - $(DLLWRAP) -o $@ --def $*.def $ $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS) - rm -f $*.def +$(CC) $(CFLAGS) -shared -o $@ $ $(LDFLAGS) $(LDFLAGS_SL) $(BE_DLLLIBS) *** /pub/devel/postgresql/postgresql-9.3beta1-1/src/postgresql-9.3beta1/src/test/regress/expected/tsearch.out 2013-05-06 22:57:06.0 +0200 --- /pub/devel/postgresql/postgresql-9.3beta1-1/build/src/test/regress/results/tsearch.out 2013-06-10
