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 .. 18 19 20 21 22 23 24 25 Next › Last »

WoefulDerelict commented on 2017-02-19 17:16 (UTC) (edited on 2017-02-20 15:28 (UTC) by WoefulDerelict)

Unfortunately there is little one can do at present as sufficient data has not been provided to diagnose this issue. I'm going to take a stab in the dark and guess that you are all bumping into some kind of race condition silliness by the look of the output snippits you've submitted and suggest that you edit the PKGBUILD and append -j 1 to the make command in build(). billypilgrim: This is a large UI toolkit and not only takes a while to build but generates a significant amount of output. There are other paste sites that are less limiting in how much you can post. Thanks for posting the error in better context: it gave me some idea what might have gone on. As you appear to have been the only user actively tracking this and reporting the issues you experienced with each release I'd very much appreciate if you could edit the PKGBUILD as suggested above and run makepkg against it. As always a clean build is best so -C if $srcdir exists already. No need to redownload the sources. dkaylor: makepkg -c != makepkg -C While the former cleans up after the the package has been made the later cleans up existing $srcdir. Blindly iterating the package release serves little purpose. In the end it boils down to an indicator to the community that there have been significant changes to the package and it needs to be updated. Transfer of upkeep is never a good excuse to iterate the pkgrel as that data isn't even included in the final package. While the rebase was significant one is adopting this in the middle of an attempt to address multiple issues. The last release made by lisu_ml removed the bash expansions used in the various dependency arrays to resolve parsing issues with some AUR helpers along with minor changes to the options passed to the configure script in an attempt to address FS#47301. Multiple users had expressed issues with this release. The end result of my rebase was simply removing some superfluous statements including the environment variables forcing compilation with clang to bring this in line with the PKGBUILD from [Extra] as I suspect using clang was just a dirty hack post GCC 6. As one did not suspect this would solve all the build issues expressed it did not seem appropriate to iterate the package release and sound an all clear to update until I could confirm the issues resolved and wouldn't be making more significant changes as this toolkit takes some time to build.

cirrus commented on 2017-02-19 13:06 (UTC) (edited on 2017-02-19 15:06 (UTC) by cirrus)

using cower & makepkg i get make[1]: *** No rule to make target 'util/qabstractsystemtrayiconsys.cpp', make: *** [Makefile:422: sub-gui-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting... [edit] Retried build using makepkg -C and after almost 2 hours (on i7) i got .. make[3]: Leaving directory '/home/cirrus/build/aur/lib32-qt4/src/qt-everywhere- make: *** [Makefile:891: sub-tools-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

dkaylor commented on 2017-02-19 10:31 (UTC)

Your -8 fails for me as well. Fresh build, no existing src or pkg trees, just makepkg -c. All previous built OK. Also, with the maintainer change and major rebase, you really should have bumped it to -9. 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) ^~~~ make[4]: *** [Makefile:14146: .obj/release-shared/helpviewer_qwv.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory '/home/dkaylor/data2/pkgbuilds/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]: Leaving directory '/home/dkaylor/data2/pkgbuilds/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]: Leaving directory '/home/dkaylor/data2/pkgbuilds/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]: Leaving directory '/home/dkaylor/data2/pkgbuilds/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/tools' make: *** [Makefile:891: sub-tools-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build().

billypilgrim commented on 2017-02-19 10:24 (UTC)

So I tried again with a clean build in a new directory (previously I was using pacaur). It failed again. I've logged my build output: http://pastebin.com/fABf9Bsw. I could only include the last few hundred lines as the full output came to 19MB.

WoefulDerelict commented on 2017-02-18 23:40 (UTC) (edited on 2017-04-27 08:06 (UTC) by WoefulDerelict)

Yamakaky: makepkg will not extract a package with a bad checksum. If you're extracting an archive that doesn't match the checksum provided and it doesn't contain the files the PKGBUILD expects in order to properly build this, it will fail. It sounds like you have an incomplete download and need to fetch the source again. gun26, billypilgrim, aunali1: I can't reproduce that failure locally in a dirty build on my workstation, a clean chroot or a clean VM. I've attempted building this against lib32-mesa-libgl and lib32-nvidia-libgl and it has succeeded. I need some more details if I'm to debug this as I can't confirm it is a problem with the PKGBUILD or the patches to the source used when building qt4 in [Extra].

Yamakaky commented on 2017-02-18 23:31 (UTC)

A few problems: - The tar.gz file has a bad checksum - lib32-qt4/PKGBUILD: ligne 49 : cd: qt-everywhere-opensource-src-4.8.7: no such file or directory. The tar.gz file doesn't seem to auto-extract in src/

WoefulDerelict commented on 2017-02-18 22:10 (UTC)

gun26: Thanks very much for the feedback, it will help in tracking this down to some degree. As I understand it you were able to build this with pkgrel 7 before the dependencies were expanded and the configure options changed at pkgrel 8? Did you try to build this after lisu_ml bumped the pkgrel or after I adopted it and reworked it? Both? Unfortunately I'm not sure I can help with skype and lib32-qt4 other than getting it to build again. Have you investigated the segfault with the older binary package to see what is going on?

gun26 commented on 2017-02-18 21:58 (UTC)

@WoefulDerelict it fails here too. There are no errors in patching that I can see. And I _always_ clear the src and pkg subdirectories before building anything from AUR. Your previous -7 version built fine. -8 does not. However, even using a successfully built lib32-qt4-7 I can't get the old skype not to segfault any more, so I may have to give up on it and lib32-qt4 and put up with the dreadful "skypeforlinux" alpha from now on. :-(

WoefulDerelict commented on 2017-02-18 21:32 (UTC)

It is unfortunate that this isn't building for you aunali1 and billypilgrim; however, I can not reproduce this error on my workstation or in test environments. The posted snippit isn't terribly enlightening but it leads me to suspect something went awry while patching the sources and you're both attempting to build broken code. Could you share the process you're using to build this? What command did you use and how did you fetch the updated resources? If you could capture the entire build output, host it via your favourite text paste bin and share the URL one would have a much better chance of diagnosing the issue. I would suggest attempting to rebuild this with makepkg -C to ensure there isn't anything lingering in $srcdir breaking the build. Starting with a completely clean build space would be the best option as I suspect you're both bumping into some cruft that is causing this to fail.

billypilgrim commented on 2017-02-18 20:36 (UTC)

It's still failing for me with the same message as @aunall1

« First ‹ Previous 1 .. 18 19 20 21 22 23 24 25 Next › Last »