Re: [Patch] Mingw: Fix import library extension, build actual staticlibraries - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [Patch] Mingw: Fix import library extension, build actual staticlibraries
Date
Msg-id 20190712013429.GC1610889@rfd.leadboat.com
Whole thread Raw
In response to Re: [Patch] Mingw: Fix import library extension, build actual staticlibraries  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
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.opqexpbuffer.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.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: XLogRecGetFullXid()
Next
From: Brad DeJong
Date:
Subject: Re: Comment typo in tableam.h