Package Details: lib32-qt4 4.8.7-15

Git Clone URL: https://aur.archlinux.org/lib32-qt4.git (read-only, click to copy)
Package Base: lib32-qt4
Description: A cross-platform application and UI framework (32-bit)
Upstream URL: http://www.qt.io
Licenses: custom, GPL3, LGPL, FDL
Conflicts: lib32-qt
Replaces: lib32-qt
Submitter: arojas
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 51
Popularity: 0.000000
First Submitted: 2017-02-09 20:36 (UTC)
Last Updated: 2019-11-19 22:10 (UTC)

Pinned Comments

WoefulDerelict commented on 2017-03-07 19:07 (UTC) (edited on 2018-08-26 01:22 (UTC) by WoefulDerelict)

This package often requires special care to build. If building this with makepkg fails it will be necessary to construct the package in a clean chroot. Using an AUR helper is not recommended; however, aurutils does provide the option to build in the clean chroot.

The process of building this package in a clean chroot is rendered exceptionally simple with the help of scripts in the devtools package and can be completed via the following steps. These summarize the information provided by the Arch Linux DeveloperWiki and assume familiarity with git or the process of downloading a snapshot from the AUR and extracting the archive. Please refer to this article for more information about the devtools scripts and building in the clean chroot: [https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot]

Prerequisites: This process uses scripts in devtools to simplify the procedure: please install this package before beginning. The lib32-libmng package is required and must be built or downloaded from the Arch Linux Archive [https://wiki.archlinux.org/index.php/Arch_Linux_Archive]. QT 4 depends on this package and it is no longer found in the binary repositories.

  1. Clone the lib32-qt4 repository or extract the snapshot archive into a clean working directory.

  2. Enter the directory containing the package source. (PKGBUILD and patches.)

  3. Execute the following command, supplying the location of lib32-libmng: multilib-build -- -I /<somewhere>/lib32-libmng-2.0.3-1-x86_64.pkg.tar.xz

  4. Execute pacman with the -U flag to install the resulting package: just as one would with any other local package. Note: lib32-libmng would need to be installed in a similar fashion if it isn't already present on your system.

WoefulDerelict commented on 2017-02-25 15:52 (UTC) (edited on 2018-08-26 00:47 (UTC) by WoefulDerelict)

The QT 4 build system is prone to some odd behaviour: especially if the qtwebkit package is installed. [https://bbs.archlinux.org/viewtopic.php?id=132416] [https://bugreports.qt.io/browse/QTBUG-20236]

If your build fails with the following [error: expected class-name before ‘{’ token] when compiling please build in a clean chroot.

If your build fails with error messages about skipping incompatible files and being unable to find a specific file in a compatible format, especially while linking, you will need to build in a clean container to avoid issues.

Building this package in a clean chroot or other form of container will prevent unexpected issues.

All build errors will be ignored unless the build was performed inside a clean, properly configured container. For more information about building in a clean chroot see this article: [https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot]

Big thanks to int [at] arcor [dot] de for doing the legwork to track down the relevant issue reports and sending them my way.

The archlinuxgr repository contains a binary copy of this package courtesy of ranger.

[archlinuxgr] Server = http://archlinuxgr.tiven.org/archlinux/$arch

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 25 Next › Last »

mnyolt commented on 2017-03-08 15:57 (UTC)

Note: This package does not compile with link-time optimizations enabled in your makepkg.conf. Either make sure you remove -flto from CXXFLAGS, or change the PKGBUILD line (inside prepare()) from sed -i "s|-O2|${CXXFLAGS} -m32|" mkspecs/common/{g++,gcc}-base.conf to sed -i "s|-O2|${CXXFLAGS} -m32 -fno-lto|" mkspecs/common/{g++,gcc}-base.conf (Maybe this can be included in the PKGBUILD by the maintainer?)

slav commented on 2017-03-08 10:53 (UTC)

Thank you for link to compiled files. Real appreciated.

TheSaint commented on 2017-03-08 09:25 (UTC)

I can't compile it. Third trial after one week. compiling .moc/release-shared/moc_bookmarkmanager.cpp helpviewer_qwv.cpp:161:1: error: expected class-name before ‘{’ token { ^ helpviewer_qwv.cpp:166:13: error: ‘QWebPage’ does not name a type virtual QWebPage *createWindow(QWebPage::WebWindowType); ^~~~~~~~ helpviewer_qwv.cpp:167:32: error: ‘WebAction’ has not been declared virtual void triggerAction(WebAction action, bool checked = false); ^~~~~~~~~ helpviewer_qwv.cpp:169:42: error: ‘QWebFrame’ has not been declared virtual bool acceptNavigationRequest(QWebFrame *frame, ^~~~~~~~~ helpviewer_qwv.cpp:170:41: error: ‘NavigationType’ has not been declared const QNetworkRequest &request, NavigationType type); ^~~~~~~~~~~~~~ helpviewer_qwv.cpp: In constructor ‘HelpPage::HelpPage(QObject*)’: helpviewer_qwv.cpp:182:7: error: class ‘HelpPage’ does not have any field named ‘QWebPage’ : QWebPage(parent) ^~~~~~~~ helpviewer_qwv.cpp: At global scope: helpviewer_qwv.cpp:190:1: error: ‘QWebPage’ does not name a type QWebPage *HelpPage::createWindow(QWebPage::WebWindowType) ^~~~~~~~ helpviewer_qwv.cpp:200:30: error: variable or field ‘triggerAction’ declared void void HelpPage::triggerAction(WebAction action, bool checked) ^~~~~~~~~ helpviewer_qwv.cpp:200:30: error: ‘WebAction’ was not declared in this scope helpviewer_qwv.cpp:200:48: error: expected primary-expression before ‘bool’ void HelpPage::triggerAction(WebAction action, bool checked) ^~~~ compiling .moc/release-shared/moc_bookmarkmanagerwidget.cpp make[4]: *** [Makefile:14146: .obj/release-shared/helpviewer_qwv.o] Error 1 make[4]: *** Attesa per i processi non terminati.... make[4]: uscita dalla directory "/tmp/yaourt-tmp-user/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/tools/assistant/tools/assistant" make[3]: *** [Makefile:42: sub-assistant-make_default-ordered] Error 2 make[3]: uscita dalla directory "/tmp/yaourt-tmp-user/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/tools/assistant/tools" make[2]: *** [Makefile:113: sub-tools-make_default-ordered] Error 2 make[2]: uscita dalla directory "/tmp/yaourt-tmp-user/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/tools/assistant" make[1]: *** [Makefile:52: sub-assistant-make_default-ordered] Error 2 make[1]: uscita dalla directory "/tmp/yaourt-tmp-user/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/tools" make: *** [Makefile:891: sub-tools-make_default-ordered] Error 2

WoefulDerelict commented on 2017-03-07 22:48 (UTC) (edited on 2017-03-07 22:51 (UTC) by WoefulDerelict)

mozo: ranger has been very up front about the source of the binary package and is present and available for comment so it shouldn't be a huge leap. As ranger has expressed an intent to keep it maintained and up to date for Skype it will probably mirror any relevant changes I make here. It didn't take long for ranger to rebuild it once the theme issue was sorted. I added the repo in the pinned comments as it seemed a reasonable option to provide given this does take a tick to build as is more finicky about the environment it is built in. One has to leave it to the user as to which option suits them; however, both are perfectly reasonable and the binary saves a ton of time for people on older or resource strapped machines.

mozo commented on 2017-03-07 22:41 (UTC)

WoefulDerelict: Thank you once again. For now I will trust ranger because the binary package install itself for seconds :)

ranger commented on 2017-03-07 22:23 (UTC) (edited on 2017-03-07 22:25 (UTC) by ranger)

@WoefulDerelict, I agree with your last post, but just to make it clear, my package has been build using exactly your files (downloaded with cower) and in an chroot. I only did a makepkg -src :) I will keep the package in the repo as it is required by skype (latest stable version)

WoefulDerelict commented on 2017-03-07 20:40 (UTC) (edited on 2017-03-07 20:48 (UTC) by WoefulDerelict)

mozo: One uses the build script that would match the target repository for a binary package. Any lib32- package would go into [Multilib] so multilib-build is the script to use in this case as you want what would amount to a binary release for [Multilib]. [Extra] or [Community] would be the target for a normal package and in those cases you would use extra-<arch>-build where <arch> was the desired system architecture (i686/x86_64). As these scripts are used by the developers behind the binary repositories there are additional tools to build for the staging and testing repositories you can likely ignore in most cases. The proper script is suggested in my instructions along with an example of the argument that must be passed for the build to succeed as lib32-qt4 needs a binary package of lib32-libmng to build against. <somewhere> is meant to be replaced with the actual location of this file so that it can be included in the chroot for lib32-qt4 to build against. The primary /drawbacks/ to using a binary package from an unofficial repository are highlighted in the red box atop the wiki page discussing them. [https://wiki.archlinux.org/index.php/unofficial_user_repositories] Like PKGBUILDs here in the AUR these packages have not been tested by anyone in the Arch Linux web of trust and are unsupported. While it is possible for a PKGBUILD in the AUR to inject malicious patches and attempt to wreak other havoc on your system the sources for everything are open for you to review before executing makepkg. Binary packages allow no such review and could contain any number of malicious changes or accidental errors caused by a dirty build environment which could cause it to behave unexpectedly and crash. Essentially the difference is how large a leap of trust you need to make for the convenience. If you write the PKGBUILD, choose what patches if any to include and build it yourself it is of course very inconvenient but should be relatively trustworthy. If you use a PKGBUILD and patch set chosen by another user it is possible that user may try to slip in something unwanted; however, the majority of sources and patches are plain text and can be scrutinized before they are build. A PKGBUILD in the AUR that packages binary blobs definitely warrants extra scrutiny and caution. This is more convenient than generating the resources to package something yourself but the maintainer is essentially asking you to trust that they knew what they were doing and put everything where it ought to be and the patches they included are appropriate fixes for serious issues. Binary packages offer very little transparency making it much easier to attempt to sneak in a malicious payload. It is impossible to know if a binary package in an unofficial repository was built in a clean chroot or some dirty build server and will behave unexpectedly on your system. Not having to download the sources and build a package is terribly convenient; however, you're essentially trusting a stranger with the security of your system and as the wiki suggests this should be done on a case by case basis. As this is a large toolkit and building it in a clean chroot will temporarily chew up quite a bit of space and time an unofficial binary package is an exceptionally convenient option with the potential to do some serious damage. Just remember both the AUR and the unofficial repositories are user generated content and provided on an as is, use at your own risk basis.

mozo commented on 2017-03-07 20:00 (UTC)

Thank you. Which script we mast call? Multilib or Extra or just follow your steps? And what are drowbacks from using the binary packag? Thank you once again.

WoefulDerelict commented on 2017-03-07 19:17 (UTC)

mozo: The wiki provides a table of the relevant scripts in devtools and what they are to be used for along with a plethora of examples on how to use them. In most cases the process is ridiculously simple and can be completed with a single unargumented call to the appropriate script. As QT 4 requires a package not found in the core/binary repositories it must be passed in; however, there is a clear example of how this is done on the wiki. In an effort to further reduce confusion one has added a pinned post summarizing the process for building this package in a clean chroot based on the article in the developer wiki. Arch Linux expects its users to be of the necessary skill level to solve these problems on their own with the help of the documentation and the community. Ubuntu is for hand holding.

WoefulDerelict commented on 2017-03-07 19:07 (UTC) (edited on 2018-08-26 01:22 (UTC) by WoefulDerelict)

This package often requires special care to build. If building this with makepkg fails it will be necessary to construct the package in a clean chroot. Using an AUR helper is not recommended; however, aurutils does provide the option to build in the clean chroot.

The process of building this package in a clean chroot is rendered exceptionally simple with the help of scripts in the devtools package and can be completed via the following steps. These summarize the information provided by the Arch Linux DeveloperWiki and assume familiarity with git or the process of downloading a snapshot from the AUR and extracting the archive. Please refer to this article for more information about the devtools scripts and building in the clean chroot: [https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot]

Prerequisites: This process uses scripts in devtools to simplify the procedure: please install this package before beginning. The lib32-libmng package is required and must be built or downloaded from the Arch Linux Archive [https://wiki.archlinux.org/index.php/Arch_Linux_Archive]. QT 4 depends on this package and it is no longer found in the binary repositories.

  1. Clone the lib32-qt4 repository or extract the snapshot archive into a clean working directory.

  2. Enter the directory containing the package source. (PKGBUILD and patches.)

  3. Execute the following command, supplying the location of lib32-libmng: multilib-build -- -I /<somewhere>/lib32-libmng-2.0.3-1-x86_64.pkg.tar.xz

  4. Execute pacman with the -U flag to install the resulting package: just as one would with any other local package. Note: lib32-libmng would need to be installed in a similar fashion if it isn't already present on your system.

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 25 Next › Last »