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

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.