I'm just starting to look into the mingw packages and building mingw executables with them - and in particular static building. I'm hoping someone can clarify some things for me.

For "regular" libs we seem to have:

%{mingw32_bindir}/libexample-0.dll
%{mingw32_libdir}/libexample.dll.a

and for static libs:

%{mingw32_libdir}/libexample.a

so for example:

-rw-r--r--. 1 root root 7539008 Apr 11 18:00 /usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll -rw-r--r--. 1 root root 13373318 Apr 11 18:00 /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a -rw-r--r--. 1 root root 6699310 Apr 11 18:00 /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a

/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows, 12 sections
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a: current ar archive
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a:     current ar archive

From what I've gleaned from some web searches is that the .dll.a file is an "import" library which seems to encode a dependency on the .dll library at runtime, while the plain .a file is a more "normal" static library.

So to link a static executable it looks like I want to be using libQt5Gui.a. However, when attempting to build the x2goclient executable I'm ending up with the following link line:

i686-w64-mingw32-g++ -g -fstack-protector -static -static-libstdc++ -static-libgcc -Wl,-subsystem,windows -mthreads -o release/x2goclient.exe @object_script.x2goclient.Release -lssh.dll -lwinspool /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Svg.dll.a /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Widgets.dll.a /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a -lgdi32 -lcomdlg32 -loleaut32 -limm32 -luxtheme -ljpeg -lpng -lharfbuzz /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Network.dll.a -lcrypt32 -ldnsapi -liphlpapi /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Core.dll.a -lz -lpcre2-16 -lversion -lole32 -luuid -lwinmm -lws2_32 -ladvapi32 -lshell32 -luser32 -lkernel32 -lnetapi32 -luserenv -liconv release/x2goclient_res.o -lmingw32 /usr/i686-w64-mingw32/sys-root/mingw/lib/libqt5main.a -lshell32

with lots of references to the .dll.a files. And from what I can tell, the x2goclient.exe executable does appear to have runtime dependencies on the various Qt dlls (e.g. Qt5Gui.dll, etc.).

I’m specifying a static config to qmake and QT is specified in the x2goclient.pro simply with:

QT += svg network

So I really have no idea where the .dll.a references are coming from. Some possibilities:

/usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl:
QMAKE_PRL_TARGET = libQt5Widgets.dll.a

$ rpm -qf /usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl
mingw32-qt5-qtbase-static-5.15.9-1.fc39.noarch

so that file is coming in as part of the -static package, but referring to the dll import file not the static file. But I'm not finding similar files for the other libraries.

I'm starting to think that the issue is that both the static and shared builds of the libraries produce .prl files - but generally the static build is installed first and then the shared build, so the .prl files that are in the Fedora packages are for the shared libraries since they have the same path.

So - is there a way for the static .prl files to be installed in a different location for for qmake find them there?



--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nwra.com
Boulder, CO 80301                 https://www.nwra.com/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to