Dear MSYS list, in the meantime I found out that the problem was caused by the resource file definition which used outdated settings (for a 64bit exe):
``` #ifndef RT_MANIFEST #define RT_MANIFEST 24 #endif #ifndef CREATEPROCESS_MANIFEST_RESOURCE_ID #define CREATEPROCESS_MANIFEST_RESOURCE_ID 1 #endif CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "filename.exe.manifest" ``` such as described here: https://blogs.msdn.microsoft.com/junfeng/2007/06/26/rt_manifest-resource-and-isolation_aware_enabled/ Excluding this from the build results in a working exe again :) best Ingo Am 11.03.19 um 16:36 schrieb msys2-us...@ingobressler.net: > Dear MSYS list, > > I've encountered a problem with native Windows DLLs when building a 64 > bit executable (EXE) on Windows: > > A project is built for 64 bit with MinGW64/MSYS2 on a recent Win10 64 > and the resulting EXE does not start. GDB tells me, it exits with error > 0xc000007b. The tool 'Dependency Walker' tells me that all depending > DLLs of the EXE are 64 bit except one: comctl32.dll for which it depends > on the 32 bit version: > C:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.619_none_42f3d87644dde83c\COMCTL32.DLL > I verified with objdump the intermediate binaries being 64 bit. > > This is very likely to be the cause of the error but I am out of options > how to debug this, why does it depend on a single 32 bit DLL? The 64 bit > version of that DLL exists on the system as well and is used by another > build of a slightly different project which uses the same static archive > requiring this dependency: > C:\windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.619_none_fb46a19f3061bf36\COMCTL32.DLL > > So, in both cases -Wl,--verbose shows that the linker choses > C:/msys64/mingw64/x86_64-w64-mingw32/lib/libcomctl32.a but only in one > case this results in the 32 bit DLL dependency. Does someone has a clue, > how to trace this down? > > This problem is reproducible on another system/hardware (tested on > Appveyor which runs Win Server). The concerning project is publicly > available, if interested, I can give instruction on how to build and > reproduce this error. > > Some detail on the environment: > For MSYS2, the package 'msys2-x86_64-20180531.exe' is installed. Next, > it is updated and the build tools are installed: > pacman -Syuu > ARCH=mingw-w64-x86_64; pacman -S --needed --noconfirm base-devel git > $ARCH-gcc $ARCH-cmake $ARCH-make $ARCH-diffutils $ARCH-patch > > The final problematic linker call is this: > g++ ../dqkit/kitInit.o ../dqkit/pwb.o ../dqkit/rechan.o ../dqkit/zlib.o > ../dqkit/winMain.o ../dqkit/_isnan.o ../res/res.o ../zlib/libz.a > ../vfs/vfs13.a ../blt/src/libBLT24.a ../itcl/itcl3.3.a ../tk/libtk84s.a > ../mk/mk4tcl.a ../tcl/tclreg12s.a ../tcl/tcldde13s.a ../tcl/libtcl84s.a > -lgdi32 -o ../dqkit/dqkit.exe -mwindows -pipe -lcomctl32 -limm32 > -lshell32 -lwinspool > > Thanks for reading! > > best > Ingo > _______________________________________________ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users
