pkg-config for mingw needs to emit -lws2_32
Closed, ResolvedPublic


If i try to build a simple C test harness into a static binary for windows using mingw32 (either x86_64 or i686 flavors, examples shown here come from x86_64), using pkg-config on debian, i get a linker error.

I try to build with:

export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/lib/pkgconfig"
x86_64-w64-mingw32-gcc -pedantic -Wall -Werror -static -o test-run.exe simple-build.c $(pkg-config --static --cflags --libs gpg-error)

and pkg-config produces:

-I/usr/i686-w64-mingw32/include -L/usr/i686-w64-mingw32/lib -lgpg-error

the resulting compilation fails with:

/usr/bin/x86_64-w64-mingw32-ld: /usr/x86_64-w64-mingw32/lib/libgpg-error.a(libgpg_error_la-logging.o): in function `fun_closer':
./build-x86_64-w64-mingw32/src/../../src/logging.c:455: undefined reference to `__imp_closesocket'
/usr/bin/x86_64-w64-mingw32-ld: /usr/x86_64-w64-mingw32/lib/libgpg-error.a(libgpg_error_la-logging.o): in function `fun_writer':
./build-x86_64-w64-mingw32/src/../../src/logging.c:339: undefined reference to `__imp_htons'
/usr/bin/x86_64-w64-mingw32-ld: ./build-x86_64-w64-mingw32/src/../../src/logging.c:358: undefined reference to `__imp_inet_addr'
/usr/bin/x86_64-w64-mingw32-ld: ./build-x86_64-w64-mingw32/src/../../src/logging.c:367: undefined reference to `__imp_socket'
/usr/bin/x86_64-w64-mingw32-ld: ./build-x86_64-w64-mingw32/src/../../src/logging.c:378: undefined reference to `__imp_connect'
/usr/bin/x86_64-w64-mingw32-ld: ./build-x86_64-w64-mingw32/src/../../src/logging.c:384: undefined reference to `__imp_closesocket'
/usr/bin/x86_64-w64-mingw32-ld: /usr/x86_64-w64-mingw32/lib/libgpg-error.a(libgpg_error_la-logging.o): in function `writen':
./build-x86_64-w64-mingw32/src/../../src/logging.c:167: undefined reference to `__imp_send'
/usr/bin/x86_64-w64-mingw32-ld: /usr/x86_64-w64-mingw32/lib/libgpg-error.a(libgpg_error_la-logging.o): in function `fun_writer':
./build-x86_64-w64-mingw32/src/../../src/logging.c:440: undefined reference to `__imp_closesocket'
collect2: error: ld returned 1 exit status

I note that the version of libassuan.pc i have installed via the debian libassuan-mingw-w64-dev package identifies that -lws2_32 is a pre-requisite of libassuan, i think derived somehow from NETLIBS in Perhaps a similar test needs to be built into gpg-error.pc ?

(as a side note, i observe that gpg-error-config.exe (the wine executable) seems to have the same problem of failing to identify -lws2_32 when asked for linker flags)

dkg created this task.Jul 15 2019, 5:47 AM
dkg updated the task description. (Show Details)Jul 15 2019, 6:01 AM
werner triaged this task as Low priority.Jul 15 2019, 8:10 AM
gniibe claimed this task.Jul 15 2019, 9:00 AM

Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.

It can be supported by *.pc, that's true.

gniibe changed the task status from Open to Testing.Feb 18 2020, 8:05 AM

Fixed in master, using Libs.private support.

werner closed this task as Resolved.
aheinecke reopened this task as Open.Jul 29 2020, 1:08 PM
aheinecke added a subscriber: aheinecke.

This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.

But for GnuPG we now also have this problem. When compiled with a libgpg-error that has this change:

/usr/bin/i686-w64-mingw32-ld: ../common/libcommon.a(libcommon_a-init.o): in function `init_common_subsystems':
/home/aheinecke/dev/main/src/gnupg/common/init.c:171: undefined reference to `_imp__WSAStartup@8'

As libcommon is ues everywhere we will get that problem everytime we link it, currently it is reduced because it's pulled in through LIBASSUAN_LIBS as we have not yet released libassuan with this change.

I'm not sure how to fix it. Seems wrong to me to add something like common_w32_extralibs=ws2_32. Ideally I would think that this would be added to: $(libcommon) but I don't know how to change that variable in automake.

aheinecke closed this task as Resolved.Jul 29 2020, 1:17 PM

I just saw that there is related discussion and a patch for this in T4994 so I will close again here.