Package Details: qt4 4.8.7-36

Git Clone URL: https://aur.archlinux.org/qt4.git (read-only, click to copy)
Package Base: qt4
Description: A cross-platform application and UI framework
Upstream URL: https://www.qt.io
Licenses: GPL-3.0-only, LGPL-3.0-only, GFDL-1.3-only
Conflicts: qt
Replaces: qt
Submitter: arojas
Maintainer: DodoGTA
Last Packager: DodoGTA
Votes: 80
Popularity: 2.22
First Submitted: 2019-05-01 11:51 (UTC)
Last Updated: 2024-06-26 19:25 (UTC)

Dependencies (30)

Required by (236)

Sources (22)

Pinned Comments

eschwartz commented on 2019-05-09 13:24 (UTC)

@semeion,

qt4 was expelled from the official repositories due to https://lists.archlinux.org/pipermail/arch-dev-public/2019-April/029560.html

It will not be restored, because software needs to stop using qt4. It's fine for people to still use it via the AUR if they have old software that is not ported, but the proper solution is to get that software ported to qt5.

"It takes a long time to compile" is not a reason to move it to community.

@xuanruiqi,

Only Developers and Trusted Users have access to pkgbuild.com, and we will not be uploading qt4 there. If we wanted qt4, we would upload it to community, but we don't -- we have managed to move every package still being actively maintained in the official repos, over to qt5, and we want to stay that way.

...

Again, the proper long-term solution is to get software ported over to qt5.

dviktor commented on 2019-05-05 17:49 (UTC) (edited on 2019-05-15 19:02 (UTC) by dviktor)

For those who have problems with ‘std::tr1’ has not been declared error: build in clean chroot with extra-x86_64-build script.

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 18 Next › Last »

<deleted-account> commented on 2020-05-10 18:05 (UTC)

@dviktor Right on. That was epicly fast.

dviktor commented on 2020-05-10 17:56 (UTC)

@optimisticninja should be fixed now

<deleted-account> commented on 2020-05-10 17:30 (UTC)

@dviktor absolutely. Building with the default PKGBUILD yields this for myself.

 /usr/bin/strings: './endiantest': No such file

/usr/bin/strings: './endiantest': No such file

rm -f endiantest.o

rm -f *~ core *.core

rm -f endiantest

rm -f Makefile

The target system byte order could not be detected!

Turn on verbose messaging (-v) to see the final report.

You can use the -little-endian or -big-endian switch to

./configure to continue.

==> ERROR: A failure occurred in build().

Aborting...

Error making: qt4

UPDATE: I am running a hardened kernel, this could have something to do with it.

dviktor commented on 2020-05-10 17:28 (UTC)

@optimisticninja could you please describe your request in more detail? This package compiled fine for the past

<deleted-account> commented on 2020-05-10 17:24 (UTC)

Please modify the configure command to include -little-endian and -host-little-endian. PKGBUILD is broken in current state.

mgc commented on 2020-05-08 18:06 (UTC)

or ingorepkg = qt4 to 'save your trouble'

eschwartz commented on 2020-04-28 18:03 (UTC)

This may be true, but you can't expect everyone to use a clean chroot. This build process is too fragile. It should work in any linux environment that satisfies the dependencies, and only ever fail with an explicit message indicating which dependencies are missing.

Your argument is invalid.

If this builds in a clean chroot, it indicates that this works correctly under expected circumstances. It additionally means the maintainer might not know why your system is special causing it to not work.

And make no mistake about it -- your system is special if it doesn't work. My system can build qt4 just fine outside of a clean chroot (I have just finished doing so), so clearly it is not impossible, and this matches the expected clean chroot results, so...

While it's possible that specific issues causing it to fail might be dealt with, I'd argue that the onus is on you, the person who it is failing for, to figure out the solution, rather than the maintainer, who it builds fine for.

I bet if someone could figure out the problem, dviktor would be happy to incorporate that feedback in the PKGBUILD.

dviktor commented on 2020-04-28 16:55 (UTC)

@Drew it's entirely related to the Qt building process. I think we can't do a lot to improve building stability (please also consider how much time has passed since last Qt 4 update). Robust packages build fine on any system but this is not the case so we are forced to use clean chroot build or precompiled binary.

Drew commented on 2020-04-28 16:04 (UTC)

I have not been able to upgrade since 4.8.7-28

make[2]: *** [Makefile.WebKit:1146: .obj/release-static/YarrInterpreter.o] Error 1
make[2]: Leaving directory '/home/drew/.cache/yay/qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/JavaScriptCore'
make[1]: *** [Makefile.WebKit:43: sub-JavaScriptCore-JavaScriptCore-pro-make_default-ordered] Error 2
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/drew/.cache/yay/qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source'
make: *** [Makefile:747: sub-webkit-make_default-ordered] Error 2

@alan1world this builds fine in a clean chroot.

This may be true, but you can't expect everyone to use a clean chroot. This build process is too fragile. It should work in any linux environment that satisfies the dependencies, and only ever fail with an explicit message indicating which dependencies are missing.

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 18 Next › Last »