Re: [HACKERS] install libpq.dll in bin directory on Windows / Cygwin
On 1/15/15 2:37 AM, Michael Paquier wrote: On Wed, Dec 24, 2014 at 3:08 PM, Michael Paquier michael.paqu...@gmail.com wrote: Attached are two patches, one for MinGW/cygwin, a slightly modified version from Peter and the second implementing the same thing but for the MSVC scripts. The method for MSVC is similar to what is done in Peter's patch: roughly it checks if SO_MAJOR_VERSION is present in the Makefile of a given library, the path of Makefile is found by looking at the location of the .rc in the vcproj file (could be better but I could not come up with a better method). TBH, it would be good to be completely consistent in the way we build things on Windows, and we may as well consider a backpatch to fix this long-standing bug. The MSVC patch removes of course the hack copying libpq.dll from lib/ to bin/. I mentioned the fix for MSVC scripts as well here: http://www.postgresql.org/message-id/cab7npqqiuepzphd3mmk+q7_cqqrkk_v1fvxknymri660z4d...@mail.gmail.com Peter, this patch is waiting for input for a couple of weeks. IMO, it would be good to finally get a fix for this bug, and we have patches for both MSVC (the patch I sent) and mingw (your stuff). I have committed my mingw portion, but I cannot take on the MSVC part. -- 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
On Mon, Jan 19, 2015 at 12:41 PM, Peter Eisentraut pete...@gmx.net wrote: I have committed my mingw portion, but I cannot take on the MSVC part. OK, no problem. Perhaps I should add a new entry in the next CF for the MSVC portion? -- Michael -- 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
On Wed, Dec 24, 2014 at 3:08 PM, Michael Paquier michael.paqu...@gmail.com wrote: Attached are two patches, one for MinGW/cygwin, a slightly modified version from Peter and the second implementing the same thing but for the MSVC scripts. The method for MSVC is similar to what is done in Peter's patch: roughly it checks if SO_MAJOR_VERSION is present in the Makefile of a given library, the path of Makefile is found by looking at the location of the .rc in the vcproj file (could be better but I could not come up with a better method). TBH, it would be good to be completely consistent in the way we build things on Windows, and we may as well consider a backpatch to fix this long-standing bug. The MSVC patch removes of course the hack copying libpq.dll from lib/ to bin/. I mentioned the fix for MSVC scripts as well here: http://www.postgresql.org/message-id/cab7npqqiuepzphd3mmk+q7_cqqrkk_v1fvxknymri660z4d...@mail.gmail.com Peter, this patch is waiting for input for a couple of weeks. IMO, it would be good to finally get a fix for this bug, and we have patches for both MSVC (the patch I sent) and mingw (your stuff). -- Michael -- 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
On Mon, Dec 22, 2014 at 2:05 PM, Michael Paquier michael.paqu...@gmail.com wrote: Peter, could it be possible to merge this patch with its MSVC portion for simplicity? I think that it would more readable to do all the changes at the same time once and for all. Also, that's still a bug, so are we still considering a backpatch? I wouldn't mind putting some time into a patch to get that fixed.. Attached are two patches, one for MinGW/cygwin, a slightly modified version from Peter and the second implementing the same thing but for the MSVC scripts. The method for MSVC is similar to what is done in Peter's patch: roughly it checks if SO_MAJOR_VERSION is present in the Makefile of a given library, the path of Makefile is found by looking at the location of the .rc in the vcproj file (could be better but I could not come up with a better method). TBH, it would be good to be completely consistent in the way we build things on Windows, and we may as well consider a backpatch to fix this long-standing bug. The MSVC patch removes of course the hack copying libpq.dll from lib/ to bin/. I mentioned the fix for MSVC scripts as well here: http://www.postgresql.org/message-id/cab7npqqiuepzphd3mmk+q7_cqqrkk_v1fvxknymri660z4d...@mail.gmail.com Regards, -- Michael From 23c3fd58d65309e2ee6cc5ada9c3dee37110c70d Mon Sep 17 00:00:00 2001 From: Michael Paquier michael@otacoo.com Date: Tue, 23 Dec 2014 05:01:38 -0800 Subject: [PATCH 1/2] Install shared libraries in bin/ and lib/ with MinGW/cygwin Those libraries can be found by scanning for SO_MAJOR_VERSION in their respective Makefiles. --- src/Makefile.shlib| 11 ++- src/interfaces/libpq/Makefile | 9 - 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/Makefile.shlib b/src/Makefile.shlib index 674fe7e..c3af1fe 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -486,6 +486,9 @@ endif endif # not win32 endif # not cygwin endif # not aix +ifneq (,$(findstring $(PORTNAME),win32 cygwin)) + $(INSTALL_SHLIB) $ '$(DESTDIR)$(bindir)/$(shlib)' +endif else # no soname $(INSTALL_SHLIB) $ '$(DESTDIR)$(pkglibdir)/$(shlib)' endif @@ -494,7 +497,10 @@ endif installdirs-lib: ifdef soname $(MKDIR_P) '$(DESTDIR)$(libdir)' '$(DESTDIR)$(pkgconfigdir)' -else +ifneq (,$(findstring $(PORTNAME),win32 cygwin)) + $(MKDIR_P) '$(DESTDIR)$(bindir)' +endif +else # no soname $(MKDIR_P) '$(DESTDIR)$(pkglibdir)' endif @@ -511,6 +517,9 @@ ifdef soname '$(DESTDIR)$(libdir)/$(shlib_major)' \ '$(DESTDIR)$(libdir)/$(shlib)' \ '$(DESTDIR)$(pkgconfigdir)/lib$(NAME).pc' +ifneq (,$(findstring $(PORTNAME),win32 cygwin)) + rm -f '$(DESTDIR)$(bindir)/$(shlib)' +endif else # no soname rm -f '$(DESTDIR)$(pkglibdir)/$(shlib)' endif # no soname diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile index 18d9b85..5f0042e 100644 --- a/src/interfaces/libpq/Makefile +++ b/src/interfaces/libpq/Makefile @@ -125,18 +125,12 @@ install: all installdirs install-lib $(INSTALL_DATA) $(srcdir)/libpq-int.h '$(DESTDIR)$(includedir_internal)' $(INSTALL_DATA) $(srcdir)/pqexpbuffer.h '$(DESTDIR)$(includedir_internal)' $(INSTALL_DATA) $(srcdir)/pg_service.conf.sample '$(DESTDIR)$(datadir)/pg_service.conf.sample' -ifneq (,$(findstring $(PORTNAME), win32 cygwin)) - $(INSTALL_SHLIB) $(shlib) '$(DESTDIR)$(bindir)/$(shlib)' -endif installcheck: $(MAKE) -C test $@ installdirs: installdirs-lib $(MKDIR_P) '$(DESTDIR)$(includedir)' '$(DESTDIR)$(includedir_internal)' '$(DESTDIR)$(datadir)' -ifneq (,$(findstring $(PORTNAME), win32 cygwin)) - $(MKDIR_P) '$(DESTDIR)$(bindir)' -endif uninstall: uninstall-lib rm -f '$(DESTDIR)$(includedir)/libpq-fe.h' @@ -144,9 +138,6 @@ uninstall: uninstall-lib rm -f '$(DESTDIR)$(includedir_internal)/libpq-int.h' rm -f '$(DESTDIR)$(includedir_internal)/pqexpbuffer.h' rm -f '$(DESTDIR)$(datadir)/pg_service.conf.sample' -ifneq (,$(findstring $(PORTNAME), win32 cygwin)) - rm -f '$(DESTDIR)$(bindir)/$(shlib)' -endif clean distclean: clean-lib $(MAKE) -C test $@ -- 2.2.1 From 13ca64cb5cdae419d6ee1bbf7c7a04f6bd3d2388 Mon Sep 17 00:00:00 2001 From: Michael Paquier michael@otacoo.com Date: Tue, 23 Dec 2014 21:58:50 -0800 Subject: [PATCH 2/2] Install shared libraries in bin/ and lib/ with MSVC This is the MSVC part of the previous commit, to ensure that install is completely consistent with the multiple methods supported. --- src/tools/msvc/Install.pm | 43 +++ 1 file changed, 35 insertions(+), 8 deletions(-) diff --git a/src/tools/msvc/Install.pm b/src/tools/msvc/Install.pm index eba9aa0..616cd9d 100644 --- a/src/tools/msvc/Install.pm +++ b/src/tools/msvc/Install.pm @@ -91,7 +91,6 @@ sub Install } CopySolutionOutput($conf, $target); - lcopy($target . '/lib/libpq.dll', $target . '/bin/libpq.dll'); my $sample_files = []; my @top_dir = (src); @top_dir = (src\\bin, src\\interfaces) if ($insttype eq client); @@ -236,8 +235,9 @@
Re: [HACKERS] install libpq.dll in bin directory on Windows / Cygwin
On Wed, Feb 26, 2014 at 6:11 AM, Peter Eisentraut pete...@gmx.net wrote: On 2/1/14, 3:22 PM, Andrew Dunstan wrote: In the end I went with the way I had suggested, because that's what the MSVC system does - it doesn't copy any other DLLs to the bin directory. So doing that seemed sane for backpatching, to bring the two build systems into sync. If you want to propose a better arrangement for the future, to include, say, ecpg DLLs, and including changes to the MSVC system, we can discuss that separately. See attached patch. There is also the commit fest item https://commitfest.postgresql.org/action/patch_view?id=1330 that requests the MSVC builds to install the epcg libraries in the bin directory. Looking finally at this patch. In short, it moves to bin/ libpgtypes.dll, libecpg.dll and libecpg_compat.dll for cygwin and MinGW build using some additional processing in Makefile.shlib, removing at the same time the win32 stuff in libpq/Makefile. IMO, it would be more readable to replace this part with a separate if block for readability. So changing that: - '$(DESTDIR)$(libdir)/$(shlib)' \ + '$(DESTDIR)$(libdir)/$(shlib)' $(if $(findstring $(PORTNAME),win32 cygwin),'$(DESTDIR)$(bindir)/$(shlib)') \ For that: ifneq(blah) blah2 endif The MSVC portion of this fix got completely lost in the void: https://commitfest.postgresql.org/action/patch_view?id=1330 Peter, could it be possible to merge this patch with its MSVC portion for simplicity? I think that it would more readable to do all the changes at the same time once and for all. Also, that's still a bug, so are we still considering a backpatch? I wouldn't mind putting some time into a patch to get that fixed.. Regards, -- Michael -- 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
On 2/1/14, 3:22 PM, Andrew Dunstan wrote: In the end I went with the way I had suggested, because that's what the MSVC system does - it doesn't copy any other DLLs to the bin directory. So doing that seemed sane for backpatching, to bring the two build systems into sync. If you want to propose a better arrangement for the future, to include, say, ecpg DLLs, and including changes to the MSVC system, we can discuss that separately. See attached patch. There is also the commit fest item https://commitfest.postgresql.org/action/patch_view?id=1330 that requests the MSVC builds to install the epcg libraries in the bin directory. diff --git a/src/Makefile.shlib b/src/Makefile.shlib index 029c7e9..c04e2ef 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -484,6 +484,9 @@ endif endif # not win32 endif # not cygwin endif # not aix +ifneq (,$(findstring $(PORTNAME),win32 cygwin)) + $(INSTALL_SHLIB) $ '$(DESTDIR)$(bindir)/$(shlib)' +endif else # no soname $(INSTALL_SHLIB) $ '$(DESTDIR)$(pkglibdir)/$(shlib)' endif @@ -491,7 +494,7 @@ endif installdirs-lib: ifdef soname - $(MKDIR_P) '$(DESTDIR)$(libdir)' '$(DESTDIR)$(pkgconfigdir)' + $(MKDIR_P) '$(DESTDIR)$(libdir)' '$(DESTDIR)$(pkgconfigdir)' $(if $(findstring $(PORTNAME),win32 cygwin),'$(DESTDIR)$(bindir)') else $(MKDIR_P) '$(DESTDIR)$(pkglibdir)' endif @@ -507,7 +510,7 @@ ifdef soname rm -f '$(DESTDIR)$(libdir)/$(stlib)' rm -f '$(DESTDIR)$(libdir)/$(shlib_bare)' \ '$(DESTDIR)$(libdir)/$(shlib_major)' \ - '$(DESTDIR)$(libdir)/$(shlib)' \ + '$(DESTDIR)$(libdir)/$(shlib)' $(if $(findstring $(PORTNAME),win32 cygwin),'$(DESTDIR)$(bindir)/$(shlib)') \ '$(DESTDIR)$(pkgconfigdir)/lib$(NAME).pc' else # no soname rm -f '$(DESTDIR)$(pkglibdir)/$(shlib)' diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile index 7f2d901..2d11816 100644 --- a/src/interfaces/libpq/Makefile +++ b/src/interfaces/libpq/Makefile @@ -121,18 +121,12 @@ install: all installdirs install-lib $(INSTALL_DATA) $(srcdir)/libpq-int.h '$(DESTDIR)$(includedir_internal)' $(INSTALL_DATA) $(srcdir)/pqexpbuffer.h '$(DESTDIR)$(includedir_internal)' $(INSTALL_DATA) $(srcdir)/pg_service.conf.sample '$(DESTDIR)$(datadir)/pg_service.conf.sample' -ifneq (,$(findstring $(PORTNAME), win32 cygwin)) - $(INSTALL_DATA) $(shlib) '$(DESTDIR)$(bindir)/$(shlib)' -endif installcheck: $(MAKE) -C test $@ installdirs: installdirs-lib $(MKDIR_P) '$(DESTDIR)$(includedir)' '$(DESTDIR)$(includedir_internal)' '$(DESTDIR)$(datadir)' -ifneq (,$(findstring $(PORTNAME), win32 cygwin)) - $(MKDIR_P) '$(DESTDIR)$(bindir)' -endif uninstall: uninstall-lib rm -f '$(DESTDIR)$(includedir)/libpq-fe.h' @@ -140,9 +134,6 @@ uninstall: uninstall-lib rm -f '$(DESTDIR)$(includedir_internal)/libpq-int.h' rm -f '$(DESTDIR)$(includedir_internal)/pqexpbuffer.h' rm -f '$(DESTDIR)$(datadir)/pg_service.conf.sample' -ifneq (,$(findstring $(PORTNAME), win32 cygwin)) - rm -f '$(DESTDIR)$(bindir)/$(shlib)' -endif clean distclean: clean-lib $(MAKE) -C test $@ -- 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
On 1/31/14, 12:47 PM, Andrew Dunstan wrote: Hmm, looks like it got dropped. I think my original patch is probably about the the right thing to do, and given that it's already done by the MSVC build it's a bug and should be backported, as Alvaro said in the original discussion. I'll get on that shortly - since the patch was untested I'll need to do a test first. I think this change is reasonable to make, but it should be in Makefile.shlib, not in libpq/Makefile. Makefile.shlib already knows about the difference between a link-time and a run-time dynamic library (not to speak of Windows vs. others), so the right change there will make it work for libpq, ecpg, and whatever else someone might come up with automatically. -- 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
On 02/01/2014 08:01 AM, Peter Eisentraut wrote: On 1/31/14, 12:47 PM, Andrew Dunstan wrote: Hmm, looks like it got dropped. I think my original patch is probably about the the right thing to do, and given that it's already done by the MSVC build it's a bug and should be backported, as Alvaro said in the original discussion. I'll get on that shortly - since the patch was untested I'll need to do a test first. I think this change is reasonable to make, but it should be in Makefile.shlib, not in libpq/Makefile. Makefile.shlib already knows about the difference between a link-time and a run-time dynamic library (not to speak of Windows vs. others), so the right change there will make it work for libpq, ecpg, and whatever else someone might come up with automatically. In the end I went with the way I had suggested, because that's what the MSVC system does - it doesn't copy any other DLLs to the bin directory. So doing that seemed sane for backpatching, to bring the two build systems into sync. If you want to propose a better arrangement for the future, to include, say, ecpg DLLs, and including changes to the MSVC system, we can discuss that separately. cheers andrew -- 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
On Thu, Jul 25, 2013 at 04:53:45PM -0400, 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. Comments? If we do this, should it be backported? Andrew, where are we on this? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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
On 01/31/2014 12:25 PM, Bruce Momjian wrote: On Thu, Jul 25, 2013 at 04:53:45PM -0400, 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. Comments? If we do this, should it be backported? Andrew, where are we on this? Hmm, looks like it got dropped. I think my original patch is probably about the the right thing to do, and given that it's already done by the MSVC build it's a bug and should be backported, as Alvaro said in the original discussion. I'll get on that shortly - since the patch was untested I'll need to do a test first. cheers andrew -- 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
From: Andrew Dunstan and...@dunslane.net I don't have a problem adding them to the bin directory. I'd be very slightly wary of removing them from the lib directory, for legacy reasons. Maybe these changes should be done for git tip and not backported (or maybe just to 9.3). Or we could just decide to clean this mess in one fell swoop. I think just adding them to the bin is enough for convenience. I don't think backporting to 9.2 and before is necessary, if we consider this change as an improvement. I'd appreciate it if you could do that for 9.3 and later. From: Andres Freund and...@anarazel.de On 2013-07-28 15:37:49 -0400, Andrew Dunstan wrote: BTW, why is libpq.dll in lib necessary? For the above files? If so, we can remove libpq.dll from lib. Or, libpqwalreceiver.dll needs it? Not sure. Perhaps you could experiment and see if anything bad happens if libpq is just installed in the bin directory and not in lib. Yes, it does need it. Just out of curiosity, what needs libpq.dll in lib? Regards MauMau -- 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
On 07/25/2013 06:27 PM, MauMau wrote: From: Andrew Dunstan andrew.duns...@pgexperts.com 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. Comments? If we do this, should it be backported? I was just about to propose something related to this. On native Windows (not on Cygwin or MinGW), DLLs are in general placed in (1) system directory (e.g. c:\windows\system32), (2) somewhere in PATH, or (3) the same directory as EXEs which automatically load the DLL at invocation. It's no problem that most DLLs in PostgreSQL's lib directory, because they are loaded at runtime by postgres.exe by calling LoadLibrary() specifying an absolute or a relative path. However, the below files are misplaced: libecpg.dll libecpg_compat.dll libpgtypes.dll These should be placed in bin directory. If done so, when running SQL embedded C applications, users can just add bin in PATH, which is usually done already. Otherwise, users have to add both bin and lib in PATH. Usually, lib is not added in PATH in many software. Could you please place the above files in bin and remove them from lib? I don't have a problem adding them to the bin directory. I'd be very slightly wary of removing them from the lib directory, for legacy reasons. Maybe these changes should be done for git tip and not backported (or maybe just to 9.3). Or we could just decide to clean this mess in one fell swoop. BTW, why is libpq.dll in lib necessary? For the above files? If so, we can remove libpq.dll from lib. Or, libpqwalreceiver.dll needs it? Not sure. Perhaps you could experiment and see if anything bad happens if libpq is just installed in the bin directory and not in lib. cheers andrew -- 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
On 2013-07-28 15:37:49 -0400, Andrew Dunstan wrote: BTW, why is libpq.dll in lib necessary? For the above files? If so, we can remove libpq.dll from lib. Or, libpqwalreceiver.dll needs it? Not sure. Perhaps you could experiment and see if anything bad happens if libpq is just installed in the bin directory and not in lib. Yes, it does need it. Andres -- 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
Re: [HACKERS] install libpq.dll in bin directory on Windows / Cygwin
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. +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. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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
On 07/25/2013 05:02 PM, Alvaro Herrera wrote: 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? MSVC already does it - see src/tools/msvc/Install.pm: lcopy($target . '/lib/libpq.dll', $target . '/bin/libpq.dll'); cheers andrew -- 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
Andrew Dunstan wrote: On 07/25/2013 05:02 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: 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. Seems a reasonable workaround for a silly platform bug. Do you need to patch the MSVC stuff as well? MSVC already does it - see src/tools/msvc/Install.pm: lcopy($target . '/lib/libpq.dll', $target . '/bin/libpq.dll'); Oh, so your patch is just a bug fix and we should backpatch it all the way, no? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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
From: Andrew Dunstan andrew.duns...@pgexperts.com 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. Comments? If we do this, should it be backported? I was just about to propose something related to this. On native Windows (not on Cygwin or MinGW), DLLs are in general placed in (1) system directory (e.g. c:\windows\system32), (2) somewhere in PATH, or (3) the same directory as EXEs which automatically load the DLL at invocation. It's no problem that most DLLs in PostgreSQL's lib directory, because they are loaded at runtime by postgres.exe by calling LoadLibrary() specifying an absolute or a relative path. However, the below files are misplaced: libecpg.dll libecpg_compat.dll libpgtypes.dll These should be placed in bin directory. If done so, when running SQL embedded C applications, users can just add bin in PATH, which is usually done already. Otherwise, users have to add both bin and lib in PATH. Usually, lib is not added in PATH in many software. Could you please place the above files in bin and remove them from lib? BTW, why is libpq.dll in lib necessary? For the above files? If so, we can remove libpq.dll from lib. Or, libpqwalreceiver.dll needs it? Regards MauMau -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
