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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sandro Mani

Currently building postgresql for Win32 with a mingw toolchain produces import libraries with *.a extension, whereas the extension should be *.dll.a. There are various downstream workarounds for this, see i.e. [1] and [2]. The attached patch 0001-Fix-import-library-extension.patch addresses this.

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.

Thanks Sandro

[1] https://src.fedoraproject.org/rpms/mingw-postgresql/blob/master/f/mingw-postgresql.spec#_144 [2] https://aur.archlinux.org/cgit/aur.git/tree/0001-Use-.dll.a-as-extension-for-import-libraries.patch?h=mingw-w64-postgresql


0001-Fix-import-library-extension.patch (4K) Download Attachment
0002-Build-static-libraries.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Sandro Mani
Any chance these patches could be considered?

Thanks
Sandro

On Thu, Mar 7, 2019 at 3:23 PM Sandro Mani <[hidden email]> wrote:

Currently building postgresql for Win32 with a mingw toolchain produces import libraries with *.a extension, whereas the extension should be *.dll.a. There are various downstream workarounds for this, see i.e. [1] and [2]. The attached patch 0001-Fix-import-library-extension.patch addresses this.

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.

Thanks Sandro

[1] https://src.fedoraproject.org/rpms/mingw-postgresql/blob/master/f/mingw-postgresql.spec#_144 [2] https://aur.archlinux.org/cgit/aur.git/tree/0001-Use-.dll.a-as-extension-for-import-libraries.patch?h=mingw-w64-postgresql

Reply | Threaded
Open this post in threaded view
|

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

Robert Haas
On Tue, Apr 2, 2019 at 5:32 AM Sandro Mani <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Noah Misch-2
In reply to this post by Sandro Mani
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&dt=2019-04-15%2022%3A35%3A52&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


Reply | Threaded
Open this post in threaded view
|

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

Andrew Dunstan-8

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&dt=2019-04-15%2022%3A35%3A52&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



Reply | Threaded
Open this post in threaded view
|

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

Noah Misch-2
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&dt=2019-04-15%2022%3A35%3A52&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.