Package Details: mingw-w64-qt5-tools 5.15.16+kde+r3-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-qt5-tools.git (read-only, click to copy)
Package Base: mingw-w64-qt5-tools
Description: A cross-platform application and UI framework (Development Tools, QtHelp; 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: 5
Popularity: 0.000000
First Submitted: 2013-08-28 23:58 (UTC)
Last Updated: 2024-11-25 20:55 (UTC)

Pinned Comments

Martchus commented on 2016-07-10 19:40 (UTC)

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

Latest Comments

1 2 Next › Last »

Martchus commented on 2020-04-03 09:48 (UTC)

During the build of Qt 5.14.1 I've just spotted the following in the log:

Qt Tools:
  QDoc ................................... no

WARNING: QDoc will not be compiled, probably because libclang could not be located. This means that you cannot build the Qt documentation.
Either ensure that llvm-config is in your PATH environment variable, or set LLVM_INSTALL_DIR to the location of your llvm installation.
On Linux systems, you may be able to install libclang by installing the libclang-dev or libclang-devel package, depending on your distribution.
On macOS, you can use Homebrew's llvm package.
On Windows, you must set LLVM_INSTALL_DIR to the installation path.

I assume nobody needs that, right? Otherwise one might add mingw64-llvm as dependency but I don't think it is worth it (these packages need long enough to build anyways and are error prone enough).

Martchus commented on 2018-11-30 13:13 (UTC)

@luntik2012 I could build this fine. Be sure to build in a clean environment. At least ensure the previous version of the package is not installed anymore.

Also use the correct markdown formatting, no one wants the error messages otherwise.

luntik2012 commented on 2018-11-30 12:25 (UTC)

many multiple definitions errors

/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /mnt/garbage/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-tools/src/qttools-everywhere-src-5.11.2/build-i686-w64-mingw32-static/lib/libQt5Designer.a(formbuilderextra.o): in function Z12uiLibWarningRK7QString': /mnt/garbage/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-tools/src/qttools-everywhere-src-5.11.2/src/designer/src/lib/uilib/formbuilderextra.cpp:76: multiple definition ofuiLibWarning(QString const&)'; /usr/i686-w64-mingw32/lib/libQt5Designer.a(formbuilderextra.o):(.text+0xf40): first defined here /usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /mnt/garbage/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-tools/src/qttools-everywhere-src-5.11.2/build-i686-w64-mingw32-static/lib/libQt5Designer.a(formbuilderextra.o):/usr/i686-w64-mingw32/include/qt/QtCore/qstring.h:1129: multiple definition of QFormBuilderExtra::CustomWidgetData::CustomWidgetData()'; /usr/i686-w64-mingw32/lib/libQt5Designer.a(formbuilderextra.o):(.text+0xff0): first defined here /usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /mnt/garbage/tmp/yaourt-tmp-nick/aur-mingw-w64-qt5-tools/src/qttools-everywhere-src-5.11.2/build-i686-w64-mingw32-static/lib/libQt5Designer.a(formbuilderextra.o):/usr/i686-w64-mingw32/include/qt/QtCore/qstring.h:1129: multiple definition ofQFormBuilderExtra::CustomWidgetData::CustomWidgetData()'; /usr/i686-w64-mingw32/lib/libQt5Designer.a(formbuilderextra.o):(.text+0xff0): first defined here

Martchus commented on 2017-02-12 15:03 (UTC)

According to thiago on #qt-labs IRC channel qcollectiongenerator is supposed to run on target so my suspicion is not correct: [15:46] <thiago> [03:41:01] martchus: qcollectiongenerator is expected to be run in the target platform. Not on host However, then the provided CMake file doesn't make any sense at all. At least I don't see any use case for it. I mean when cross-compiling we only configure and build under Arch Linux and hence your mingw-w64-cmake package is just a wrapper for Linux version and does not contain any binaries to run on the target. But what's your use-case for this, I mean, how do you want to use it?

Martchus commented on 2017-02-11 21:22 (UTC)

xantares: This problem seems to exist since at least version 5.5.0 of this package, just nobody noticed it. I am not sure what this qcollectiongenerator is supposed to do, but I suspect this tool is required at build time. This would mean the path is actually correct, but the tool needs to be provided as native GNU/Linux binary. You obviously know more about qcollectiongenerator than me since you're trying to use it, so would this make sense? And where is it actually used?

xantares commented on 2017-02-11 16:05 (UTC) (edited on 2017-02-11 16:05 (UTC) by xantares)

Hi, There'a problem when using the qt5help cmake config file: for example in /usr/i686-w64-mingw32/lib/cmake/Qt5Help/Qt5HelpConfigExtras.cmake there is: set(imported_location "${_qt5Help_install_prefix}/lib/qt/bin/qcollectiongenerator") but no /usr/i686-w64-mingw32/lib/qt/bin/qcollectiongenerator is installed I changed it to: set(imported_location "${_qt5Help_install_prefix}/bin/qcollectiongenerator-qt5.exe") Same for qhelpgenerator what do you think ?

Martchus commented on 2017-01-04 22:42 (UTC) (edited on 2017-01-04 22:42 (UTC) by Martchus)

@Schala Here's a version of mingw-w64-qt5-tools providing a regular CMake file for QtUiTools target: https://github.com/Martchus/PKGBUILDs/commit/0b2216ecb8b20c7c813c78a0f5b3c1c74f03d316 This solution isn't nice and I haven't tested it. Which package/project uses this target? Would be useful for me to know so I can reproduce the issue. BTW: I'm quite curious what you're actually doing with all those mingw-w64 KF5 packages. If you have PKGBUILDs for building actual KDE apps like Kate, Konversations or Okular (KF5 version works quite well for me natively under Arch) I would be very interested :-)

Schala commented on 2016-12-31 22:33 (UTC)

hmm... weird

Martchus commented on 2016-12-31 14:16 (UTC) (edited on 2017-01-04 21:58 (UTC) by Martchus)

@Schala I customized the build system to allow use of static version with CMake. To achieve this, I prefixed all CMake files and targets for static variant with 'Static'. This way you can even use the dynamic and the static variant in one project at the same time. The problem is now that UI tools is only available as static library and in consequence only the 'Static' prefixed version is available. I haven't thought about this and I'm currently not sure how to deal with this special case. Since use of static version with CMake is one of my use-cases I would only reluctantly drop the concerning patch in mingw-w64-qt5-base (0022-Allow-usage-of-static-version-with-CMake.patch). But maybe I can figure a way to handle this special case. Not sure why Qt5UiTools is only available as static lib anyways.

Schala commented on 2016-12-31 00:30 (UTC)

Qt5UiTools module seems to be absent. I verified it and there are no CMake files for it

1 2 Next › Last »