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.012471
First Submitted: 2017-02-09 20:36 (UTC)
Last Updated: 2019-11-19 22:10 (UTC)

Sources (15)

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

tioguda commented on 2022-06-17 20:48 (UTC)

It is necessary to add the patch for gcc11.

Mipster commented on 2021-09-06 08:42 (UTC) (edited on 2021-09-06 08:42 (UTC) by Mipster)

My default compiler is clang, and it won't compile the source as is because clang defines a statement like this as an error

if(pointer > 0)

and it appears in the source
here is a link to an issue in mac ports for the same issue with a fix
https://trac.macports.org/ticket/54183
they give the solution made in the original project

this is a patch with the same solution, worked for me locally:
https://pastebin.com/EZVjSyVv

I'll mention it to be sure, but I don't think that it matters that much
I am running manjaro and not pure arch

Alkaris commented on 2021-02-23 22:51 (UTC)

This package fails with 404, because 4.8.7 does not exist in the directory → https://download.qt.io/archive/qt/4.8/

take a look and you will see it doesn't exist, you will need to either replace it with a different version or change the host where it can be downloaded.

bkb commented on 2021-02-04 08:32 (UTC)

It's even worse now, it's 404'ed

curl: (22) The requested URL returned error: 404 Not Found
==> ERROR: Failure while downloading https://download.qt.io/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz
    Aborting...
error: failed to download sources for 'lib32-qt4-4.8.7-15':

bkb commented on 2021-01-30 11:19 (UTC)

paru

commented on 2021-01-30 11:16 (UTC)

How do you install this using terminal?

China: http://mirrors.sohu.com/qt-all/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz

USA: https://ftp.osuosl.org/pub/blfs/conglomeration/qt4/qt-everywhere-opensource-src-4.8.7.tar.gz

bkb commented on 2021-01-25 09:03 (UTC) (edited on 2021-01-25 09:07 (UTC) by bkb) 

curl: (22) The requested URL returned error: 403 Forbidden
==> ERROR: Failure while downloading https://download.qt.io/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz

Maintainer hasn't done anything since 2 years, I have no hope for him to correct that

Alkaris commented on 2021-01-25 00:43 (UTC)

Seems to be an issue while downloading package with Error 403 Forbidden. URL must be outdated, or download server permissions have been changed.

MCOfficer commented on 2021-01-20 12:32 (UTC)

Because download.qt.io seems to be down and most mirrors only host 5.x and 6.x, here are two alternative URLs for the current version (4.8.7). The usual disclaimers apply.

China: http://mirrors.sohu.com/qt-all/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz

USA: https://ftp.osuosl.org/pub/blfs/conglomeration/qt4/qt-everywhere-opensource-src-4.8.7.tar.gz

commented on 2020-04-06 16:26 (UTC)

0ffline packages: http://s.go.ro/f8rzjz29

slav commented on 2019-11-21 07:11 (UTC)

@Kalinda Thank you a lot.

Kalinda commented on 2019-11-20 23:04 (UTC)

Hey guys,

For anyone who has trouble building this huge package, I am providing it in my repo. You can find the info at https://aur.andontie.net

slav commented on 2019-11-20 22:17 (UTC)

Guys can you provide build lib32-qt4 4.8.7-15-x86_64.pkg.tar.xz file? Regards, Slav

WoefulDerelict commented on 2019-11-19 22:13 (UTC)

bitspyer: This should now be corrected.

PedroHLC: It does seem that way. Including the patches used by qt4 results in a successful build on my test box in a clean chroot.

bitspyer commented on 2019-11-14 11:00 (UTC)

lib32-qt4 wont build, also in clean chroot, as discribed in the pinned commentary.

Building always stops with this Message (in clean chroot and normal system):

dialogs/qpagesetupdialog_unix.cpp:553:12: error: ‘class Ui::QPageSetupWidget’ has no member named ‘paperHeight’ 553 | widget.paperHeight->setValue(m_paperSize.height() / m_currentMultiplier); | ^~~~~~~~~~~ compiling dialogs/qabstractpagesetupdialog.cpp dialogs/qpagesetupdialog_unix.cpp: At global scope: dialogs/qpagesetupdialog_unix.cpp:70:13: warning: ‘void populatePaperSizes(QComboBox)’ defined but not used [-Wunused-function] 70 | static void populatePaperSizes(QComboBox cb) | ^~~~~~~~~~~~~~~~~~ make[1]: [Makefile:129212: .obj/release-shared/qpagesetupdialog_unix.o] Error 1 make[1]: Waiting for unfinished jobs.... make[1]: Leaving directory '/build/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/gui' make: *** [Makefile:421: sub-gui-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

PedroHLC commented on 2019-09-27 15:09 (UTC)

Looks like that patches are required to build with GCC9

medicineman25 commented on 2018-07-09 04:52 (UTC) (edited on 2018-07-09 04:54 (UTC) by medicineman25)

Hey there, thanks for doing this package. Please update the qt source to: http://download.qt.io/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz

Or if this package is using a newer version of Qt, then we can just change the version number :)

Cheers!!

sam-cavalcanti commented on 2018-07-03 03:42 (UTC)

Please change http://download.qt.io/official_releases/qt/4.8/${pkgver}/${_pkgfqn}.tar.gz for http://download.qt.io/archive/qt/4.8/${pkgver}/${_pkgfqn}.tar.gz

WoefulDerelict commented on 2018-06-13 18:05 (UTC)

8XA: I do not encounter any issues when using the official download URL. If you're unable to successfully download the tarball from the URL in the source array I'd suggest http://master.qt.io/official_releases/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz as the best alternative.

8XA commented on 2018-06-13 05:56 (UTC)

The source has an error, I put this link instead: http://qt.mirror.constant.com/official_releases/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz Then, everything went OK.

WoefulDerelict commented on 2018-01-27 23:34 (UTC)

ArnaudNux: I can not reproduce that error in a clean chroot. Please read the pinned comments and retry your build in a clean chroot.

ArnaudNux commented on 2018-01-27 20:52 (UTC)

graphicsview/qgraphicswidget.cpp:1443:5: note: here case QEvent::GraphicsSceneMouseMove: ^~~~ graphicsview/qgraphicswidget.cpp: In member function 'virtual void QGraphicsWidget::changeEvent(QEvent*)': graphicsview/qgraphicswidget.cpp:1484:9: warning: this statement may fall through [-Wimplicit-fallthrough=] if (d->layout) ^~ graphicsview/qgraphicswidget.cpp:1486:5: note: here case QEvent::FontChange: ^~~~ moc graphicsview/qgraphicswidget.h compiling graphicsview/qgraphicswidget_p.cpp compiling graphicsview/qgridlayoutengine.cpp compiling graphicsview/qsimplex_p.cpp compiling graphicsview/qgraphicsanchorlayout_p.cpp compiling graphicsview/qgraphicsanchorlayout.cpp compiling util/qsystemtrayicon.cpp moc util/qcompleter.h compiling util/qcompleter.cpp moc util/qdesktopservices.cpp compiling util/qdesktopservices.cpp compiling util/qundogroup.cpp compiling util/qundostack.cpp moc util/qundoview.cpp compiling util/qundoview.cpp make[1]: No rule to make target 'util/qabstractsystemtrayiconsys.cpp', needed by '.obj/release-shared/qabstractsystemtrayiconsys.o'. Stop. make[1]: Leaving directory '/home/arnaud/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/gui' make: [Makefile:423: sub-gui-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

WoefulDerelict commented on 2018-01-26 09:43 (UTC)

I've merged the changes made in [Extra] to mend issues caused by ICU 60.1 and ensured lib32-icu is properly invited to the party if ICU is going to jump in and break the build.

ghthor commented on 2018-01-26 02:56 (UTC)

I managed to get it to build by applying this[1] change from the qt4 [extra] package. It was related to the icu-60.1 version bump. I've pushed that change and an addition of lib32-icu (optional) dependancy to my github[2].

[1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/qt4&id=5e7388ab98ceb32ccc2b44caba3259c371933b1e [2] https://github.com/ghthor/lib32-qt4.git

basil commented on 2018-01-06 15:31 (UTC)

@rafaelff Did you read the two pinned comments from WoefulDerelict at the top? I have a bash script that did all the dirty work. It was working at some point, not sure if it still does, but for sure it's worth a try.

See here: https://gist.github.com/basilschneider/2422cebb355427d6f4063dfde52fb371

Note also the comments at the bottom. They might further help you if the build is still not working.

rafaelff commented on 2018-01-06 14:06 (UTC)

Build failed. Here is the build() output: https://ptpb.pw/Pf5p - any ideia?

WoefulDerelict commented on 2017-07-12 16:20 (UTC)

dimytch: The patches used here are mirrored from qt4 in [Extra]. I'll investigate this when I have a chance; however, if you feel this patch is no longer necessary it would be prudent to file an issue with qt4 in [Extra] so this can be corrected in both builds.

dimytch commented on 2017-07-12 11:52 (UTC)

This patch is not needed anymore. prepare() { ... # http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ # patch -p1 -i "${srcdir}"/kubuntu_14_systemtrayicon.diff ...

JohnRobson commented on 2017-06-04 21:45 (UTC)

People, follow this, will work perfectly: https://gist.github.com/basilschneider/2422cebb355427d6f4063dfde52fb371

WoefulDerelict commented on 2017-05-27 13:29 (UTC) (edited on 2017-05-27 16:19 (UTC) by WoefulDerelict)

In order to appease a small group of users who've: commented here [severach], posted and immediately deleted comments (which I still get a copy of via e-mail) and even contacted me via e-mail requesting multilib support for legacy qtwebkit applications one has created lib32-qtwebkit. This works with applications like Skype 4.3.0.37 that are only distributed as 32-bit binaries. Of course not only does lib32-qtwebkit depend on lib32-qt4, as many users have already discovered with qtwebkit, it will also interfere with building lib32-qt4 once installed. This awkward situation, which will likely complicate future updates, can be resolved by building lib32-qt4 in a container. The Qt4 port of webkit takes about twice as long to build as the Qt4 blob without webkit. If you do not have the patience for a long build seek out a binary package in one of the unofficial repos.

WoefulDerelict commented on 2017-05-25 22:21 (UTC) (edited on 2017-05-25 22:22 (UTC) by WoefulDerelict)

biosin: Helpers do odd and stupid things sometimes. If the source is something you recognize you might be able to read through it and find out what pacaur is doing that causes the issue. Sadly, while these tools often make maintaining one's system easier the added complexity they introduce can lead to breakage during builds. If one's helper fails it is always best to fall back to using makepkg on a snapshot of the resources in the AUR. stefonarch: Not sure what's up there at all. There are now patches allowing this to build against OpenSSL 1.1 so lib32-openssl-1.0 was dropped as a dependency. It looks like it is in the webkit source which shouldn't be part of the build as it is explicitly disabled. There is likely something on your system interfering with the build. I can't reproduce the error in a clean chroot or on a dirty test box.

stefonarch commented on 2017-05-21 11:34 (UTC) (edited on 2017-05-21 11:36 (UTC) by stefonarch)

Same error as antoniovazquez on 2017-04-24 12:13: make[2]: *** [Makefile.WebKit:497627: .obj/release-static/MediaPlayer.o] Error 1 make[2]: uscita dalla directory "/tmp/makepkg/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/WebCore" make[1]: *** [Makefile.WebKit:79: sub-WebCore-make_default-ordered] Error 2 make[1]: uscita dalla directory "/tmp/makepkg/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source" make: *** [Makefile:747: sub-webkit-make_default-ordered] Error 2 yaourt -S lib32-openssl-1.0 solves for now.

commented on 2017-05-21 09:37 (UTC)

I don't know why, but each time I let pacaur download it together with aria2c, it didn't work, there was just a small file in the end. I downloaded it manually (with aria2c) and could makepkg -oi, so it works...

WoefulDerelict commented on 2017-05-20 15:05 (UTC) (edited on 2017-05-20 15:12 (UTC) by WoefulDerelict)

biosin: Yes, the checksum in the PKGBUILD is correct. Perhaps try fetching the source from an alternate location. http://master.qt.io/official_releases/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz Unfortunately upstream hasn't provided any resources users can utilize to verify the authenticity or integrity of the archive; however, local testing yields the same sha512sum on a fresh download of the tarball.

commented on 2017-05-20 11:14 (UTC)

I'm sorry but is the checksum correct for qt-everywhere-opensource-src-4.8.7.tar.gz? My download has b8085c86254cbe951aec73d8d2fedf9285fea94d487903bda40e3480193e68a55c63fc91d01635fcd5198c9d1555657eaede4961474a624137aa211193987a57 whereas in the PKGBUILD it says f9f81a2e7205e1fd05c8d923dc73244f29aa33f951fa6b7c5c8193449328b37084796b9b71ad0c317e4e6fd00017c10ea5d67b1b2032551cde00548522218125. Unfortunately on the website there are only MD5 and SHA-{1,256} given.

derblub commented on 2017-05-19 23:30 (UTC)

What's going on? Compilation is taking hours..

samarch commented on 2017-05-17 15:41 (UTC)

Indeed, the compilation is a real pain and takes ages, having the binaries of this package would be nice.

slav commented on 2017-05-13 21:32 (UTC)

Can we put ib32-qt4-4.8.7-13-x86_64.pkg.tar.xz for downloading please? Thank you

WoefulDerelict commented on 2017-05-13 19:03 (UTC)

Unfortunately I have yet another release and rebuild for you my lovelies. In this release we include a patch to make QT4 play nice with OpenSSL 1.1 and drop the lib32-openssl-1.0 dependency, mirroring the changes in [Extra]. At least thins out the prerequisites. If lib32-qt4 is your only package using lib32-openssl-1.0 it will be safe to remove this package after updating.

ArchRob commented on 2017-05-11 15:39 (UTC)

After hitting a wall with this package twice, I ended up automating the process in a shell script. Public gist here: https://gist.github.com/anonymous/b960fdc913040903b49776b404410da0 Basically, it grabs the latest packages for lib32-libmng and lib32-openssl-1.0, builds them in a clean chroot, then builds this package using the command WoefulDerelict posted in the pinned comment. Helpful, because when I need to update qt4 again in a couple of months, I probably won't remember how I did it the first two times :D

basil commented on 2017-05-06 19:02 (UTC)

I'm confused by the instructions here. I followed the steps up to multilib-build -- -I /<somewhere>/lib32-libmng-2.0.3-1-x86_64.pkg.tar.xz -I /<somewhere>/lib32-openssl-1.0-1.0.2.k-1-x86_64.pkg.tar.xz which worked. Now how can I install the package system wide? I went through the devtools Wiki, but it's not clear to me how to proceed. All help is much appreciated.

ranger commented on 2017-05-03 23:34 (UTC)

Again, lib32-qt4-4.8.7-12 has been build and I'm uploading at the moment. [archlinuxgr] Server = http://archlinuxgr.tiven.org/archlinux/$arch

slav commented on 2017-05-03 22:54 (UTC)

again request to upload please.... lib32-qt4-4.8.7-12-x86_64.pkg.tar.xz cheers

WoefulDerelict commented on 2017-05-03 22:44 (UTC)

PhoenixtheII: Yea, lib32-openssl-1.0 is a new special 1.0 compatibility package that became necessary after lib32-openssl moved to 1.1.0. 1.0 is part of the package's name like the openssl-1.0 package it mirrors in [Extra]. These packages provide support for legacy software that isn't compatible with openssl 1.1.0. It does need to be present in the chroot for this to build against or you'll get an error. Glad you got it sorted. One hopes the update to icu support isn't painful.

PhoenixtheII commented on 2017-05-01 07:22 (UTC) (edited on 2017-05-01 07:34 (UTC) by PhoenixtheII)

@WoefulDerelict: Had to manually compile in clean chroot lib32-openssl-1.0 from aur too... *facepalm*

maek commented on 2017-04-30 14:44 (UTC)

@kingcreole: I had your same issue and solved it by purging /var/lib/archbuild

WoefulDerelict commented on 2017-04-27 23:18 (UTC)

kingcreole: Unfortunately I can not reproduce this. The binary repo ranger maintains may be a less troublesome option for you. See the bottom of the second pinned post. Binaries of lib32-openssl-1.0 and lib32-qt4 are maintained there and built from the source here. I wager lib32-qtwebkit will find its way there soon after the qt4/ICU update lands in core.

kingcreole commented on 2017-04-27 19:58 (UTC) (edited on 2017-04-27 20:35 (UTC) by kingcreole)

that command in a free lib32-qt4 folder fails some update with this output: error: failed to commit transaction (conflicting files) ca-certificates-utils: /etc/ssl/certs/ca-certificates.crt exists in filesystem Errors occurred, no packages were upgraded. ==> ERROR: Aborting... by the way, it even does that when i delete /etc/ssl/certs/ca-certificates.crt

WoefulDerelict commented on 2017-04-26 20:43 (UTC)

It appears that this will need to be rebuilt against icu 59.1 / hunspell 1.6.0. I'll be iterating the package release when these move from testing into the standard repos. If you're using [Mulilib-testing] I'd suggest rebuilding this package against icu 59.1 / hunspell 1.6.0 to avoid issues.

WoefulDerelict commented on 2017-04-26 17:16 (UTC)

darkbasic: One has not found it necessary to build this in a clean chroot unless the system happens to be polluted with .pc files from other bits like qtwebkit that lead to issues. On various test environments I've successfully built this outside a clean chroot. lib32-openssl and lib32-openssl-1.0 are designed to be installed together as lib32-openssl-1.0 (-1.0 is part of the package name) is a clone of openssl-1.0 designed to offer compatibility with legacy software like QT 4 that doesn't support openssl 1.1.0. PhoenixtheII: It looks like your system is out of date and lib32-openssl-1.0 is not installed. The current version of lib32-openssl is 1:1.1.0.e-1. If you do not want to update your system to the openssl 1.1.0 deployment fetch package release 10. Package release 10 will build on openssl 1.0.2 systems.

PhoenixtheII commented on 2017-04-26 16:45 (UTC)

Doesn't build in clean chroot with lib32-openssl-1:1.0.2.k-1-x86_64.pkg.tar.xz installed from aur/lib32-openssl-1.0 error: target not found: lib32-openssl-1.0 ==> ERROR: 'pacman' failed to install missing dependencies. % sudo arch-nspawn /scratch/chroot64/root pacman -Q | grep openssl lib32-openssl 1:1.0.2.k-1 openssl 1.1.0.e-1

darkbasic commented on 2017-04-26 09:45 (UTC)

No I'm building release 11... $ pacaur -Ss lib32-openssl multilib/lib32-openssl 1:1.1.0.e-1 [installato] The Open Source toolkit for Secure Sockets Layer and Transport Layer Security (32-bit) aur/lib32-openssl-1.0 1.0.2.k-1 (18, 15,82) [installed] The Open Source toolkit for Secure Sockets Layer and Transport Layer Security (32-bit) I'm not using a clean chroot because I always managed to build it somehow, even using an AUR helper. Maybe the problem is having both multilib/lib32-openssl and aur/lib32-openssl?

slav commented on 2017-04-25 22:52 (UTC)

@ranger thank you, found now http://archlinuxgr.tiven.org/archlinux/x86_64/

ranger commented on 2017-04-25 22:28 (UTC)

@slav, check my previous comment

slav commented on 2017-04-25 22:03 (UTC)

Can someone drop lib32-qt4 4.8.7-11-x86_64.pkg.tar.xz please? Thank you

ranger commented on 2017-04-25 18:43 (UTC) (edited on 2017-04-25 22:27 (UTC) by ranger)

lib32-qt4-4.8.7-11 as well as lib32-openssl-1.0-1.0.2.k-1 have been uploaded to the archlinuxgr repo. As always, no changes to the PKGBUILD and build in a clean chroot

WoefulDerelict commented on 2017-04-25 17:55 (UTC)

darkbasic: While you are the first user to post a comment with that output it does not seem to be a new issue. If one parses the output correctly it appears that you attempted to build package release 10 against lib32-openssl 1:1.1.0.e which was known not to work. QT4 is not compatible with OpenSSL 1.1.0 and the issue was noted here when OpenSSL 1.1.0 hit testing. Release 11 should work so long as all the prerequisites have been met as it builds against a new lib32-openssl-1.0 package which should provide all the expected symbols.

darkbasic commented on 2017-04-25 11:05 (UTC)

compiling .moc/release-shared/moc_qnetworkaccessbackend_p.cpp In file included from ssl/qsslsocket_openssl_symbols.cpp:47:0: ssl/qsslsocket_openssl_symbols.cpp: In function ‘const SSL_METHOD* q_SSLv3_client_method()’: ssl/qsslsocket_openssl_symbols_p.h:169:39: error: ‘SSLv3_client_method’ was not declared in this scope ret q_##func(arg) { funcret func(a); } ^ ssl/qsslsocket_openssl_symbols.cpp:231:1: note: in expansion of macro ‘DEFINEFUNC’ DEFINEFUNC(const SSL_METHOD *, SSLv3_client_method, DUMMYARG, DUMMYARG, return 0, return) ^~~~~~~~~~ ssl/qsslsocket_openssl_symbols.cpp: In function ‘const SSL_METHOD* q_SSLv3_server_method()’: ssl/qsslsocket_openssl_symbols_p.h:169:39: error: ‘SSLv3_server_method’ was not declared in this scope ret q_##func(arg) { funcret func(a); } ^ ssl/qsslsocket_openssl_symbols.cpp:237:1: note: in expansion of macro ‘DEFINEFUNC’ DEFINEFUNC(const SSL_METHOD *, SSLv3_server_method, DUMMYARG, DUMMYARG, return 0, return) ^~~~~~~~~~ compiling .moc/release-shared/moc_qnetworkaccessdebugpipebackend_p.cpp make[1]: *** [Makefile:18393: .obj/release-shared/qsslsocket_openssl_symbols.o] Error 1 Is this a new error? I already removed qtwebkit since a long time.

WoefulDerelict commented on 2017-04-25 05:50 (UTC)

DellArch: After building one installs a local package with: pacman -U <path to pkg> If one has just completed step 3 installing the result would be as simple as: pacman -U lib32-qt4 4.8.7-10-x86_64.pkg.tar.xz

DellArch commented on 2017-04-24 13:25 (UTC)

I followed the steps without any errors back, but running $yaourt -Syua I still have the package not upgraded

antoniovazquez commented on 2017-04-24 12:13 (UTC)

../JavaScriptCore/runtime/JSGlobalObject.h: In constructor ‘JSC::JSGlobalObject::JSGlobalObject(JSC::JSGlobalData&, JSC::Structure*, JSC::JSObject*)’: ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef ‘dummyJSGlobalObject_has_only_a_single_slot’ locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/runtime/JSGlobalObject.h:140:13: note: in expansion of macro ‘COMPILE_ASSERT’ COMPILE_ASSERT(JSGlobalObject::AnonymousSlotCount == 1, JSGlobalObject_has_only_a_single_slot); ^~~~~~~~~~~~~~ In file included from /usr/include/unicode/utypes.h:38:0, from /usr/include/unicode/ucnv_err.h:88, from /usr/include/unicode/ucnv.h:52, from /usr/include/libxml2/libxml/encoding.h:31, from /usr/include/libxml2/libxml/parser.h:810, from /usr/include/gstreamer-0.10/gst/gstconfig.h:200, from /usr/include/gstreamer-0.10/gst/gstelement.h:55, from /usr/include/gstreamer-0.10/gst/gstbin.h:27, from /usr/include/gstreamer-0.10/gst/gst.h:35, from platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:32, from platform/graphics/MediaPlayer.cpp:46: /usr/include/unicode/umachine.h: At global scope: /usr/include/unicode/umachine.h:357:17: error: conflicting declaration ‘typedef int32_t UChar32’ typedef int32_t UChar32; ^~~~~~~ In file included from ../JavaScriptCore/wtf/unicode/Unicode.h:29:0, from platform/graphics/Color.h:31, from dom/Document.h:33, from platform/graphics/MediaPlayer.h:35, from platform/graphics/MediaPlayer.cpp:29: ../JavaScriptCore/wtf/unicode/qt4/UnicodeQt4.h:71:18: note: previous declaration as ‘typedef uint32_t UChar32’ typedef uint32_t UChar32; ^~~~~~~ In file included from ../JavaScriptCore/wtf/CrossThreadRefCounted.h:36:0, from ../JavaScriptCore/wtf/text/StringImpl.h:28, from ../JavaScriptCore/wtf/text/WTFString.h:28, from platform/text/PlatformString.h:28, from platform/KURL.h:29, from dom/IconURL.h:34, from dom/Document.h:36, from platform/graphics/MediaPlayer.h:35, from platform/graphics/MediaPlayer.cpp:29: ../JavaScriptCore/wtf/RefCounted.h: In instantiation of ‘void WTF::RefCounted<T>::deref() [with T = WebCore::Frame]’: ../JavaScriptCore/wtf/PassRefPtr.h:59:13: required from ‘void WTF::derefIfNotNull(T*) [with T = WebCore::Frame]’ ../JavaScriptCore/wtf/RefPtr.h:58:49: required from ‘WTF::RefPtr<T>::~RefPtr() [with T = WebCore::Frame]’ page/FrameTree.h:37:29: required from here ../JavaScriptCore/wtf/RefCounted.h:141:13: warning: deleting object of polymorphic class type ‘WebCore::Frame’ which has non-virtual destructor might cause undefined behavior [-Wdelete-non-virtual-dtor] delete static_cast<T*>(this); ^~~~~~ make[2]: *** [Makefile.WebKit:496577: .obj/release-static/MediaPlayer.o] Error 1 make[2]: Leaving directory '/tmp/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/WebCore' make[1]: *** [Makefile.WebKit:79: sub-WebCore-make_default-ordered] Error 2 make[1]: Leaving directory '/tmp/lib32-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... error: dependency package lib32-qt4 failed to build, aborting

WoefulDerelict commented on 2017-04-23 01:59 (UTC) (edited on 2017-04-23 02:00 (UTC) by WoefulDerelict)

DellArch: You will need a copy of the lib32-libmng package present to include in the chroot and the devtools package must be installed if you want to use the multilib-build script as shown. Currently the package in the ALA is perfectly sound and there is not reason not to use it unless you really like building things locally. In step 3 "/<somewhere>/lib32-libmng-2.0.3-1-x86_64.pkg.tar.xz" is meant to be expanded by the user to wherever they stored the package file so the script can install it in the chroot as it isn't part of the repos. This is going to install a base copy of Arch Linux on your system with all the packages needed to build lib32-qt4 including lib32-libmng so be sure you have lots of free disk space or it is going to get messy fast.

DellArch commented on 2017-04-22 23:26 (UTC)

Sorry guys, just to be sure, I find this error: rm -f release/libjscore.a mv -f libjscore.a release/ make[2]: Leaving directory '/tmp/yaourt-tmp-federico/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/JavaScriptCore' cd WebCore/ && /tmp/yaourt-tmp-federico/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/bin/qmake /tmp/yaourt-tmp-federico/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/WebCore/WebCore.pro -spec /tmp/yaourt-tmp-federico/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/mkspecs/linux-g++-32 -o Makefile.WebKit Project ERROR: Package gstreamer-app-0.10 not found make[1]: *** [Makefile.WebKit:72: WebCore/Makefile.WebKit] Error 2 make[1]: Leaving directory '/tmp/yaourt-tmp-federico/aur-lib32-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... ==> ERROR: Makepkg was unable to build lib32-qt4. ==> Restart building lib32-qt4 ? [y/N] So, I have to make a back up of lib32-libmng (it is no ok the package on ALA?) and then follow the 3 steps of the pinned comment? 1 - download from ALA the .pkg.tar.xz 2 - run: cd "folder with package downloaded" 3 - run: multilib-build -- -I /<somewhere>/lib32-libmng-2.0.3-1-x86_64.pkg.tar.xz

JohnRobson commented on 2017-04-07 01:22 (UTC)

Please, is possible to someone create a tutorial to use this "chroot" process? (or paste a link to some tutorial) The comments doesn't give me the necessary details for some steps. Thank you so much.

WoefulDerelict commented on 2017-04-06 22:58 (UTC)

WARNING: This is not compatible with lib32-openssl 1:1.1.0.e-1 from [Multilib-Testing]. This should be binary compatible with 32-bit copies of openssl 1.0; however there is not yet a lib32-openssl-1.0 in [Multilib-Testing]. I've sent a message to the maintainer requesting a 32-bit openssl 1.0 package for compatibility with legacy binaries. Mirror the added lines in [Extra]'s qt4 and testing the PKGBUILD against a personal staging package of lib32-openssl-1.0 produces some unexpected errors during linking. I have some leads and a possible solution but it is unlikely the update to openssl 1.1 with openssl 1.0 alongside it will be painless. Expect breakage.

mudrii commented on 2017-03-26 08:31 (UTC)

Failed to compile with bellow error Any idea ? make[1]: Entering directory '/home/irutsu/.cache/pacaur/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/corelib' compiling animation/qabstractanimation.cpp cc1plus: error: one or more PCH files were found, but they were invalid cc1plus: error: use -Winvalid-pch for more information cc1plus: fatal error: .pch/release-shared/QtCore: No such file or directory compilation terminated. make[1]: *** [Makefile:7394: .obj/release-shared/qabstractanimation.o] Error 1 make[1]: Leaving directory '/home/irutsu/.cache/pacaur/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/corelib' make: *** [Makefile:205: sub-corelib-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: failed to build lib32-qt4 package(s)

Xavion commented on 2017-03-24 20:31 (UTC)

It takes forever to download the tarball using that link. For some reason, it comes down much faster from Qt's "master" subdomain. Please use the following link in the PKGBUILD instead: * http://master.qt.io/official_releases/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz

severach commented on 2017-03-22 17:53 (UTC)

The problem is that someone put up qtwebkit which we don't need. What we need is lib32-qtwebkit.

WoefulDerelict commented on 2017-03-22 14:43 (UTC)

severach: WebKit has a plethora of known flaws that can be exploited and are unlikely to be fixed in this deployment. It has traditionally been broken off into a separate package from QT4 in [Extra] so users who need it can install it while allowing everyone else to avoid it. The webkit extensions were disabled in lib32-qt4 long before this was dropped from [Multilib] and found its way to the AUR. qtwebkit has been dropped from [Extra] and now resides in the AUR. Many legacy webkit packages were dropped from the repos during a recent purge. In the rare event a user needs the QT WebKit extensions for 32-bit compatibility this should be solved via a dedicated package. At present when building lib32-qt4 using the devtools script as I've suggested the lib32-libgl group, as qt4 in [Extra] which I mirror still uses the libgl group, will default to the first and only member of the group which is presently lib32-libglvnd, completing just fine. Changing the dependency array will break compatibility with older deployments so this seems less than prudent. If the distribution decides to drop the libgl group I'll follow; however, until then I'll leave it be to maintain compatibility as it isn't broken and functions exactly as it was intended.

severach commented on 2017-03-22 06:44 (UTC)

Clean chroot works. Because of the AUR dependency standard Arch build tools are too hard to make work. Graysky's clean-chroot-manager makes it easy peasy. Why was WebKit disabled? WebKit was the only useful part of this package. Dependency lib32-libgl should be changed to lib32-libglvnd. lib32-libgl is a group. Groups cannot be selected during a clean build.

astronouth7303 commented on 2017-03-22 00:31 (UTC)

Followed the chroot instructions: ==> Validating source files with sha512sums... qt-everywhere-opensource-src-4.8.7.tar.gz ... Passed improve-cups-support.patch ... Passed moc-boost-workaround.patch ... Passed kubuntu_14_systemtrayicon.diff ... Passed kde4-settings.patch ... Passed glib-honor-ExcludeSocketNotifiers-flag.diff ... Passed disable-sslv3.patch ... Passed l-qclipboard_fix_recursive.patch ... Passed l-qclipboard_delay.patch ... Passed qt4-gcc6.patch ... Passed qt4-glibc-2.25.patch ... Passed ==> Making package: lib32-qt4 4.8.7-10 (Tue Mar 21 20:29:00 EDT 2017) ==> Checking runtime dependencies... ==> Installing missing dependencies... sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges? ==> ERROR: 'pacman' failed to install missing dependencies. ==> ERROR: Build failed, check /tmp/chroot/astronouth7303/build

NicolasV commented on 2017-03-20 22:29 (UTC) (edited on 2017-03-20 22:31 (UTC) by NicolasV)

I faced the same issue regarding the build of this Skype dependency (yes Skype 4.3 works better and allow audio/video/screen sharing) I'm an Arch newcomer and on my small test machine (2GB of RAM) the compilation failed each time at the same step. I notice a massive amount of memory used and then... crash. A simple "du -sh" revealed the cause: /tmp is a 1GB tmpfs filesystem... on a 2GB machine? ridiculous... I decided to keep the RAM for the software and not for the temporary compilation files... I found this method pretty efficient: systemctl mask tmp.mount I restarted my PC and the lib32-qt4 compilation. You know what? No crash yet, still compiling. As I'm writing these lines, the current /tmp folder contains 1.4GB of files, beyond the 1GB limit of the initial tmpfs! Compiling big applications/libraries simply require sometimes more room (Firefox, QT4, LibreOffice...) That's why 1GB tmpfs is not enough. That's why a compilation inside a "clean chroot" works (because outside /tmp and the default 1GB limit)

WoefulDerelict commented on 2017-03-20 15:55 (UTC)

brandimarte: Glad to hear it didn't give you any problems. piedro: No, building in a clean chroot is not something that should be included in a PKGBUILD. It is unlikely that the plethora of variables that result in issues with this build will be addressed any time soon. These issues are not universal and many users are able to build this just fine outside of a clean chroot. If you want to know the difference between QT releases it is best to check the change log upstream. This will provide you with the most detailed account of what has been changed between releases. If you want to know what has happened between package releases there is a git history detailing the changes made. The majority of releases for QT 4.8.7 in [Extra] and iterations here have been to include patches to fix issues with QT 4.8.7.

brandimarte commented on 2017-03-19 16:40 (UTC)

Hi, just to let you know, the package compiled fine here. I was afraid to upgrade after reading the comments, but the compilation was successful. Best!

piedro commented on 2017-03-16 14:53 (UTC)

Hello! Sorry to say but this is the single most inconvenient update package in AUR I've ever dealt with. What is the difference to 4.8.4? Is there any need for updating anyway? Will there be a version that does not require all this clean-chroot-shenanigans? Shouldn't this be included in the PKGBUILD? thx, p.

Tharbad commented on 2017-03-15 20:04 (UTC)

I'm getting some compilation errors: compiling helpviewer_qwv.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) I *thought* such things don't suppose to happen anymore...

PhoenixtheII commented on 2017-03-14 13:45 (UTC)

After an hour of compiling I gave up (Core i7 6700k!) it seems to keep looping on compiling this here: ../JavaScriptCore/wtf/StdLibExtras.h: In function 'TO WTF::bitwise_cast(FROM)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyWTF_bitwise_cast_sizeof_casted_types_is_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/StdLibExtras.h:96:5: note: in expansion of macro 'COMPILE_ASSERT' COMPILE_ASSERT(sizeof(TO) == sizeof(FROM), WTF_bitwise_cast_sizeof_casted_types_is_equal); ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/StdLibExtras.h: In function 'size_t WTF::roundUpToMultipleOf(size_t)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummydivisor_is_a_power_of_two' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/StdLibExtras.h:120:5: note: in expansion of macro 'COMPILE_ASSERT' COMPILE_ASSERT(divisor && !(divisor & (divisor - 1)), divisor_is_a_power_of_two); ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/OwnPtr.h: In member function 'bool WTF::OwnPtr<T>::operator==(const WTF::OwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/OwnPtr.h:87:66: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator==(const OwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/OwnPtr.h: In member function 'bool WTF::OwnPtr<T>::operator!=(const WTF::OwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/OwnPtr.h:88:66: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator!=(const OwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/OwnPtr.h: In member function 'bool WTF::OwnPtr<T>::operator==(const WTF::PassOwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/OwnPtr.h:89:70: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator==(const PassOwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/OwnPtr.h: In member function 'bool WTF::OwnPtr<T>::operator!=(const WTF::PassOwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/OwnPtr.h:90:70: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator!=(const PassOwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/StringHasher.h: In static member function 'static unsigned int WTF::StringHasher::hashMemory(const void*)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummylength_must_be_a_multible_of_four' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/StringHasher.h:140:9: note: in expansion of macro 'COMPILE_ASSERT' COMPILE_ASSERT(!(length % 4), length_must_be_a_multible_of_four); ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/PassOwnPtr.h: In member function 'bool WTF::PassOwnPtr<T>::operator==(const WTF::PassOwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/PassOwnPtr.h:95:70: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator==(const PassOwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/PassOwnPtr.h: In member function 'bool WTF::PassOwnPtr<T>::operator!=(const WTF::PassOwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/PassOwnPtr.h:96:70: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator!=(const PassOwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/PassOwnPtr.h: In member function 'bool WTF::PassOwnPtr<T>::operator==(const WTF::OwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/PassOwnPtr.h:97:66: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator==(const OwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/wtf/PassOwnPtr.h: In member function 'bool WTF::PassOwnPtr<T>::operator!=(const WTF::OwnPtr<U>&)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyOwnPtrs_should_never_be_equal' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/wtf/PassOwnPtr.h:98:66: note: in expansion of macro 'COMPILE_ASSERT' template<typename U> bool operator!=(const OwnPtr<U>&) { COMPILE_ASSERT(!sizeof(U*), OwnPtrs_should_never_be_equal); return false; } ^~~~~~~~~~~~~~ ../JavaScriptCore/runtime/JSVariableObject.h: In constructor 'JSC::JSVariableObject::JSVariableObject(JSC::JSGlobalData&, JSC::Structure*, JSC::SymbolTable*, JSC::Register*)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyRegister_should_be_same_size_as_WriteBarrier' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/runtime/JSVariableObject.h:75:13: note: in expansion of macro 'COMPILE_ASSERT' COMPILE_ASSERT(sizeof(WriteBarrier<Unknown>) == sizeof(Register), Register_should_be_same_size_as_WriteBarrier); ^~~~~~~~~~~~~~ ../JavaScriptCore/runtime/JSGlobalObject.h: In constructor 'JSC::JSGlobalObject::JSGlobalObject(JSC::JSGlobalData&, JSC::Structure*)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyJSGlobalObject_has_only_a_single_slot' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/runtime/JSGlobalObject.h:127:13: note: in expansion of macro 'COMPILE_ASSERT' COMPILE_ASSERT(JSGlobalObject::AnonymousSlotCount == 1, JSGlobalObject_has_only_a_single_slot); ^~~~~~~~~~~~~~ ../JavaScriptCore/runtime/JSGlobalObject.h: In constructor 'JSC::JSGlobalObject::JSGlobalObject(JSC::JSGlobalData&, JSC::Structure*, JSC::JSObject*)': ../JavaScriptCore/wtf/Assertions.h:326:47: warning: typedef 'dummyJSGlobalObject_has_only_a_single_slot' locally defined but not used [-Wunused-local-typedefs] #define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1] ^ ../JavaScriptCore/runtime/JSGlobalObject.h:140:13: note: in expansion of macro 'COMPILE_ASSERT' COMPILE_ASSERT(JSGlobalObject::AnonymousSlotCount == 1, JSGlobalObject_has_only_a_single_slot);

slav commented on 2017-03-13 23:08 (UTC)

Thank you

ranger commented on 2017-03-13 21:11 (UTC)

I will update the repo as soon as possible. I'm away at the moment

slav commented on 2017-03-13 20:57 (UTC)

Can someone drop lib32-qt4 4.8.7-10-x86_64.pkg.tar.xz please? Thank you

WoefulDerelict commented on 2017-03-13 19:13 (UTC)

[Extra] adopted a new patch and I've chosen to include it as well. Happy building everyone.

WoefulDerelict commented on 2017-03-09 14:32 (UTC)

1ace: No, no, no a thousand times NO. Due to some inconsistencies in other lib32- packages needed for lib32-qt4 to work properly with GTK themes in the core binary repos the build system is allowed to troll your entire system for configuration files. Because you had gstreamer 0.10 installed it configured and attempted to build against gstreamer 0.10. The proper solution would have been to build the package in a clean chroot as has been suggested multiple times. In this environment there would be no gstreamer 0.10 and thus no issue. gstreamer 0.10 was dropped from the Arch Linux core repositories. It is probably unwise to build this package against gstreamer 0.10 as that may result in unexpected behaviour.

1ace commented on 2017-03-09 13:34 (UTC)

Had to install lib32-gstreamer0.10 and lib32-gstreamer0.10-base; are they maybe missing from makedepends?

WoefulDerelict commented on 2017-03-08 20:22 (UTC)

mnyolt: That option isn't used on Arch Linux by default for good reason: https://bbs.archlinux.org/viewtopic.php?id=171819 One can only reasonably supoort the default Arch Linux makepkg.conf options. Users who have modified makepkg.conf in any way are not supported. You changed it for your own reasons and if things break it is your responsibility to deal with it, not mine. It is entirely unreasonable to expect a PKGBUILD to cope with every random breaking change made to the system by the user. Managing the intricacies of your deployment are entirely your burden.

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.

mozo commented on 2017-03-07 18:31 (UTC)

I read the wiki and also tried to install in a clean chroot. Googled it and it is yet unclear operation for me. I'm not a developer, I'm a user. And english isn't my native language wich make things harder. Will you understand how to build in a clean chrood explained in Bulgarian? As I already said - I'll stick with binary.

WoefulDerelict commented on 2017-03-07 18:22 (UTC)

mozo: lib32-qt4 has been part of [Multilib] since at least 2013 according to the files in the Arch Linux Archive. I find it highly unlikely you've had to build this package frequently if at all in the past as it was only recently dropped from the binary repositories. Perhaps I'm wrong and you're intimately familiar with the ABS, in which case you should know QT 4 is legacy software and a great many packages have changed on the system over 5 years. It it unreasonable to expect build behaviour to remain the same when the underlying software has gone through multiple updates. Creating a clean chroot is essentially the same as installing Arch Linux. It would be entirely possible to use the installation tools to create and enter a new clean chroot. The Arch Linux developers have been kind enough to provide extra tooling in the devtools package. The wiki article linked provides a detailed explanation and examples of how the tooling is used. Arch Linux users are expected to be able to cope with documentation and solve problems on their own. If one had bothered to read and follow the instructions it should prove exceedingly simple to build this in a clean chroot as has been repeatedly suggested. Information pointing to the unofficial binary repository was provided should users not want to fuss with building the software on their own and hopefully will remain as a convenient option as this is a sizeable toolkit and takes a while to build. Which option you choose is entirely up to you.

mozo commented on 2017-03-07 17:56 (UTC) (edited on 2017-03-07 17:59 (UTC) by mozo)

WoefulDerelict: past five years since I use Arch, older lib32-qt4 versions compiled without any problems . I haven't any problems compiling all of my AUR packages too. Just lib32-qt4. I'll stick with binary for I don't know how to compile in clean chroot as most people.

WoefulDerelict commented on 2017-03-07 15:25 (UTC)

mozo: There is no viable way for me to create a PKGBUILD that would prevent users from having conflicting software installed during the build process. Were you to download the resources used to create the qt4 package and attempt to build it it would fail for you in exactly the same way. The problem isn't in the PKGBUILD instructions or the patches it applies to the QT 4 source code. The QT 4 build system is detecting additional resources installed on your system and attempting to include them in the build process which results in unexpected behaviour and errors. As one mentioned earlier, the instructions in this PKGBUILD and the patches it applies to the source are a mirror of those used to build the binary package in [Extra]. The only way to avoid unexpected errors when building QT 4 is to build it in a clean container where only the resources necessary to build it are present. It is not a requirement of the Arch Packaging Standards [https://wiki.archlinux.org/index.php/Arch_packaging_standards] that this be able to cope with dirty build envirnments. The documentation does; however, encourage the building of packages in clean containers.

mozo commented on 2017-03-07 15:06 (UTC)

The new version also fails to compile: http://pastebin.com/1nkSnptC Please, make it work just like all other packages in Arch. We haven't problems at all, just lib32-qt4. Thanks to ranger for the binary. Great work!

WoefulDerelict commented on 2017-03-07 14:18 (UTC)

remussatala: There is a package on your system that is breaking the build. You will need to compile the software in a clean container like the pinned comment suggests.

commented on 2017-03-07 05:18 (UTC)

rm -f libQtWebKit.so.4.10.4 libQtWebKit.so libQtWebKit.so.4 libQtWebKit.so.4.10 linking ../../../../../../lib/libQtWebKit.so.4.10.4 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../libgstapp-0.10.so when searching for -lgstapp-0.10 /usr/bin/ld: skipping incompatible /usr/lib/libgstapp-0.10.so when searching for -lgstapp-0.10 /usr/bin/ld: cannot find -lgstapp-0.10 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../libgstinterfaces-0.10.so when searching for -lgstinterfaces-0.10 /usr/bin/ld: skipping incompatible /usr/lib/libgstinterfaces-0.10.so when searching for -lgstinterfaces-0.10 /usr/bin/ld: cannot find -lgstinterfaces-0.10 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../libgstpbutils-0.10.so when searching for -lgstpbutils-0.10 /usr/bin/ld: skipping incompatible /usr/lib/libgstpbutils-0.10.so when searching for -lgstpbutils-0.10 /usr/bin/ld: cannot find -lgstpbutils-0.10 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../libgstvideo-0.10.so when searching for -lgstvideo-0.10 /usr/bin/ld: skipping incompatible /usr/lib/libgstvideo-0.10.so when searching for -lgstvideo-0.10 /usr/bin/ld: cannot find -lgstvideo-0.10 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../libgstbase-0.10.so when searching for -lgstbase-0.10 /usr/bin/ld: skipping incompatible /usr/lib/libgstbase-0.10.so when searching for -lgstbase-0.10 /usr/bin/ld: cannot find -lgstbase-0.10 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../libgstreamer-0.10.so when searching for -lgstreamer-0.10 /usr/bin/ld: skipping incompatible /usr/lib/libgstreamer-0.10.so when searching for -lgstreamer-0.10 /usr/bin/ld: cannot find -lgstreamer-0.10 collect2: error: ld returned 1 exit status make[2]: *** [Makefile.WebKit.QtWebKit:1210: ../../../../../../lib/libQtWebKit.so.4.10.4] Error 1 make[2]: Leaving directory '/tmp/yaourt-tmp-user/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/WebKit/qt' make[1]: *** [Makefile.WebKit:115: sub-WebKit-qt-QtWebKit-pro-make_default-ordered] Error 2 make[1]: Leaving directory '/tmp/yaourt-tmp-user/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source' make: *** [Makefile:747: sub-webkit-make_default-ordered] Error 2

WoefulDerelict commented on 2017-03-06 16:22 (UTC) (edited on 2017-03-06 16:29 (UTC) by WoefulDerelict)

ranger: Thanks for the support. Hopefully that will prove less confusing a path than building in a container.

ranger commented on 2017-03-06 16:20 (UTC) (edited on 2017-03-06 16:20 (UTC) by ranger)

As many people continue to have problem building this package, I uploaded the latest version to the archlinuxgr repo

WoefulDerelict commented on 2017-03-06 16:18 (UTC)

tc1384: qtwebkit is not the only package capable of interacting with this build which is why the first line clearly states the only way to avoid issues it to build in a clean container. slav: It was pointless to include that snippet as it contains no relevant information as to what the failure was, only that earlier something had failed. Something on your local system is likely interacting with QT 4's build system in an unpleasant way. Build it in a clean chroot or other form of container without extraneous packages.

slav commented on 2017-03-06 15:45 (UTC)

collect2: error: ld returned 1 exit status make[2]: *** [Makefile.WebKit.QtWebKit:1210: ../../../../../../lib/libQtWebKit.so.4.10.4] Error 1 make[2]: Leaving directory '/tmp/packerbuild-1000/lib32-qt4/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/3rdparty/webkit/Source/WebKit/qt' make[1]: *** [Makefile.WebKit:115: sub-WebKit-qt-QtWebKit-pro-make_default-ordered] Error 2 make[1]: Leaving directory '/tmp/packerbuild-1000/lib32-qt4/lib32-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... The build failed.

tc1384 commented on 2017-03-05 23:18 (UTC)

I did not have qtwebkit installed as noted in my post. > Note: qtwebkit was removed

WoefulDerelict commented on 2017-03-05 19:01 (UTC)

linus.c: If I read the output correctly it appears your build is running into some legacy 64-bit gstreamer 0.10 stuff and trying to include gstreamer 0.10 support as part of the build. It is failing because there is no matching lib32-gstreamer0.10 Building in a clean chroot should fix the issue.

WoefulDerelict commented on 2017-03-05 12:22 (UTC)

jro: Did you happen to try building this in a clean chroot at any point? There is a noted issue in the pinned comment where QT 4's build system where it will pull in resources found in a dirty build environment and those will cause output similar to yours. Please do not submit localized terminal output as it befuddles both automated translation software and maintainers. When submitting output please use the POSIX or C locale. tc1384: This seems like a build issue resulting from a dirty build environment. Other parts of QT 4, like qtwebkit, can not be present on the system or they will interact with the QT4 build and cause it to fail. This is noted in the pinned posted above all the other comments. The PKGBUILD functions absolutely fine in a clean container. Dirty build environments are NOT a packaging issue. It is and always has been best practice to build packages in a clean chroot.

tc1384 commented on 2017-03-05 11:17 (UTC) (edited on 2017-03-05 11:22 (UTC) by tc1384)

qvector.cpp:(.text+0xa9): undefined reference to `qRealloc(void*, 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[1]: *** [Makefile:117: ../../../bin/moc] Error 1 make[1]: Leaving directory '/home/usr1/.cache/pacaur/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/tools/moc' make: *** [Makefile:97: sub-moc-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: failed to build lib32-qt4 package(s) Note: qtwebkit was removed

PhotonX commented on 2017-03-05 11:16 (UTC)

@jro: Sounds like the problem described in the pinned comment.

jro commented on 2017-03-05 10:59 (UTC)

for me, build still fails reproducibly on three devices. Find the last 40 or so lines of the build log at https://gist.github.com/vasyugan/df99606405786ed0031c407626d18ddf

PhotonX commented on 2017-03-05 10:39 (UTC)

You're welcome and thanks for the fix, it works!

WoefulDerelict commented on 2017-03-04 22:12 (UTC)

PhotonX: Thanks very much for sticking with me through this and being my guinea pig. I do believe that pins down the problem and I can issue a proper fixed update now. Your diligence in tracking this down with me has been much appreciated.

PhotonX commented on 2017-03-04 22:02 (UTC)

TF2 passed the test.

PhotonX commented on 2017-03-04 21:39 (UTC)

TF1 failed the test, now building TF2.

WoefulDerelict commented on 2017-03-04 20:58 (UTC)

PhotonX: I've uploaded two more tests with some changes attempting to resolve the issue introduced in the last test. TF1 and TF2. They are different from one another and do not include the same changes. I'm hoping one of them will work properly and resolve your issue.

PhotonX commented on 2017-03-04 20:51 (UTC)

Exactly, it builds correctly but Skype looks ugly. Let me know if you need more test runs to bisect the issue further!

WoefulDerelict commented on 2017-03-04 20:46 (UTC)

PhotonX: If it builds correctly but fails to render the GTK theme then it means you have helped me narrow down the offending batch of changes and I can investigate a much smaller body of code for the root of the issue and hopefully fix it which will allow me to publish a finished release that is safe to update to unlike release 8 which has be fraught with build errors due to interactions with qtwebkit and GTK themes.

PhotonX commented on 2017-03-04 20:37 (UTC)

So, mBase failed. What does it mean?

WoefulDerelict commented on 2017-03-04 20:34 (UTC)

PhotonX: Rebase is a mirror of the current deployment rebased on [Extra]. It should be the exact same as the resources here in the AUR and is the revision currently failing to incorporate your GTK themes properly. mBase is a step between GCC and Rebase where the statements from [Extra] are used; however, the additional patches are not incorporated. It should isolate the issue down to something one did to the PKGBUILD during the rebase or the code changes made by the patches from [Extra]

PhotonX commented on 2017-03-04 20:06 (UTC)

Sorry, read too late that GCC contains Reconfigure. Does it also contain Rebase? Anyway, GCC and Reconfigure are passed, now doing mBase.

WoefulDerelict commented on 2017-03-04 19:33 (UTC)

PhotonX: GCC contains Reconfigure. If GCC passed there is no point in doing the other two from the first set as the offending change will not be there. Try mBase instead.

PhotonX commented on 2017-03-04 19:23 (UTC)

Well, in my opinion, if a package works, then is updated to a higher revision the software version staying unchanged and breaks something, the problem is clearly packaging related. :) Started the tests with GCC. GCC test has been passed. Now doing Reconfigure.

WoefulDerelict commented on 2017-03-04 19:16 (UTC)

PhotonX: I've dropped another test into the repo should you manage to make it through the previous three without reproducing the issue. mBase: This test includes the minimal number of patches necessary to build along with the statement tuning used in the rebase. This should point out if there is some mistake in the sed sorcery or if the issue stems from the additional patches from [Extra]

WoefulDerelict commented on 2017-03-04 18:10 (UTC)

PhotonX: My old Nehalelm i7-870 has finished derping through the build. It all looks good and I've updated the tests on GitHub. Feel free to give em a whack. I'll usually tackle an issue if it is actually packaging related. There are plenty of times it isn't something that can be accounted for by the PKGBUILD and there isn't much one can do. In this case I suspect it may have more to do with the additional patch sets from [Extra] than it does with the actual PKGBUILD but I did choose to include them during the rebase instead of just sticking to the essential three.

PhotonX commented on 2017-03-04 17:15 (UTC)

No worries and thanks again for your support!

WoefulDerelict commented on 2017-03-04 17:11 (UTC)

PhotonX: Short answer, it was late, I was sleepy and I didn't properly clean up things in the package function. Testing the fix now with my coffee and I'll be uploading it soon. Apologies. Please give it another go after the fix has been uploaded.

PhotonX commented on 2017-03-04 10:50 (UTC)

Actually, even the Origin test has file conflicts. What is wrong here?

PhotonX commented on 2017-03-04 08:43 (UTC) (edited on 2017-03-04 09:09 (UTC) by PhotonX)

Thanks! First result: Building the Reconfigure and GCC tests results in file conflicts (files in /usr/lib/qt4/bin/ and /usr/include/qt4/, being owned by the non-lib32 qt4 package). Building the next test now.

WoefulDerelict commented on 2017-03-04 03:13 (UTC)

PhotonX: I've isolated the most notable changes into a set of tests here: https://github.com/WoefulDerelict/PKGBUILDs/tree/master/tests Origin: This test is based on the original resources from [Multilib] that were dropped to the AUR. It includes [FS#47301 [https://bugs.archlinux.org/task/47301]] and the removal of bash expansion from the dependency arrays. As you state https://aur.archlinux.org/cgit/aur.git/tree/?h=lib32-qt4&id=77e07c49a2e24c4d64fa1b25fb54c123a7367136 'works fine' this version should also and provide a stable point to iterate from to find the offending change. Reconfigure: The configure options in this test are the ones used in the final release one published in the AUR. If this test fails it is likely the configure options borrowed from [Extra] are to blame and can be reverted to remedy the issue. GCC: This test removes the environment variables explicitly specifying clang as the complier from 'Reconfigure' which should revert it back to using GCC. An additional flag is passed to the compiler so GCC 6 will build qt4. This test is unlikely to result in failure. If the problem isn't introduced by this build then it likely stems from one of the patches used in [Extra] to fix issues with QT 4. This can likely be narrowed down and corrected if it is the case.

WoefulDerelict commented on 2017-03-03 21:39 (UTC) (edited on 2017-03-04 00:51 (UTC) by WoefulDerelict)

PhotonX: Were tsmuxer and skype statically linked you wouldn't be seeing issues with them as they would include the all library routines used by the program in the executable image. It is because these applications are dynamically linked and dependant on the libraries installed on the system that you're experiencing the current issue. Were the applications statically linked the issue wouldn't present its self until you rebuilt the application against the new library and it added the new routines to the executable image. journalctl and dmesg both log output from userspace applications in a default Arch Linux deployment. Unless you have customized your system's settings messages issued by userspace applications should be logged in the journal and dmesg. There were only a handful of major changes to the PKGBUILD that would have an effect on the output, possibly resulting in your current issues. Git has of course tracked all the changes made and they are fairly simple and straightforward. First, the dependency arrays were originally completed using bash expansion. This was removed and the arrays populated with a complete listing of the dependencies to expand compatibility with AUR helpers. Second, the location of some files were changed to address [FS#47301 [https://bugs.archlinux.org/task/47301]]. Next one synchronized the arguments passed to configure so they matched those in the PKGBUILD from [Extra], changing --reduce-relocations to no-reduce-relocations and modifying -sysconfdir to point to /etc/xdg instead of /etc. The headers included in the package were removed as these aren't commonly included in lib32- packages. After this the build was migrated from clang to gcc. Finally, the package resources were rebased on those used in [Extra] which used a different set of patches than the lib32- package from [Multilib]. As you can see in the highlighted changes the major payload that accompanied the rebase you linked were a different set of patches essentially rendering this a 32-bit mirror of resources from [Extra]. Focusing on the two revisions you've drawn attention to the earlier submission was made by lisu_ml in an attempt to address the first two issues raised with this PKBUILD. It successfully removes the bash expansion and attempts to implement [FS#47301 [https://bugs.archlinux.org/task/47301]]. The later revision is where I rebased the package. The notable differences would be the change from clang to gcc and the modified patch set and configure options. As one found there were already users stumbling across the conflict ultimately caused by building this in a dirty environment with qtwebkit it seemed prudent not to update the pkgrel until all the issues were resolved. It is unlikely this change was caused by swapping the compiler; however, it may be worth testing this point as it required a patch that wasn't in the binary release or lisu_ml's update. The configure options are probably one place to look and the patch sets another. The key patches appear in the later commit and are entirely green if you want to review the code: improve-cups-support.patch, moc-boost-workaround.patch, kde4-settings.patch, glib-honor-ExcludeSocketNotifiers-flag.diff, l-qclipboard_fix_recursive.patch, l-qclipboard_delay.patch

PhotonX commented on 2017-03-03 16:31 (UTC) (edited on 2017-03-03 16:32 (UTC) by PhotonX)

So the revision I linked previously works fine. Seems like this later commit, which is basically a complete overwrite, introduces the problem: https://aur.archlinux.org/cgit/aur.git/commit/?h=lib32-qt4&id=bef4f7fb2f5bbbeb5da6959c5757cd108db51996 It says, this revision is based on the package from extra/ but the package from extra/ actually worked fine, as far as I understand. What exactly changed between the old package from extra/ and the current package in the AUR and archlinuxgr/?

PhotonX commented on 2017-03-03 15:06 (UTC)

Ok, seems like my idea was wrong, the symlink didn't help. I will try to build this revision and see if it still works there: https://aur.archlinux.org/cgit/aur.git/tree/?h=lib32-qt4&id=77e07c49a2e24c4d64fa1b25fb54c123a7367136 Here the folder name is already changed but other (greater) changes are not yet made.

ranger commented on 2017-03-03 13:45 (UTC)

To check if the problem is the move form /usr/lib32/qt/ to /usr/lib32/qt4/, you can install -8 and make a symlink

PhotonX commented on 2017-03-03 13:41 (UTC) (edited on 2017-03-03 13:42 (UTC) by PhotonX)

Tsmuxer shows the same behaviour as Skype. Sure, so far I just downgraded to -7, but I think, this is not a good solution on the long term. :) I think, journalctl and dmseg don't show userspace apps' output, are they? Also, I cannot see the missing linked libraries in Skype and Tsmuxer using ldd, because both are statically linked. Maybe this is the problem? Maybe we can find the cause of the problem by looking at what has been changed between -7 and -8? As far as I can see the relevant change is that the directories in the configure call have been changed from subfolders of /usr/lib32/qt/ to subfolders of /usr/lib32/qt4/ Is this necessary to avoid collisions with qt5? If not, the best solution would be to roll back this change, imo. If this is impossible, then it would be necessary to tell Skype and other apps where to search for the libs (because the cannot find them in /usr/lib32/qt4/ obviously) somehow, but I don't know how...

WoefulDerelict commented on 2017-03-03 13:03 (UTC) (edited on 2017-03-03 13:10 (UTC) by WoefulDerelict)

PhotonX: If you're interested in chasing the issue the next step would be to consult the various logs for pertinent errors, as there likely should be some, after which one could attack skype with strace for more information. journalctl and/or dmesg should contain some information as to why the theme isn't being rendered correctly. Likely it will complain that it can't find or load some resource. Should that prove fruitless strace will likely catch it. If you aren't familiar with the tools you can submit the output for the community to sift through. The output of these tools is very verbose and not limited to just errors with skype. If you'd just like Skype to work properly the easy solution would be to roll back to the binary release of -7 from the ALA which was working and should still work. Post Scriptum: The 'Required by' section on this page contains a list of software that depends upon lib32-qt4. Last I looked there were 42 packages listed there.

PhotonX commented on 2017-03-03 13:00 (UTC)

VLC doesn't need 32 bit libraries, does it? And I don't know any 32 bit QT apps besides of Skype...

ranger commented on 2017-03-03 12:02 (UTC)

PhotonX, have you tried any other Qt4 apps (eg vlc)? Is the problem only with the 32 lib dependency?

PhotonX commented on 2017-03-03 08:46 (UTC) (edited on 2017-03-03 08:47 (UTC) by PhotonX)

Unfortunately, rebuilding lib32-qt4, lib32-gtk-engine-murrine and skype from source/AUR didn't solve the problem... What else can I do?

PhotonX commented on 2017-03-03 07:30 (UTC)

I tried rebuilding lib32-gtk-engine-murrine, but unfortunately nothing changed. What would be the next step? Try to build lib32-qt from source myself? I started the building process, will report back if it makes any difference. Thanks for your support so far! :)

WoefulDerelict commented on 2017-03-02 20:40 (UTC) (edited on 2017-03-02 21:00 (UTC) by WoefulDerelict)

PhotonX: QT4 no longer integrating with GTK themes is a bug. I'm not certain if changes made to the PKGBUILD or the build environment of the binary package you're using are responsible for the change in behaviour. Are you restarting the host environment after you update? Have you tried building this package and Skype yourself? Have you rebuilt any downline dependencies that may be affected by the update to address [FS#47301 [https://bugs.archlinux.org/task/47301]] which is the primary change in -8? As the article you linked clearly states some of these GTK themes require special engines. If you're using a 32-bit GTK engine like Murrine or Pixmap from the AUR it may be necessary to rebuild it for proper lib32-qt4 integration. It is also possible that FS#47301 had not been addressed because of some oddities with the way things in the 32-bit realm handled this. One will need quite a bit more information before it is possible to make a determination on this issue.

PhotonX commented on 2017-03-02 08:19 (UTC) (edited on 2017-03-02 08:25 (UTC) by PhotonX)

@ranger: Unfortunately, no change. I can achieve what I see in your screenshot, but this is not how it should be. You have the Cleanlooks theme running in Skype, which is of course better than the Windows 95 like theme but it is still not what it used to be before the update... edit: This is the difference I mean: http://www.webupd8.org/2014/03/fix-skype-not-using-desktop-gtk-theme.html Before: Cleanlooks, after: Proper GTK2 integration.

ranger commented on 2017-03-01 22:07 (UTC)

@PhotonX it's weird, I also have "use desktop settings" option selected and I use a gtk DE (cinnamon) I just uploaded a rebuild of skype, do you mind trying it? same repo

PhotonX commented on 2017-03-01 21:47 (UTC) (edited on 2017-03-01 21:48 (UTC) by PhotonX)

Thanks for the quick reply, guys! Before the update it looked like this (the variant "Use desktop settings" is selected in the "Style" settings): http://imgur.com/8SJe0uX Now it looks like this: http://imgur.com/ipZLvJo I can make it look the way it looks on you screenshot, @ranger, by selecting "Cleanlooks" in the "Style" settings, but this is still worse than what it was before the update, where it really integrated with the GTK2 theme being used (see my first screenshot).

ranger commented on 2017-03-01 20:56 (UTC) (edited on 2017-03-01 21:39 (UTC) by ranger)

which version of skype are you using? I use the latest stable and my skype looks like that http://imgbox.com/oLwPXqxr

WoefulDerelict commented on 2017-03-01 20:43 (UTC)

PhotonX: Yes, to the best of my knowledge ranger used the current version of the PKGBUILD here to build the binary at [archlinuxgr]. There are changes in the locations of some files between -7 and -8 that could be affecting dowstream applications. One would suggest rebuilding the Skype package after updating to see if that has any effect. This isn't something I can test or reproduce.

ranger commented on 2017-03-01 20:36 (UTC)

@PhotonX no problem with skype here

PhotonX commented on 2017-03-01 20:29 (UTC)

Is this PKGBUILD the base of the binary package in archlinuxgr/? If so: After the update to -8 (in archlinuxgr/), Skype falls back to a pre-2000 looking ugly theme. Downgrading to -7 solves the problem. Any thoughts?

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

WoefulDerelict commented on 2017-02-25 15:33 (UTC)

tc1384: It is probably much easier to use mesa to provide libgl instead of nvidia inside a container. If one recalls correctly you'll have to enable [Multilib] inside the container before attempting to fetch the lib32- dependencies. Obviously this process eats a sizeable chunk of disk space for the container.

ranger commented on 2017-02-25 15:05 (UTC)

denixx, I uploaded a package but my comment is lost somewhere near the bottom :p you can find the package here [archlinuxgr] SigLevel = PackageOptional Server = http://archlinuxgr.tiven.org/archlinux/$arch

denixx commented on 2017-02-25 14:53 (UTC)

Eh. This package is kind of time waster. Can it be precompiled to binaries? It builds a couple of hours. :)

tc1384 commented on 2017-02-25 08:35 (UTC)

I tried building in a clean chroot but have been unable to resolve lib32-nvidia-libgl dependencies.

WoefulDerelict commented on 2017-02-24 15:58 (UTC)

tc1384: Have you tried building the package in a clean chroot on either system?

mozo commented on 2017-02-23 21:36 (UTC)

I also get the token error. I hope this will be fixed for I can't manage with the compilinng in a clean chroot. My CPU is Intel 3770 Ivy Bridge with 16GB RAM. The installation is on a SSD. I use RAM to compile. I don't know how to check CPU firmware. http://pastebin.com/MqHQyc8g

tc1384 commented on 2017-02-23 19:34 (UTC) (edited on 2017-02-23 19:39 (UTC) by tc1384)

> tc1384: This makes it seem a great deal more like a race condition unless you installed some new packages between the two builds. Were the builds hosted in /tmp, on an SSD or HDD? builds were hosted on HDD. Also 57 new packages were install between builds. [2017-02-17 11:31] [ALPM] upgraded lie320qt4 (4.8.7-7 -> 4.8.7-8)

WoefulDerelict commented on 2017-02-23 17:58 (UTC)

tc1384: This makes it seem a great deal more like a race condition unless you installed some new packages between the two builds. Were the builds hosted in /tmp, on an SSD or HDD? kvasthval: Doesn't seem like you ran out of space. You're encountering the same error many other users are and not all of them were building in a limited tmpfs. I suspect it is a race condition in the build system. Not sure if the media type the source and output are hosted on has an effect on this. I've been testing on spindle media and in tmpfs/RAM with no difference/failure.

WoefulDerelict commented on 2017-02-23 17:50 (UTC)

snack: It is highly unlikely there is a missing dependency in one of the arrays as multiple users have built this successfully in a clean chroot. lib32-dbus is a dependency of this, including dbus, lib32-systemd, and systemd as dependencies which likely provide headers used during build. One suspects your issue is the result of some other package influencing the environment and confusing the configure script. Building this in a clean chroot will likely resolve the issue.

zoutiyx commented on 2017-02-23 16:26 (UTC)

Errors trying to build this package on my system: compiling openpagesswitcher.cpp openpagesswitcher.cpp: In member function ‘virtual bool OpenPagesSwitcher::eventFilter(QObject*, QEvent*)’: openpagesswitcher.cpp:157:61: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] else if (key == Qt::Key_Tab && (ke->modifiers() == modifier)) ~~~~~~~~~~~~~~~~^~~~~~~~~~~ compiling helpviewer_qwv.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) ^~~~ make[4]: *** [Makefile:14143: .obj/release-shared/helpviewer_qwv.o] Error 1 make[4]: Leaving directory '/tmp/yaourt-tmp-zoutiyx/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]: Leaving directory '/tmp/yaourt-tmp-zoutiyx/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]: Leaving directory '/tmp/yaourt-tmp-zoutiyx/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]: Leaving directory '/tmp/yaourt-tmp-zoutiyx/aur-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(). Aborting...

esh commented on 2017-02-23 14:26 (UTC) (edited on 2017-02-23 14:39 (UTC) by esh)

It fails to build for me on my laptop: - Intel Core i7-4700MQ (intel-ucode 20161104 loaded) and 16GB RAM - GCC is 6.3.1/20170109 (multilib/gcc-multilib 6.3.1-1) - Kernel is version 4.7.10 with the CK5 patchset and BFQ I/O scheduler. Kernel config is based on linux-ck, but with march=native, 1000 Hz constant tickrate (i.e. non-tickless) and cpufreq disabled - LibGL provider is multilib/lib32-nvidia-libgl 378.13-1 - Building from /tmp which is mounted on tmpfs with size = 50% of RAM (i.e. the default) - "pacman -Syu" has been performed prior to the build - Freetype is vanilla (extra/freetype2 2.7.1-1) - The only resource-hungry process is a virtual Win7 running idle on KVM with 4GB RAM (no ballooning) - Default shell is fish, however makepkg has been started from /bin/sh Full makepkg output: https://fjerhammer.dk/lib32-qt4.out (plain text, 24MB) / https://fjerhammer.dk/lib32-qt4.out.gz (gzipped, 483KB) (too large for pastebin/pasted) Relevant variables from makepkg.conf: CARCH="x86_64" CHOST="x86_64-pc-linux-gnu" CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=native -O2 -pipe -fstack-protector-strong" CXXFLAGS="-march=native -O2 -pipe -fstack-protector-strong" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" MAKEFLAGS="-j8" OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !optipng !upx !debug) I guess there is a chance that the system is silently running out of memory. I will try to build it from a non-volatile filesystem as soon as I find the time.

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

ZeroBit commented on 2017-02-22 12:08 (UTC)

@WoefulDerelict Please, let me know when you downloaded and I will delete this file allout.tar.gz

ZeroBit commented on 2017-02-22 11:45 (UTC)

Sorry I could not upload logs to pasterbin. I put it here https://dl.dropboxusercontent.com/u/932514/temp/allout.tar.gz

devourerOfBits80 commented on 2017-02-22 07:26 (UTC)

@ranger gave us the best solution for this issue. Thank you very much. You are great man! :-) @WoefulDerelict Unfortunately... I have not read this page before my third attemp to build this package (collection of resources). In the future I will try to look into AUR much earlier, to avoid simmilar issues. Sorry. :-)

mwz commented on 2017-02-21 22:10 (UTC)

make[1]: *** No rule to make target 'util/qabstractsystemtrayiconsys.cpp', needed by '.obj/release-shared/qabstractsystemtrayiconsys.o'. Stop. make[1]: Leaving directory '~/.cache/pacaur/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/gui' make: *** [Makefile:423: sub-gui-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: failed to build lib32-qt4 package(s)

WoefulDerelict commented on 2017-02-21 21:12 (UTC)

ZeroBit: Preferably the entire output of makepkg hosted on a paste site. See the URLs in posts made by meepzh, plebian and billypilgrim.

ZeroBit commented on 2017-02-21 20:02 (UTC)

@WoefulDerelict Can you provide the list of command the output of which you are interested of?

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

billypilgrim: The current most likely suspect is a race condition in QT4's build system. Have you tried building this in a clean chroot to eliminate the possibility this is the result of some unexpected interaction with some package installed on your system?

kabbalah commented on 2017-02-21 18:49 (UTC)

Thank you install skype and aur low one time the lib32-qt4 there was no longer need to compile

billypilgrim commented on 2017-02-21 18:49 (UTC)

I tried building it outside of /tmp but it failed. This time it was with the same error as I had the first time, which makes me think building in /tmp was a secondary reason why it fails. Log is here: http://ice9.ddns.net/build_notmp.out

WoefulDerelict commented on 2017-02-21 18:44 (UTC) (edited on 2017-02-21 18:48 (UTC) by WoefulDerelict)

ranger: That is understandable. Your input is appreciated. kabbalah: The error proper is further back in the build output and I'd wager it looks something like this: helpviewer_qwv.cpp:161:1: error: expected class-name before ‘{’ token

ranger commented on 2017-02-21 18:43 (UTC) (edited on 2017-02-21 18:43 (UTC) by ranger)

I have limited space in my main pc, that's why I use /tmp. I will try tomorrow to unmount /tmp and build again.

kabbalah commented on 2017-02-21 18:42 (UTC)

This is error in compile lib32-qt4.: make[4]: *** [Makefile:14143: .obj/release-shared/helpviewer_qwv.o] Error 1 make[4]: se sale del directorio '/tmp/yaourt-tmp-julio/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]: se sale del directorio '/tmp/yaourt-tmp-julio/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]: se sale del directorio '/tmp/yaourt-tmp-julio/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]: se sale del directorio '/tmp/yaourt-tmp-julio/aur-lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/tools' make: *** [Makefile:891: sub-tools-make_default-ordered] Error 2 ==> ERROR: Se produjo un fallo en build(). Cancelando… ==> ERROR: Makepkg no ha podido compilar lib32-qt4.

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

ranger: Interesting. Thanks for the feedback. Have you tried building it on your main PC outside of /tmp? Unless it is running out of space I can't really imagine why that would effect the build as I've managed to do it here successfully with an i7-870 backed by 16 GB of RAM and inside a VM which was allocated 8 GB. The best suggestion I've gotten so far is that this is some kind of race condition in qt4's build system which is unfortunate as it is one of the harder things to reproduce reliably, find and fix. Thanks for uploading a binary as I'm sure this will come in handy for some folks.

ranger commented on 2017-02-21 18:19 (UTC)

I still can't build the package using my main pc (i7-3537U, ssd, 8GB RAM) but I managed to build it using my "old" laptop (pentium P6200, 4GB RM). I don't know why it fails. I have exactly the same makepkg.conf. similar setup and up to date systems. The main difference (except the hardware) is that the laptop doesn't use /tmp for building. If someone needs the latest version (-8), I uploaded it in the archlinuxgr repo [archlinuxgr] SigLevel = PackageOptional Server = http://archlinuxgr.tiven.org/archlinux/$arch

WoefulDerelict commented on 2017-02-21 17:54 (UTC)

kabbalah: You can find old binary releases of lib32-qt4 and many other packages in the Arch Linux Archive: https://archive.archlinux.org/packages/l/lib32-qt4/

kabbalah commented on 2017-02-21 17:41 (UTC)

I am installing skype from aur and I have problems with lib32-qt4, this throws an error when compiling, I found a lib32-qt4 at: http://ftp.vim.org/os/Linux/distr/manjaro/testing/multilib/x86_64 / I have not used it, I'm waiting to finish compiling the aur.

darkbasic commented on 2017-02-21 16:50 (UTC)

moc openpagesswitcher.h rcc assistant.qrc rcc assistant_images.qrc compiling helpenginewrapper.cpp compiling .moc/release-shared/moc_fontpanel.cpp compiling .moc/release-shared/moc_aboutdialog.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) ^~~~ 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 "/home/niko/.cache/pacaur/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 "/home/niko/.cache/pacaur/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 "/home/niko/.cache/pacaur/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 "/home/niko/.cache/pacaur/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/tools" make: *** [Makefile:891: sub-tools-make_default-ordered] Error 2 ==> ERRORE: Si è verificato un errore in build(). L'operazione sta per essere interrotta... :: failed to build lib32-qt4 package(s)

WoefulDerelict commented on 2017-02-21 16:24 (UTC) (edited on 2017-02-21 16:41 (UTC) by WoefulDerelict)

One is still quite unable to reproduce this and I now fail to recall the number of time I've downloaded, verified and built this in various conditions attempting to do so. After calling in some support from the #ArchLinux community on FreeNode and having little luck reproducing the error the most logical cause remains some form of race condition in the qt4 build system. The only other likely candidate is an unexpected interaction with something on the local system. The former is not only hard to diagnose it is extremely difficult to locate and mend. As this is legacy software getting assistance from upstream is bound to be slow. The latter condition is easier to eliminate. When building and testing packages please remember the following. 1) AUR helpers are not supported as they frequently interact with builds causing unpredictable errors. Please download and extract the snapshot archive into a clean working directory or clone this repository via git before using makepkg to build it. 2) Do not build in /tmp. /tmp is tmpfs and can run out of space with large builds or updates causing unexpected breakage. 3) Build packages in a clean chroot to avoid conflicts with other installed software. (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot) meepzh: I'm glad you were able to successfully build this. Thanks for stopping by to provide your feedback. plebian: Thanks for the information. Did you use pacaur for the whole process? Your build is having a sad at a different location than the majority of failures reported here. ZeroBit: Thanks for the input. Makes things almost seem predictable till someone pops back with a different failure. Tomek80Bytom: This is not a package, it is a collection of resources to build a package. QT4 is a sizeable library and takes quite a while to build. You could have saved yourself the trouble of rebuilding by reading the comments here as the issue you're experiencing has already been reported and is under investigation.

meepzh commented on 2017-02-21 15:18 (UTC) (edited on 2017-02-21 17:03 (UTC) by meepzh)

I was having issues earlier. Then I cleared the pacaur cache at ~/.cache/pacaur/lib32-qt4 and it built successfully. CPU Info and Build Log: https://gist.github.com/meepzh/632a7661f55599d6d0089c979b0c4aa5 I'm running stock 4.9.9-1-ARCH x86_64 on Intel i7 4800MQ with 16GB RAM. Best of luck resolving the issue!

devourerOfBits80 commented on 2017-02-21 11:20 (UTC)

This package is really very terrible. One hour of compilation and I have got error. :-( I tried three times. openpagesswitcher.cpp: In member function ‘virtual bool OpenPagesSwitcher::eventFilter(QObject*, QEvent*)’: openpagesswitcher.cpp:157:61: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] else if (key == Qt::Key_Tab && (ke->modifiers() == modifier)) ~~~~~~~~~~~~~~~~^~~~~~~~~~~ compiling helpviewer_qwv.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)

ZeroBit commented on 2017-02-21 09:51 (UTC) (edited on 2017-02-21 09:54 (UTC) by ZeroBit)

I have the same problem on 2 computers: 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]: Leaving 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]: Leaving 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]: Leaving 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]: Leaving 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 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build lib32-qt4. ==> Restart building lib32-qt4 ? [y/N]

plebian commented on 2017-02-21 09:36 (UTC) (edited on 2017-02-21 09:36 (UTC) by plebian)

@WoefulDerelict Makelog: https://gist.github.com/MartijnDevNull/0fca281f31efa88cc77925cf266c8103 CPU: https://gist.github.com/MartijnDevNull/bbdfcbbb549f31938f3474e9e41ffe13 Install: Antergos x86_64 Linux 4.9.9-1-ARCH Everything else is stock and up to date

WoefulDerelict commented on 2017-02-21 00:46 (UTC)

vita_cell: Could you try building this with makepkg outside of tmpfs instead of with yaourt? You'll forgive me; however, I'm not fluent in Spanish and terminal output is very difficult to translate and parse. Not sure why that is happening but I can't reproduce it. My only guess it something funny in your system's i/o and yaourt + tmpfs

WoefulDerelict commented on 2017-02-21 00:30 (UTC) (edited on 2017-02-27 18:33 (UTC) by WoefulDerelict)

If your build fails with the following [error: expected class-name before ‘{’ token] when compiling helpviewer_qwv.cpp at 161:1 please revert back to basic package building procedure: Do NOT use an AUR helper. Use makepkg under a clean chroot. The wiki [https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot https://wiki.archlinux.org/index.php/Arch_User_Repository] as well as the community are available for support if you are unfamiliar with the process. I can be found in the #ArchLinux and #ArchLinux-AUR channels along with many other helpful community members on FreeNode [https://wiki.archlinux.org/index.php/IRC_channel]. If you aren't able to build this and need a functioning copy you can find old binary releases of lib32-qt4 and many other packages in the Arch Linux Archive: https://archive.archlinux.org/packages/l/lib32-qt4/ Thanks to all the users who have submitted output from their builds and a special thanks to mattlyons for smashing through the test suite with a Skylake and submitting the results to me via e-mail. I'm still sifting through the data to see if I can't locate the exact cause; however, I've narrowed it down to two more distinct avenues. The first is that some package is disrupting the build by altering the behaviour of the tools resulting in garbled output: likely at some macro expansion. The second is that there is a race condition somewhere in the QT 4.8.7 build system leading to improperly generated output. Should this turn out to be a race condition in the QT 4.8.7 build system it may take some time to resolve. I'll be hoping to include the QT Project in the hunt for heisenbergs; however, this is legacy Trolltech/Nokia/Digia stuff so I'm not sure how much help they will be. I’m presently conducting tests under a /new/ Arch Linux base installation on an Intel Haswell i7 from the latest ISO. It is currently suspected that the build errors many users are experiencing result from some race condition in the QT4 build system. One has spotted discussion of a similar issue on an entirely different distribution that supports this suspicion here: http://blfs-dev.linuxfromscratch.narkive.com/d2pzKCq9/kde4 Unfortunately these are exceptionally difficult to reproduce and diagnose. If users could provide me with additional information when reporting issues it would greatly help me address the issue you’re experiencing. Specifically your CPU (please include the manufacturer and model), the amount of RAM, media type (SSD/HDD) and some details about your installation. I’ll need to know if you’re running Arch Linux proper or a spin, if you’ve made any changes to makepkg.conf, when your last sync was, which package is providing lib32-libgl, the specific command you used to initiate the build and if it was run in a clean chroot. If you can provide me with the entire output of the build process it is much more helpful than a vague snippit out of context: those often tell me nothing. I’ve only ever seen the processor generation noticeably impact specific build tests of cryptographic libraries but I’d like to eliminate the variable so please include more than just the manufacturer and class, id est: Intel i7-880, Intel i7-4790, Intel i7-Nehalem, Intel i5-Skylake or AMD FX-9590 vs Intel i7. It is also helpful to know if the firmware and processor microcode are up to date and/or if the processor microcode is being updated by the system at boot. In the unlikely event I/O latency is having some bearing on the output it would help me to know if the build (source and output) were hosted in RAM, on an SSD or a HDD employing spindle and VCA.

vita_cell commented on 2017-02-21 00:14 (UTC)

Error :( http://dpaste.com/15BT2K6

WoefulDerelict commented on 2017-02-21 00:10 (UTC)

n0bs: I definitely need more output to debug that. lib32-dbus is a dependency and should already be on your system for makepkg to even proceed to build(). Not really sure why it isn't finding it on your system and it is bailing out.

WoefulDerelict commented on 2017-02-21 00:07 (UTC)

billypilgrim: I don't recall there being a pkgrel 6 out here in the AUR. It was dropped at pkgrel 7 and there is still a binary package for 4.8.7-7 in the Arch Linux archive. I had noticed some builds in temp so I'd tested against this locally and it didn't result in a failure. This is large but only takes up about 2 GB. With 8 GB of ram tmpfs is limited to 4GB of space in a default Arch Linux deployment which was still more than enough space for it to succeed in my VM test environment. Were this causing the issue I'd have expected to see something in the output about there being no space left on a device.

n0bs commented on 2017-02-20 23:44 (UTC)

I'm getting the following error with both pacaur and manually downloading the snapshot and running makepkg: `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. ==> ERROR: A failure occurred in build(). Aborting...`

ranger commented on 2017-02-20 22:12 (UTC)

billypilgrim, I also build in the /tmp. Maybe this is the problem?

billypilgrim commented on 2017-02-20 22:10 (UTC)

And yes it seems to fail at a different point every time I try to build it. Which is weird....

billypilgrim commented on 2017-02-20 22:09 (UTC)

I'm also on an Intel i7, 11GB RAM, pure arch, only the multilib repository, using normal kernel. I'm using bash. I haven't changed anything to do with tmpfs, although I have set my packages to be made in /tmp. I last synced my machine yesterday -- I was fully up to date before I tried making the package. I previously had pkgver -6 from the AUR working, but didn't try making -7. My makepkg.conf only has a couple of tweaks, but here it is in case it helps: http://ice9.ddns.net/makepkg.conf

WoefulDerelict commented on 2017-02-20 15:29 (UTC)

ranger: Thanks for the info. I'm constructing a test based on the info to see if I can reproduce this error under a suspected condition. dkaylor: I agree that using the pkgrel to differentiate the revisions would make it easy to refer to a specific set of changes when reporting an issue and help avoid some confusion; however, the AUR is backed by git and it is just as easy to refer to changes by their commit/fingerprint.

ranger commented on 2017-02-20 12:35 (UTC)

I have the same problem with billypilgrim. Fails with exactly the same error. intel i7, 8GB RAM, pure arch, no testing repo, system up to date, using lts kernel I was able to build -7 a few days ago...

dkaylor commented on 2017-02-20 10:29 (UTC)

@WoefulDerelict "makepkg -c != makepkg -C While the former cleans up after the the package has been make the later cleans up existing $srcdir" I understand the difference just fine, thanks. I know how to read a man page. As I said, I had no existing src or pkg directories; I had no existing anything, it was a new build. I get your points about not bumping up the pkgrelease. It confuses things however, because those of us that can't get a successful build have to reference "the old -8", vs. "your new -8" to make the distinction.

WoefulDerelict commented on 2017-02-19 23:54 (UTC)

billypilgrim: Thanks very much for providing me with the complete output. This will probably take me a tick to comb through as nothing is immediately jumping out. The build appears to have failed for you at a different point with each release. In the current release this appears to be when attempting to compile helpviewer_qwv.cpp which happens to be a common sticking point with other users. I apologize as this might start to feel a bit like an interrogation; however, the more I narrow things down the closer one becomes to rooting out the issue and a solution. Could you provide me with some details about your system? Specifically I'm interested in some minimal hardware specs (what CPU you have, how much memory is in your system) and a few key items about your configuration. Are you running Arch Linux proper or a spin? Are you using any of the testing or foreign repositories? When was the last time you synced your system with the repositories? Did you alter the tmpfs settings? Have you changed makepkg.conf and if so would you mind sharing it? Are you using bash or another shell? Am I correct in understanding you have not been able to successfully build this using any revision of the PKGBUILD posted here?

billypilgrim commented on 2017-02-19 21:14 (UTC)

Hi. Tried rebuilding with make -j1 and got the same result. The full build output is available here: http://ice9.ddns.net/build_j1.out

WoefulDerelict commented on 2017-02-19 18:37 (UTC) (edited on 2017-02-19 18:38 (UTC) by WoefulDerelict)

Yamakaky: One has already downloaded and re-verified the source many times while attempting to reproduce the number of issues here. Still no repro of this issue on my machines... or any of the other users boxxen.

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

Same checksum issue, while downloading multiple times. Could you try to re-dl the files? Maybe they changed the file but kept the file name.

WoefulDerelict commented on 2017-02-19 18:20 (UTC)

yochaigal: Sadly that output snippit tels me verry little about what happened or how to fix it. The make command is the last line of build() just before the closing }. Instead of 'make' it should read 'make -j 1'. The build area needs to be clean (makepkg -C) and it should preferably be performed within a clean chroot.

yochaigal commented on 2017-02-19 17:53 (UTC)

Building with makepkg fails with: make[4]: *** [Makefile:14146: .obj/release-shared/helpviewer_qwv.o] Error 1 make[4]: Leaving directory '/home/yochai/.cache/pacaur/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/yochai/.cache/pacaur/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/yochai/.cache/pacaur/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/yochai/.cache/pacaur/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(). Aborting... Adding -j 1 to the make command in the build() function doesn't make a difference (if I'm doing it right).

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

aunali1 commented on 2017-02-18 19:53 (UTC)

Build still fails for me :( moc openpagesmanager.h 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) ^~~~ moc openpagesswitcher.h rcc assistant.qrc rcc assistant_images.qrc compiling .moc/release-shared/moc_fontpanel.cpp compiling helpenginewrapper.cpp compiling .moc/release-shared/moc_aboutdialog.cpp compiling .moc/release-shared/moc_bookmarkdialog.cpp openpagesswitcher.cpp: In member function ‘virtual bool OpenPagesSwitcher::eventFilter(QObject*, QEvent*)’: openpagesswitcher.cpp:157:61: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] else if (key == Qt::Key_Tab && (ke->modifiers() == modifier)) ~~~~~~~~~~~~~~~~^~~~~~~~~~~ compiling .moc/release-shared/moc_bookmarkfiltermodel.cpp make[4]: *** [Makefile:14146: .obj/release-shared/helpviewer_qwv.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory '/tmp/yaourt-tmp-aunali/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]: Leaving directory '/tmp/yaourt-tmp-aunali/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]: Leaving directory '/tmp/yaourt-tmp-aunali/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]: Leaving directory '/tmp/yaourt-tmp-aunali/aur-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(). Aborting... ==> ERROR: Makepkg was unable to build lib32-qt4. ==> Restart building lib32-qt4 ? [y/N] ==> ---------------------------------- ==>

WoefulDerelict commented on 2017-02-18 19:36 (UTC)

I've rebased this on the PKGBUILD used for qt4 in [Extra]. Clang is not longer used to build this which will hopefully remedy build issues users were experiencing. Issues raised in [FS#47301 [https://bugs.archlinux.org/task/47301]] have been properly addressed.

lisu_ml commented on 2017-02-18 14:29 (UTC)

Sorry, but I have no time to take care of the package anymore.

billypilgrim commented on 2017-02-18 10:42 (UTC)

I'm getting a build error with the new version of the package: <inline asm>:2:10: note: instantiated into assembly here cmpxchgl %rbx,_ZZL12unifiedTimervE16this__StaticVar_(%rip) ^~~~~ 1 error generated. make[1]: *** [Makefile:7552: .obj/release-shared/qvariantanimation.o] Error 1 make[1]: *** Waiting for unfinished jobs.... 1 error generated. make[1]: *** [Makefile:7392: .obj/release-shared/qabstractanimation.o] Error 1 make[1]: Leaving directory '/tmp/makepkg/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/corelib' make: *** [Makefile:205: sub-corelib-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: failed to build lib32-qt4 package(s)

jmartl109 commented on 2017-02-17 18:51 (UTC)

I'm getting clang-3.9: error: unknown argument: '-fvar-tracking-assignments' make: *** [Makefile:257: project.o] Error 1

lisu_ml commented on 2017-02-17 14:09 (UTC)

@lightdot and @sl1pkn07: Both changes are part of the newest release. Could you please give it a try and let me know if both issues are gone now?

lightdot commented on 2017-02-14 20:46 (UTC)

> If you think expanding the depends will help build the package with other helpers, I can do it straight away. It would re-enable the package to be built by aura, if not also some others.

bakgwailo commented on 2017-02-14 01:40 (UTC)

@lisu_ml The error was in pacaur. Yaourt seems to work fine.

sl1pkn07 commented on 2017-02-13 23:47 (UTC)

any chance for fix this? https://bugs.archlinux.org/task/47301

lisu_ml commented on 2017-02-12 10:15 (UTC)

@biinari: Builds fine using yaourt. If you think expanding the depends will help build the package with other helpers, I can do it straight away.

biinari commented on 2017-02-12 03:44 (UTC)

Using bash expansion in the depends array makes aura (an aur helper) unable to update this package. As in: lib32-{fontconfig,sqlite,alsa-lib,glib2,dbus,openssl} It builds fine with makepkg but it might be worth considering writing the depends out in full. I don't know if other aur helpers are any better at handling bash expansion.

dkaylor commented on 2017-02-12 03:19 (UTC)

@lisu_ml: Thanks for adopting. I use this package as a dep for packettracer.

dkaylor commented on 2017-02-12 03:15 (UTC)

@bakqwailo: You need to answer yes to either "Assume -R" or "Apply anyway?" for the prepare() to complete. @billypilgrim: I had a similar failure when building using pacaur, so if you are using a helper, try it without one, worked for me.

lisu_ml commented on 2017-02-11 23:37 (UTC)

The package built for me without any issues.

lisu_ml commented on 2017-02-11 23:16 (UTC)

@gokcen: According to the last commit message, this package has been dropped from [multilib] repo. @billypilgrim: I'm building the package right now to see if there is any problem, but it is taking long time. I will report here if it worked or not for me. @bakgwailo: The prepare() works fine here, so I have no idea why it fails in your case. Are you sure you are not trying to re-apply the patches somehow?

bakgwailo commented on 2017-02-11 21:52 (UTC)

Doesn't build for me, either, fails applying patches: ==> Extracting sources... -> Extracting qt-everywhere-opensource-src-4.8.7.tar.gz with bsdtar ==> Starting prepare()... patching file examples/desktop/systray/window.cpp patching file examples/desktop/systray/window.h The next patch would create the file src/gui/util/qabstractsystemtrayiconsys.cpp, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored The next patch would create the file src/gui/util/qabstractsystemtrayiconsys_p.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored patching file src/gui/util/qsystemtrayicon.cpp patching file src/gui/util/qsystemtrayicon_p.h patching file src/gui/util/qsystemtrayicon_x11.cpp The next patch would create the file src/gui/util/qxembedsystemtrayicon_x11.cpp, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored The next patch would create the file src/gui/util/qxembedsystemtrayicon_x11_p.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored patching file src/gui/util/util.pri ==> ERROR: A failure occurred in prepare(). Aborting... :: failed to build lib32-qt4 package(s)

billypilgrim commented on 2017-02-11 18:58 (UTC)

The build is currently failing for me: make[1]: *** No rule to make target 'util/qabstractsystemtrayiconsys.cpp', needed by '.obj/release-shared/qabstractsystemtrayiconsys.o'. Stop. make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/tmp/makepkg/lib32-qt4/src/qt-everywhere-opensource-src-4.8.7/src/gui' make: *** [Makefile:422: sub-gui-make_default-ordered] Error 2 ==> ERROR: A failure occurred in build(). Aborting... :: failed to build lib32-qt4 package(s)

gokcen commented on 2017-02-10 09:11 (UTC)

What happened to the binary lib32-qt4 package?