Package Details: qt4 4.8.7-29

Git Clone URL: https://aur.archlinux.org/qt4.git (read-only)
Package Base: qt4
Description: A cross-platform application and UI framework
Upstream URL: https://www.qt.io
Licenses: custom, GPL3, LGPL, FDL
Conflicts: qt
Replaces: qt<=4.8.4
Submitter: arojas
Maintainer: dviktor
Last Packager: dviktor
Votes: 14
Popularity: 9.735362
First Submitted: 2019-05-01 11:51
Last Updated: 2019-05-04 10:28

Dependencies (29)

Required by (713)

Sources (19)

Pinned Comments

eschwartz commented on 2019-05-09 13:24

@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

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

1 2 3 4 5 6 ... Next › Last »

totsilence commented on 2019-05-25 06:48

Just wanted to let everyone know that there is a bug in GCC 9 (now in testing), which makes it miscompile the foreach macro in Qt4:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617

Since that macro is used extensively throughout the Qt source code I can only imagine that compiling qt4 with the current testing gcc will cause severe breakage.

We can fix this in two ways:

1) Wait for gcc fix 2) Apply a patch to qt4 to change the way Q_FOREACH is coded.

andreymal commented on 2019-05-16 20:00

Missing dependency gstreamer0.10-base?

cd WebCore/ && $/aur-qt4/src/qt-everywhere-opensource-src-4.8.7/bin/qmake $/aur-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/WebCore/WebCore.pro -spec $/aur-qt4/src/qt-everywhere-opensource-src-4.8.7/mkspecs/linux-g++ -o Makefile.WebKit

Project ERROR: Package gstreamer-app-0.10 not found

make[1]: *** [Makefile.WebKit:72: WebCore/Makefile.WebKit] Error 2

Tharbad commented on 2019-05-11 22:41

@dviktor: Can you add that the right script for the devtools is extra-x86_64-build?

dviktor commented on 2019-05-11 12:30

@Tharbad no, it's not proper way to perform clean chroot build. Please follow instructions in wiki

Tharbad commented on 2019-05-11 02:28

Used yay clean build option. Got:

In file included from ./wtf/FastAllocBase.h:93,
             from ./wtf/RefCounted.h:25,
             from ./wtf/CrossThreadRefCounted.h:36,
             from ./wtf/text/StringImpl.h:28,
             from ./runtime/UString.h:26,
             from yarr/YarrPattern.h:30,
             from yarr/YarrInterpreter.h:29,
             from yarr/YarrInterpreter.cpp:28:
./wtf/TypeTraits.h:186:69: error: ‘std::tr1’ has not been declared
template<typename T> struct HasTrivialConstructor : public 
std::tr1::has_trivial_constructor<T> { };                                          
                ^~~
./wtf/TypeTraits.h:186:74: error: expected ‘{’ before ‘has_trivial_constructor’
template<typename T> struct HasTrivialConstructor : public 
std::tr1::has_trivial_constructor<T> { };

^~~~~~~~~~~~~~~~~~~~~~~ ./wtf/TypeTraits.h:187:68: error: ‘std::tr1’ has not been declared template<typename T> struct HasTrivialDestructor : public std::tr1::has_trivial_destructor<T> { }; ^~~ ./wtf/TypeTraits.h:187:73: error: expected ‘{’ before ‘has_trivial_destructor’ template<typename T> struct HasTrivialDestructor : public std::tr1::has_trivial_destructor<T> { };

^~~~~~~~~~~~~~~~~~~~~~

yarr/YarrInterpreter.cpp: In member function ‘bool 
JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd(JSC::Yarr::ByteTerm&, 
JSC::Yarr::Interpreter::DisjunctionContext*)’:
yarr/YarrInterpreter.cpp:707:13: warning: this statement may fall through [-
Wimplicit-fallthrough=]
         if (backTrack->begin == notFound) {
         ^~
yarr/YarrInterpreter.cpp:711:9: note: here
     case QuantifierNonGreedy:

     ^~~~
make[2]: *** [Makefile.WebKit:1062: .obj/release-static/YarrInterpreter.o] Error 1
make[2]: Leaving directory '/tmp/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]: Leaving directory '/tmp/yay/qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source'
make: *** [Makefile:747: sub-webkit-make_default-ordered] Error 2
==> ERROR: A failure occurred in build().
Aborting...

Also, when trying to remove qt4 I noticed it's dependency of kde.

mozo commented on 2019-05-10 15:02

Just for example there will be never alternative for KBGOffice Dictionary for it is abandoned years ago but is the only one Eng<->Bg dictionary for Linux. Some packages just doesn't have alternatives.

https://i.imgur.com/UszXcnW.png

eschwartz commented on 2019-05-10 14:52

Except none of that makes sense. sip does not need qt4, and it doesn't need qt5 either -- it just generates code for them. And the real issue with sip is that in the latest version of sip, the upstream developer of sip, removed all qt4 support. https://www.riverbankcomputing.com/hg/sip/rev/328f2e872d64

All three of those packages are AUR packages... it's not unheard of for one AUR package to depend on another. And spflashtool-bin requires qtwebkit in addition to qt4... do you realize qtwebkit has been in the AUR for two years now?

This is not about "drying the well", and we're not trying to force anyone to port anything. We're simply saying that for years we've only begrudgingly supported qt4 at all, and we finally decided to stop. There's no use getting upset about the lack of support for really old things; we don't support KDE3, gnome2, linux 3.x either, now it is qt4's turn.

My advice is to port it or ask someone else to port it, because getting it ported will make it easier to run without requiring AUR packages, and will be beneficial in the long run either way.

Alternatively, look for modern alternatives to these packages.

dviktor commented on 2019-05-10 14:34

@Tharbad recheck your /etc/makepkg.conf and also show us steps how do you create clean chroot. Please post full relevant error so we can inspect it.

@piedro I think it's clear now how to build this package. For those who can't build it under usual environment method with clean chroot exists and works just fine.

It's inevitable that some software becomes obsolete and out-of-date, new versions will replace the old one - this is normal process of software development. Great example are GCC compilers version 6 and 7 (and, in near future, 8) - they are also moved out to the AUR and also requires a lot of time to build but I don't see anyone who complains about it. If you're not satisfied with AUR solution you can always find binary repository for qt4 and install it directly.

mozo commented on 2019-05-10 12:50

@piedro +1

piedro commented on 2019-05-10 11:54

The package "sip" is in the official extra repository and still needs qt4.

Also "everpad", "soundwire", "spflashtool"... to name only a few.

The idea to "dry the well" to make people behave in a certain way seems very questionable to me... The decision to make it harder for users in order to force porting is really twisted! And also misdirected. The result is that the users waste their time on figuring out how to compile qt4 while the developers of the "old" applications just don't care...

But well, though I am not a developer responsible for porting to qt5 I still need qt4 - so I will have to figure out how to compile it. What a waste of time.

pk