I am using MinGW-w64 with POSIX streams. I want to create a GNU gettext with POSIX streams and as shared libraries (in this case a DLL). However, when you create runtime artifacts (such as DLLs or executables) that depend on POSIX streams with MinGW / MinGW-w64, each ends up with these artifacts dependent on libwinpthread-1.dll . In my case, I want to avoid this and associate any runtime artifacts with POSIX streams statically! The only way to do this on MinGW / MinGW-w64 is to set the -static flag during the binding phase. I have done this hundreds of times before, so I know that it works.
Now the problem is that I have to deal with the infamous Autotools, which once again proved that they are absolutely inflexible, unfriendly and cumbersome to use. So 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 added -static , and he does the following for my build:
- All GNU gettext libraries that were supposed to be created as DLLs (due to
--enable-shared and --disable-static ) are now created as static libraries / archives; All GNU gettext binaries are built with -static excluded, which makes them depend on libwinpthread-1.dll , for example:
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 that Autotools intentionally filtered out only -static without my permission and any logical reason for this.
I tried different things and even found:
link_static_flag="-static"
in the libtool file. I tried changing it to:
link_static_flag=""
in the hope that this will prevent libtool from reacting this way when the -static flag is present. Unfortunately, there is no success so far. This is incredibly frustrating.
Well, Autotools guru, now it's finally your time to shine.
source share