install libpq.dll in bin directory on Windows / Cygwin
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?
cheers
andrew
Attachments:
install-libpq-dll.patchtext/x-patch; name=install-libpq-dll.patchDownload
diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile
index f116000..bece893 100644
--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile
@@ -115,18 +115,21 @@ fe-misc.o: fe-misc.c $(top_builddir)/src/port/pg_config_paths.h
$(top_builddir)/src/port/pg_config_paths.h:
$(MAKE) -C $(top_builddir)/src/port pg_config_paths.h
-install: all installdirs install-lib
+install: all installdirs install-lib install-dll-bin
$(INSTALL_DATA) $(srcdir)/libpq-fe.h '$(DESTDIR)$(includedir)'
$(INSTALL_DATA) $(srcdir)/libpq-events.h '$(DESTDIR)$(includedir)'
$(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)'
+ $(MKDIR_P) '$(DESTDIR)$(includedir)' '$(DESTDIR)$(includedir_internal)' '$(DESTDIR)$(datadir)' '$(DESTDIR)$(bindir)'
uninstall: uninstall-lib
rm -f '$(DESTDIR)$(includedir)/libpq-fe.h'
@@ -134,6 +137,9 @@ 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 $@
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 Herrera http://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
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
Import Notes
Reply to msg id not found: WM94d511915e77f75e6aeff9ba89d12f1dd1c01357f5352d29435bde6e037f72525911fc5d4b5dba56dea5c8a0998e8848@asav-1.01.com
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 Herrera http://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
From: "Andrew Dunstan" <andrew.dunstan@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
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)' +endifI 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
/messages/by-id/E1UqoYt-0007Qc-9E@wrigleys.postgresql.org
/messages/by-id/51B59794.3000500@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
On 07/25/2013 06:27 PM, MauMau wrote:
From: "Andrew Dunstan" <andrew.dunstan@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.dllThese 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
Import Notes
Reply to msg id not found: WM46b3fc31b95904e2ac9a934b846c047da252784e8055ffc17bd07f31eb778a5d9b470ba8b82d28aa8310aa486a8dc16e@asav-2.01.com
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
From: "Andrew Dunstan" <andrew@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" <andres@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
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 <bruce@momjian.us> http://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
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
Import Notes
Reply to msg id not found: WM6183d725dee83c850e5f95a63e7fc81c772c289c156ed4cfc87acdb3c5eaef3055a2672d7edb907146407119a116bd33@asav-3.01.com
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
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
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.
Attachments:
windows-lib-install.patchtext/x-patch; name=windows-lib-install.patchDownload
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 $@
On Wed, Feb 26, 2014 at 6:11 AM, Peter Eisentraut <peter_e@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
endifThe 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
On Mon, Dec 22, 2014 at 2:05 PM, Michael Paquier
<michael.paquier@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:
/messages/by-id/CAB7nPqQiUePzPhd3Mmk+Q7_cQQRKK_V1FVxKNyMRi660Z4dPzg@mail.gmail.com
Regards,
--
Michael
Attachments:
0001-Install-shared-libraries-in-bin-and-lib-with-MinGW-c.patchapplication/x-patch; name=0001-Install-shared-libraries-in-bin-and-lib-with-MinGW-c.patchDownload
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
0002-Install-shared-libraries-in-bin-and-lib-with-MSVC.patchapplication/x-patch; name=0002-Install-shared-libraries-in-bin-and-lib-with-MSVC.patchDownload
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 @@ sub CopySolutionOutput
while ($sln =~ $rem)
{
my $pf = $1;
- my $dir;
+ my @dirs;
my $ext;
+ my $is_sharedlib = 0;
$sln =~ s/$rem//;
@@ -247,17 +247,37 @@ sub CopySolutionOutput
my $proj = read_file("$pf.$vcproj")
|| croak "Could not open $pf.$vcproj\n";
+
+ # Check this project uses a shared library by looking if
+ # SO_MAJOR_VERSION is defined in its Makefile, whose path
+ # can be found using the resource file of this project.
+ if ($proj =~ qr{ResourceCompile\s*Include="([^"]+)"})
+ {
+ my $projpath = dirname($1);
+ my $mf = read_file($projpath . '/Makefile')
+ || croak "Could not open $projpath/Makefile\n";
+
+ if ($mf =~ /^SO_MAJOR_VERSION\s*=\s*(.*)$/mg)
+ {
+ $is_sharedlib = 1;
+ }
+ }
+
if ($vcproj eq 'vcproj' && $proj =~ qr{ConfigurationType="([^"]+)"})
{
if ($1 == 1)
{
- $dir = "bin";
+ @dirs = qw(bin);
$ext = "exe";
}
elsif ($1 == 2)
{
- $dir = "lib";
+ @dirs = qw(lib);
$ext = "dll";
+ if ($is_sharedlib)
+ {
+ push(@dirs, 'bin');
+ }
}
else
{
@@ -271,13 +291,17 @@ sub CopySolutionOutput
{
if ($1 eq 'Application')
{
- $dir = "bin";
+ @dirs = qw(bin);
$ext = "exe";
}
elsif ($1 eq 'DynamicLibrary')
{
- $dir = "lib";
+ @dirs = qw(lib);
$ext = "dll";
+ if ($is_sharedlib)
+ {
+ push(@dirs, 'bin');
+ }
}
else # 'StaticLibrary'
{
@@ -290,8 +314,11 @@ sub CopySolutionOutput
{
croak "Could not parse $pf.$vcproj\n";
}
- lcopy("$conf\\$pf\\$pf.$ext", "$target\\$dir\\$pf.$ext")
- || croak "Could not copy $pf.$ext\n";
+ foreach my $dir (@dirs)
+ {
+ lcopy("$conf\\$pf\\$pf.$ext", "$target\\$dir\\$pf.$ext")
+ || croak "Could not copy $pf.$ext\n";
+ }
lcopy("$conf\\$pf\\$pf.pdb", "$target\\symbols\\$pf.pdb")
|| croak "Could not copy $pf.pdb\n";
print ".";
--
2.2.1
On Wed, Dec 24, 2014 at 3:08 PM, Michael Paquier
<michael.paquier@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:
/messages/by-id/CAB7nPqQiUePzPhd3Mmk+Q7_cQQRKK_V1FVxKNyMRi660Z4dPzg@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
On 1/15/15 2:37 AM, Michael Paquier wrote:
On Wed, Dec 24, 2014 at 3:08 PM, Michael Paquier
<michael.paquier@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:
/messages/by-id/CAB7nPqQiUePzPhd3Mmk+Q7_cQQRKK_V1FVxKNyMRi660Z4dPzg@mail.gmail.comPeter, 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
On Mon, Jan 19, 2015 at 12:41 PM, Peter Eisentraut <peter_e@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