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: None
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 .. 13 14 15 16 17 18 19 20 21 22 23 .. 25 Next › Last »

tc1384 commented on 2017-02-23 13:56 (UTC) (edited on 2017-02-23 16:49 (UTC) by tc1384)

@WoefulDerelict I forgot to mention I am running linux-rt 4.9.11_rt9-1 on both machines. Edit: I tried installing the microcode on the Haswell system and recompiling lib32-qt4 That FAILED I then removed the microcode and tried recompiling (deleted previous source) That FAILED. So - I am now unable to compile what previously compiled successfully.

snack commented on 2017-02-23 08:59 (UTC)

I get this error while building version 4.8.7-8: Creating qmake. Please wait... The QtDBus module cannot be enabled because libdbus-1 version 0.93 was not found. Turn on verbose messaging (-v) to ./configure to see the final report. If you believe this message is in error you may use the continue switch (-continue) to ./configure to continue. Maybe some depend/makedepend is missing?

tc1384 commented on 2017-02-23 07:17 (UTC)

@WoefulDerelict I am NOT updating the micrcode on the Haswell and it compiles successfully. On the i5, M 460 2.5GHz machine I am updating the microcode and it does not compile. Both machines are up to date.

maxyme commented on 2017-02-23 06:44 (UTC) (edited on 2017-02-23 07:20 (UTC) by maxyme)

I'm having a similar issue to the link you posted: http://blfs-dev.linuxfromscratch.narkive.com/d2pzKCq9/kde4 Running on a Intel i5-6200U Skylake, 16gb DDR4 Ram. Failed to build on CK Kernel as well as LTS. I have lib32-libglvnd and lib32-mesa-libgl installed. I've tried building a few times and have failed with the same error each time. I am installing the package using yaourt if that helps. A sizeable chunk of the output from compiling: http://pasted.co/95e43a33 Edit: I'm updating the microcode on this machine.

ZeroBit commented on 2017-02-22 18:27 (UTC)

@WoefulDerelict >This is output from youart -Syua, yes? Yes, it is.

WoefulDerelict commented on 2017-02-22 16:17 (UTC) (edited on 2017-02-22 16:34 (UTC) by WoefulDerelict)

olsonpm: This package provides a compatibility layer for 32-bit binary applications that utilize the QT 4 framework. The QT framework provides cross-platform libraries developers use when building applications to take care of things like drawing the user interface. As stated above it is suspected this is some issue with QT4's build system that results in a race condition on some machines. ranger: My only guess is that you might not be updating the microcode on your i7 and that is somehow contributing to the race condition; however, errors seem to be coming from all across the Intel i* generations from Westmere up through Haswell which makes that seem unlikely. I'm not sure which -8 you caught but -7 was the original sources used in [Multilib] before lisu_ml attempted to update the package to fix [FS#47301] or nerf the bash expansion in the first -8 before this was orphaned. When I rebased this on [Extra] upon adopting, it migrated back to compiling with GCC instead of clang which likely has some bearing on the race condition. If you could test [!bashExpansion] and [GCC] it might help pinpoint this. [!bashExpansion] rolls up through all the simple changes requested in [FS#47301] and doesn't depend on bash expansion to fill the dependency array which are the changes made by lisu_ml before this was orphaned. It still uses clang. [GCC] just swaps out the compiler. I made sure to try and isolate this in tests as it seemed many more users started seeing this condition when I changed the tooling back to default instead of just a few when it used clang. It is hard to tell as I wager few tried to build it back at -7 as there was a matching binary release. Errors started showing up the moment lisu_ml iterated the pkgrel, triggering updates and a great many more builds. tc1384: Very curious indeed. Most the errors reported so far seem to have been originating from newer Haswell machines. Here you are succeeding on a Haswell and failing on an old Westmere with something really new and interesting. Are you updating the microcode on these machines? Were they both in sync? ZeroBit: I've nabbed the log. Thank you. You can take it down now if you like. This is output from youart -Syua, yes?

vongoom commented on 2017-02-22 16:10 (UTC)

I use this package, and I think most of us do, just because it's a requisite for Skype. Since Skype is working well with an old version, I'm not taking the hassle to compile this new version which doesn't build.

olsonpm commented on 2017-02-22 15:50 (UTC)

fyi - cleaning the package cache didn't work for me (meephz mentioned it did for them) I plan on providing the info for my machine tonight. The combination of my not having used 'chroot', nor any of those arch helper scripts caused for slow progress based off the instructions/feedback here. That is my own fault for being a noob :) Thanks so much for this package btw. I have no idea what it does but I know I've benefited from it.

ranger commented on 2017-02-22 14:15 (UTC) (edited on 2017-02-22 14:15 (UTC) by ranger)

@WoefulDerelict So I tried again to build in my main pc (i7-3537U, ssd, 8GB RAM, using /tmp) First try, I killed my DE and X and tried to build from terminal (150 MB used) but still using /tmp. Failed like before. Then I started the system normally and tried to build in my ~, without using /tmp. Again failed at the same point. So at least we know it has nothing to do with building in RAM, it's something in my setup. I don't know why I had no problem with -7...

tc1384 commented on 2017-02-22 12:19 (UTC)

It builds OK on Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz MemTotal: 16372612 kB pacman -Q lib32-qt4 lib32-qt4 4.8.7-8 Build FAILS on my laptop Intel(R) Core(TM) i5 CPU M 460 @ 2.53GHz MemTotal: 8166864 kB .cache/pacaur/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/tools/bootstrap/libbootstrap.a(qmalloc.o)' is incompatible with i386:x86-64 output .cache/pacaur/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/tools/bootstrap/libbootstrap.a(qdir.o): In function `QDir::cleanPath(QString const&)': qdir.cpp:(.text+0x12ae): undefined reference to `qMalloc(unsigned long)' ... qvector.cpp:(.text+0xba): undefined reference to `qReallocAligned(void*, unsigned long, unsigned long, unsigned long)' collect2: error: ld returned 1 exit status make: *** [Makefile:118: ../../../bin/moc] Error 1

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 22 23 .. 25 Next › Last »