Broken static Windows cross build with `--default-library=both` meson option
Building Environment
- Build OS: Fedora 34
- Test OS: Windows Server 2022
- Shell: bash
- GCC: x86_64-w64-mingw32-gcc (GCC) 10.3.1 20210422 (Fedora MinGW 10.3.1-2.fc34) (cross compilation)
- Python v3.9.9
- meson v0.59.4
- ninja v1.10.2
- git v2.31.1
- glib release v2.70.1
How to reproduce
-
Cross compile Glib2 using the following command line:
mingw-w64-x86_64-meson --default-library=both
-
Compile test.c using the following GCC command:
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DGLIB_STATIC_COMPILATION -mms-bitfields -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/glib-2.0 -I/usr/x86_64-w64-mingw32/sys-root/mingw/lib/glib-2.0/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -o test.exe test.c -static -fstack-protector-strong -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lgthread-2.0 -lglib-2.0 -lintl -lws2_32 -lole32 -lwinmm -lshlwapi -lm -lpcre
-
Copy the resulting binary and
gspawn-win64-helper-console.exe
in the same folder. For example:C:\Users\Administrator\Desktop\test
. -
Run the resulting binary on the test OS in this folder.
PS C:\Users\Administrator\Desktop\test> .\test.exe
calling gspawn-win64-helper-console.exe with argv:
argv[0]: gspawn-win64-helper-console.exe
argv[1]: 8
argv[2]: 9
argv[3]: z
argv[4]: 4
argv[5]: 6
argv[6]: -
argv[7]: y
argv[8]: y
argv[9]: -
argv[10]: PING.exe
argv[11]: www.redhat.com
argv[12]: NULL
../glib/gspawn-win32.c:read_helper_report: read 16...
...got 8 bytes
../glib/gspawn-win32.c:read_helper_report: read 8...
...got 8 bytes
STARTED: PID: 248
- Run the resulting binary on the test OS in any other folder.
PS C:\Users\Administrator\Desktop> .\test\test.exe
calling gspawn-win64-helper-console.exe with argv:
argv[0]: gspawn-win64-helper-console.exe
argv[1]: 8
argv[2]: 9
argv[3]: z
argv[4]: 4
argv[5]: 6
argv[6]: -
argv[7]: y
argv[8]: y
argv[9]: -
argv[10]: PING.exe
argv[11]: www.redhat.com
argv[12]: NULL
ERROR: Failed to execute helper program (No such file or directory)
Expected outcome
The helper program should be found regardless of the current working directory. According to fork_exec source and _glib_get_dll_directory source helper program path for statically built executable should be based on its location.
Actual outcome
As we see from the output, _glib_get_dll_directory
returns NULL (argv[0] does not include the full path, only the helper name). So, the g_spawn works only if the helper program is in the PATH/current working directory.
The problem occurs because DLL_EXPORT is defined for the static build when the --default-library=both
meson option is used (see meson.build). This causes unnecessary check in the _glib_get_dll_directory that cannot be true for the static build.