Autoconf and Libtool Are Insanely Stubborn about Static Linkage

Question

I'm using MinGW-w64 with POSIX threads. I want to build GNU gettext with POSIX threads and as shared libraries (DLLs in this case). However, when one builds runtime artifacts (such as DLLs or executables) which depend on POSIX threads with MinGW/MinGW-w64, one ends up with these artifacts being dependent on libwinpthread-1.dll. In my case, I want to avoid that and link any runtime artifacts against POSIX threads statically! The only way one can do that on MinGW/MinGW-w64 is to supply -static flag during the linkage stage. I've done that hundreds of times before, so I know that it works.

The problem now is that I have to deal with notorious Autotools which have just proven yet again that they are absolutely inflexible, unfriendly, and cumbersome to use. So there we go:

LDFLAGS="-static-libgcc -static-libstdc++ -static" ../configure --build=x86_64-w64-mingw32 --disable-static --enable-shared --disable-java --disable-native-java --enable-relocatable --enable-threads=posix --prefix=<prefix>

Guess what? This guy somehow parses that I've added -static and it does the following to my build:

1. All the GNU gettext libraries that should have been built as DLLs (due to --enable-shared and --disable-static) are now built as static libraries/archives;

2. All the GNU gettext executables are built with -static excluded what makes them dependent on libwinpthread-1.dll, for instance:

   gcc -pipe -Wall -Wextra -O3 -static-libgcc -static-libstdc++ -o test-lock.exe test-lock.o lock.o threadlib.o -lpthread
   

   as we can see Autotools have intentionally filtered out only the -static without my permission and any logical reason to do so.

I tried various things, and even found:

link_static_flag="-static"

in the libtool file. I've tried to change it to:

link_static_flag=""

in hope that it will prevent libtool from reacting like that when the -static flag is present. Unfortunately, no success yet. This is incredibly frustrating.

OK, Autotools gurus, now it's finally your time to shine.

Unders

Why would you expect Autotools gurus to shine for you after they've just spent 10 minutes reading a rant wherein you insult their favorite tool? ;-) – Ferbam

Some searhing around the web suggests to try passing the full path to libpthread.a to inhibit ld from finding the libwinpthread DLL. Also, the libtool manual suggests using the -all-static option. – Croquet

I've also seen the behavior under Apple's Xcode, even when building for iOS (iOS requires all static libs for non-Apple applications). The two work arounds I used were: (1) supplying the full path to static archive; and (2) delete the shared object from the lib/ directory so Xcode could not use it. I could do (2) because I built the library (it was not a system library). – Vd

" inflexible, unfriendly, and cumbersome..." - I don't know about inflexible, but unfriendly and cumbersome is not off the mark. – Vd

This link, cygwin.com/ml/cygwin/2009-02/msg00231.html , suggests Try Ralf's suggested workaround, configuring your entire package with CC='gcc -static-libcc' and/or CXX='g++ -static-libgcc'. If that works, then I'll ping Ralf on fixing this bug.. Apparently Ralf hasn't fixed the bug, it's 2014 and I had to use this workaround to make things work... – Clive