Package Details: mingw-w64-qt5-base-static 5.15.15+kde+r127-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-qt5-base-static.git (read-only, click to copy)
Package Base: mingw-w64-qt5-base-static
Description: A cross-platform application and UI framework, native OpenGL backend (mingw-w64)
Upstream URL: https://www.qt.io/
Licenses: custom, GPL3, LGPL3, FDL
Groups: mingw-w64-qt5
Submitter: ant32
Maintainer: Martchus
Last Packager: Martchus
Votes: 12
Popularity: 0.000566
First Submitted: 2013-08-28 23:57 (UTC)
Last Updated: 2024-09-10 21:19 (UTC)

Sources (33)

Pinned Comments

Martchus commented on 2020-09-13 11:43 (UTC)

Also take note of the sticky comments on the mingw-w64-qt5-base package.

Martchus commented on 2017-01-10 21:24 (UTC) (edited on 2019-12-10 13:02 (UTC) by Martchus)

Notes about using static Qt with CMake:

Note about using static Qt with qmake:

  • Add CONFIG+=no_smart_library_merge to qmake arguments to prevent qmake from messing linker flags for freetype2/harfbuzz (which have dependency cycle).

Martchus commented on 2016-07-10 19:47 (UTC) (edited on 2016-09-19 18:26 (UTC) by Martchus)

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs Patches for this package are managed at: https://github.com/Martchus/qtbase/tree/5.7.0-mingw-w64 There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff For general discussion and issues not only concerning this variant please use the comment section of the package mingw-w64-qt5-base.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

ant32 commented on 2017-02-28 00:31 (UTC)

You can compile libpq staticaly by adding the following two lines to the mingw-w64-postgresql PKGBUILD ${_arch}-ar rvs -o libpq.a src/interfaces/libpq/*.o mv libpq.a "${pkgdir}/usr/${_arch}/lib/"

Martchus commented on 2017-02-22 15:26 (UTC)

PostgeSQL is currently not available as static lib. Hence, the current attempt is to link against the dynamic version also on static build, but apparently this does not work. Maybe I should just disable this plugin in the static variant. In the case of MariaDB, I assume the correct static library would be mariadbclient. Not sure why the dynamic library is attempted to be used instead. You can play around with the linker flags by modifying /usr/$_arch/lib/qt/plugins/sqldrivers/qsqlpsql.static.prl and qsqlmysql.static.prl. In the last line of those files the linker flags for CMake are defined. What are the final flags passed by CMake to the linker? I suppose the flags in the mentioned files are messed up so linking against libs explicitly as dynamic libs doesn't work. Note that sometimes CMake creates an extra file for the flags, eg. CMakeFiles/yourapp.dir/linklibs.rsp. To prevent CMake from finding the static plugins at all, you can just remove the corresponding module.

woggioni commented on 2017-02-22 13:13 (UTC) (edited on 2017-02-22 13:15 (UTC) by woggioni)

compiling the example https://github.com/oggio88/Qt-CMake-HelloWorld with STATIC_QT=ON I noticed that QtSql module now links to non existing libs -lmariadb and -lpq, here is what I got from the linker: /usr/lib/gcc/x86_64-w64-mingw32/6.3.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmariadb /usr/lib/gcc/x86_64-w64-mingw32/6.3.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lpq /usr/lib/gcc/x86_64-w64-mingw32/6.3.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lmariadb /usr/lib/gcc/x86_64-w64-mingw32/6.3.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lpq

woggioni commented on 2017-01-12 09:18 (UTC)

@Martchus Great job! Thank you

Martchus commented on 2017-01-11 19:41 (UTC) (edited on 2017-01-11 21:55 (UTC) by Martchus)

@woggioni I tested again. My applications have no further dependencies. However, Dependency Walker shows that the hello world app links against all Qt dependencies and the standard library dynamically. I used regular wine command to test yesterday but I might have set WINEPATH some time ago so I didn't notice. Linking dynamically against the standard library should be ok. Telling the build system to do otherwise is nothing the Qt packages should enforce. I would also say that linking dynamically against Qt dependencies is a valid configuration and hence static linkage for all libraries should not be enforced from the Qt-side or this package. But of course this is certainly not what most people (including me) want. So to achieve static linking against all libraries I did the following in my own build scripts: * Add linker flags for linking statically against *all* libraries: `-static -static-libstdc++ -static-libgcc` * Make CMake aware of the meaning of such flags by enabling the target properties `LINK_SEARCH_START_STATIC` and `LINK_SEARCH_END_STATIC` See https://github.com/Martchus/cpp-utilities/blob/master/cmake/modules/BasicConfig.cmake#L90 and https://github.com/Martchus/cpp-utilities/blob/master/cmake/modules/AppTarget.cmake#L40 I also updated the example now: https://github.com/Martchus/Qt-CMake-HelloWorld/tree/mingw-w64-static

woggioni commented on 2017-01-11 17:23 (UTC) (edited on 2017-01-11 17:24 (UTC) by woggioni)

@Martchus do you use /usr/bin/wine or /usr/bin/${arch}-w64-mingw32-wine? Because the second one works without having to copy the dll since it sets WINEPATH before calling wine, /usr/bin/wine on my machine requires all the dlls in the executable folder instead

Martchus commented on 2017-01-11 16:54 (UTC)

@woggioni No, this is not expected behavior. But I can not reproduce the issue. * tested yesterday the hello world project with wine and there were no complaints about missing libs * my own apps have no further dependencies, too: https://martchus.no-ip.biz/repo/win/static/ Note that only `find_package(Qt5Core)` is required. You should *not* add it to `target_link_libraries`.

woggioni commented on 2017-01-11 16:47 (UTC) (edited on 2017-01-11 16:48 (UTC) by woggioni)

Thanks Martchus, your workaround seems to do the job. I just noticed that even compiling the hello word example with "-static -static-libgcc -static-libstdc++" the generated executable needs a long list of dll, located under /usr/x86_64/bin (namely libbz2-1.dll libgcc_s_seh-1.dll libgraphite2.dll libiconv-2.dll libjpeg-8.dll libpcre-1.dll libstdc++-6.dll zlib1.dll libfreetype-6.dll libglib-2.0-0.dll libharfbuzz-0.dll libintl-8.dll libpcre16-0.dll libpng16-16.dll libwinpthread-1.dll), is this this the expected behaviour? In particular, it is funny that libstdc++ is needed since I asked explicitely the compiler to statically link it. I ask because, to me, the main point of linking Qt statically is to have a single executable file for my program and not having to distribute a long list of dlls alongside the main executable

Martchus commented on 2017-01-10 21:24 (UTC) (edited on 2019-12-10 13:02 (UTC) by Martchus)

Notes about using static Qt with CMake:

Note about using static Qt with qmake:

  • Add CONFIG+=no_smart_library_merge to qmake arguments to prevent qmake from messing linker flags for freetype2/harfbuzz (which have dependency cycle).

woggioni commented on 2017-01-10 10:19 (UTC)

@Martchus I tried to compile your project (https://github.com/Martchus/qtutilities) and it has the same problem as mine if you set QT_LINKAGE=STATIC in CMakeCache.txt

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »