[Patch] Mingw: Fix import library extension, build actual static libraries

Any chance these patches could be considered?

Thanks
Sandro

On Thu, Mar 7, 2019 at 3:23 PM Sandro Mani <manisandro@gmail.com> wrote:

On Tue, Apr 2, 2019 at 5:32 AM Sandro Mani <manisandro@gmail.com> wrote:

Any chance these patches could be considered?

You should add them to the Open CommitFest, currently
https://commitfest.postgresql.org/23/

That CommitFest is scheduled to start in July; we are about to go to
feature freeze for v12, and your patch was submitted after the last
CommitFest for v12 had already started. That doesn't *necessarily*
mean that someone won't make an argument for including your patch in
v12 rather than making it wait another year, if for example it is
viewed to be a bug fix, but the odds are against you, because a lot of
other people's patches have been in line for much longer.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Mar 07, 2019 at 03:23:50PM +0100, Sandro Mani wrote:

Related, no actual static libraries are produced alongside the respective
dlls. The attached patch 0002-Build-static-libraries.patch addresses this,
in a similar fashion as is already done for the AIX case in Makefile.shlib.

We don't build static libraries on AIX, though Makefile.shlib uses the
$(stlib) variable to get a name for the *.a shared library it makes. Here's
an example of one AIX Makefile.shlib build sequence, from
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hornet&amp;dt=2019-04-15%2022%3A35%3A52&amp;stg=make

rm -f libpq.a
ar crs libpq.a fe-auth.o fe-auth-scram.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o fe-secure.o libpq-events.o encnames.o wchar.o fe-secure-openssl.o fe-secure-common.o
touch libpq.a
../../../src/backend/port/aix/mkldexport.sh libpq.a libpq.so.5 >libpq.exp
xlc_r -qmaxmem=33554432 -D_LARGE_FILES=1 -qnoansialias -g -O2 -qmaxmem=16384 -qsrcmsg -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -o libpq.so.5 libpq.a -Wl,-bE:libpq.exp -L../../../src/port -L../../../src/common -lpgcommon_shlib -lpgport_shlib -L/home/nm/sw/nopath/libxml2-64/lib -L/home/nm/sw/nopath/icu58.2-64/lib -L/home/nm/sw/nopath/uuid-64/lib -L/home/nm/sw/nopath/openldap-64/lib -L/home/nm/sw/nopath/icu58.2-64/lib -L/home/nm/sw/nopath/libxml2-64/lib -Wl,-blibpath:'/home/nm/farm/xlc64/HEAD/inst/lib:/home/nm/sw/nopath/libxml2-64/lib:/home/nm/sw/nopath/icu58.2-64/lib:/home/nm/sw/nopath/uuid-64/lib:/home/nm/sw/nopath/openldap-64/lib:/home/nm/sw/nopath/icu58.2-64/lib:/home/nm/sw/nopath/libxml2-64/lib:/usr/lib:/lib' -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE -lintl -lssl -lcrypto -lm -lldap_r -llber -lpthreads
rm -f libpq.a
ar crs libpq.a libpq.so.5

On 4/16/19 1:22 AM, Noah Misch wrote:

On Thu, Mar 07, 2019 at 03:23:50PM +0100, Sandro Mani wrote:

Related, no actual static libraries are produced alongside the respective
dlls. The attached patch 0002-Build-static-libraries.patch addresses this,
in a similar fashion as is already done for the AIX case in Makefile.shlib.

We don't build static libraries on AIX, though Makefile.shlib uses the
$(stlib) variable to get a name for the *.a shared library it makes. Here's
an example of one AIX Makefile.shlib build sequence, from
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hornet&amp;dt=2019-04-15%2022%3A35%3A52&amp;stg=make

rm -f libpq.a
ar crs libpq.a fe-auth.o fe-auth-scram.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o fe-secure.o libpq-events.o encnames.o wchar.o fe-secure-openssl.o fe-secure-common.o
touch libpq.a
../../../src/backend/port/aix/mkldexport.sh libpq.a libpq.so.5 >libpq.exp
xlc_r -qmaxmem=33554432 -D_LARGE_FILES=1 -qnoansialias -g -O2 -qmaxmem=16384 -qsrcmsg -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -o libpq.so.5 libpq.a -Wl,-bE:libpq.exp -L../../../src/port -L../../../src/common -lpgcommon_shlib -lpgport_shlib -L/home/nm/sw/nopath/libxml2-64/lib -L/home/nm/sw/nopath/icu58.2-64/lib -L/home/nm/sw/nopath/uuid-64/lib -L/home/nm/sw/nopath/openldap-64/lib -L/home/nm/sw/nopath/icu58.2-64/lib -L/home/nm/sw/nopath/libxml2-64/lib -Wl,-blibpath:'/home/nm/farm/xlc64/HEAD/inst/lib:/home/nm/sw/nopath/libxml2-64/lib:/home/nm/sw/nopath/icu58.2-64/lib:/home/nm/sw/nopath/uuid-64/lib:/home/nm/sw/nopath/openldap-64/lib:/home/nm/sw/nopath/icu58.2-64/lib:/home/nm/sw/nopath/libxml2-64/lib:/usr/lib:/lib' -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE -lintl -lssl -lcrypto -lm -lldap_r -llber -lpthreads
rm -f libpq.a
ar crs libpq.a libpq.so.5

I'm wondering if it wouldn't be better to set the value of stlib for
windows, instead of changes like this:

-    $(CC) $(CFLAGS)  -shared -static-libgcc -o $@  $(OBJS) $(LDFLAGS)
$(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) -Wl,--export-all-symbols
-Wl,--out-implib=$(stlib)
+    $(CC) $(CFLAGS)  -shared -static-libgcc -o $@  $(OBJS) $(LDFLAGS)
$(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) -Wl,--export-all-symbols
-Wl,--out-implib=lib$(NAME).dll.a

I'm also wondering if changing this will upset third party authors.

Thoughts?

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Jul 09, 2019 at 08:26:52AM -0400, Andrew Dunstan wrote:

On 4/16/19 1:22 AM, Noah Misch wrote:

On Thu, Mar 07, 2019 at 03:23:50PM +0100, Sandro Mani wrote:

Related, no actual static libraries are produced alongside the respective
dlls. The attached patch 0002-Build-static-libraries.patch addresses this,
in a similar fashion as is already done for the AIX case in Makefile.shlib.

We don't build static libraries on AIX, though Makefile.shlib uses the
$(stlib) variable to get a name for the *.a shared library it makes. Here's
an example of one AIX Makefile.shlib build sequence, from
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hornet&amp;dt=2019-04-15%2022%3A35%3A52&amp;stg=make

rm -f libpq.a
ar crs libpq.a fe-auth.o fe-auth-scram.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o fe-secure.o libpq-events.o encnames.o wchar.o fe-secure-openssl.o fe-secure-common.o
touch libpq.a
../../../src/backend/port/aix/mkldexport.sh libpq.a libpq.so.5 >libpq.exp
xlc_r -qmaxmem=33554432 -D_LARGE_FILES=1 -qnoansialias -g -O2 -qmaxmem=16384 -qsrcmsg -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -o libpq.so.5 libpq.a -Wl,-bE:libpq.exp -L../../../src/port -L../../../src/common -lpgcommon_shlib -lpgport_shlib -L/home/nm/sw/nopath/libxml2-64/lib -L/home/nm/sw/nopath/icu58.2-64/lib -L/home/nm/sw/nopath/uuid-64/lib -L/home/nm/sw/nopath/openldap-64/lib -L/home/nm/sw/nopath/icu58.2-64/lib -L/home/nm/sw/nopath/libxml2-64/lib -Wl,-blibpath:'/home/nm/farm/xlc64/HEAD/inst/lib:/home/nm/sw/nopath/libxml2-64/lib:/home/nm/sw/nopath/icu58.2-64/lib:/home/nm/sw/nopath/uuid-64/lib:/home/nm/sw/nopath/openldap-64/lib:/home/nm/sw/nopath/icu58.2-64/lib:/home/nm/sw/nopath/libxml2-64/lib:/usr/lib:/lib' -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE -lintl -lssl -lcrypto -lm -lldap_r -llber -lpthreads
rm -f libpq.a
ar crs libpq.a libpq.so.5

I'm wondering if it wouldn't be better to set the value of stlib for
windows, instead of changes like this:

-��� $(CC) $(CFLAGS)� -shared -static-libgcc -o $@� $(OBJS) $(LDFLAGS)
$(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) -Wl,--export-all-symbols
-Wl,--out-implib=$(stlib)
+��� $(CC) $(CFLAGS)� -shared -static-libgcc -o $@� $(OBJS) $(LDFLAGS)
$(LDFLAGS_SL) $(SHLIB_LINK) $(LIBS) -Wl,--export-all-symbols
-Wl,--out-implib=lib$(NAME).dll.a

If we're going to have both static libs and import libs, they need different
names. But it may be an improvement to set implib = lib$(NAME).dll.a and use
$(implib) in Make recipes like this one.

I'm also wondering if changing this will upset third party authors.

I'd make it master-only, but I don't expect big trouble. GNU ld does pick
libFOO.dll.a when both that and libFOO.a are available. Folks probably have
scripts that copy libpq.a to libpq.lib for the benefit of MSVC, and those
would need to change.

On 2019-03-07 15:23, Sandro Mani wrote:

Currently building postgresql for Win32 with a mingw toolchain produces
import libraries with *.a extension, whereas the extension should be
*.dll.a.

I have read the MinGW documentation starting from
<http://www.mingw.org/wiki/DLL&gt; and have found no information supporting
this claim. All their examples match our existing naming. What is your
source for this information -- other than ...

There are various downstream workarounds for this, see i.e. [1]
and [2]. The attached patch 0001-Fix-import-library-extension.patch
addresses this.

I'm confused what Fedora and Arch Linux have to do with this. Are they
distributing Windows binaries of third-party software?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services