Arch Linux

The Qt5 PKGBUILD is based on the Qt4 one.

At the moment I don't remember why it's there. The WebSVN log doesn't help because we renamed the package...I'll check svn later.
In the meantime, Pierre do you have some idea?

So, the reason is  FS#14854 . I'll see if this is still the case.

I wonder if any of the three lines are needed

sed -i "s|-O2|${CXXFLAGS}|" qtbase/mkspecs/common/{g++,gcc}-base.conf
sed -i "/^QMAKE_LFLAGS_RPATH/s| -Wl,-rpath,||g" qtbase/mkspecs/common/gcc-base-unix.conf
sed -i "/^QMAKE_LFLAGS\s/s|+=|+= ${LDFLAGS}|g" qtbase/mkspecs/common/gcc-base.conf

If they are needed for building Qt then maybe they should be set a different way so that they are only used for the build and are not in the mkspecs for any time one uses qmake.

The first line doesn't quite work as intended anymore be cause of this commit
https://qt.gitorious.org/qt/qtbase/commit/cd652500af18671e0d64b30d51c79a0c45b973a3
If the replacement is intended for the end user then maybe it should be for -03 too.

Second line is no more needed, just tested.

I dropped the first one because of that commit too.

Still wondering what to do with the third one.

I would leave it vanilla for people using qmake generally. As far as I can tell, the mkspecs aren't used for building qt as I can't see qmake invoked anywhere in the PKGBUILD. It may do it internally, however, so I don't know.

If you scrap it, it is possible to set manually, say when building packages that use qmake by
qmake "QMAKE_LFLAGS = $LDFLAGS"

cont.
actually probably what you would want is
qmake "QMAKE_CFLAGS = $CFLAGS" "QMAKE_CFLAGS_RELEASE =" "QMAKE_CXXFLAGS = $CXXFLAGS" "QMAKE_CXXFLAGS_RELEASE =" "QMAKE_LFLAGS = $LDFLAGS" "QMAKE_LFLAGS_RELEASE ="

So if you are going to leave line 3 in you should probably sed all of the above for consistency.
Also QMAKE_CFLAGS_DEBUG = $DEBUG_CFLAGS and QMAKE_CXXFLAGS = $DEBUG_CXXFLAGS too.

I just looked at cmake and you don't seem to add any of the makepkg.conf flags to the .cmake files so it's probably best to do the same with qmake.

Related:  FS#38819 

Redacted: TIL that abs can be different from trunk… recompiling again (sorry for outdated comment and energy waste)
I somehow managed to make false positive with trunk - binaries are still broken (qmake/libQt5PlatformSupport)

As for now i only managed to compile sane qt5-base (and only that) with https://gist.github.com/swiftgeek/38bcf0761876de66d12f , compilation breaks somewhere in qtwebkit
---
Next round of compiling brings updated sanity check:
compile&install qt5 from one user, compile qt5-wayland-git (only for sanity checking) from another user (that doesn't have access to files created by first one)
Some result:
Commenting lines 131-132 (`find` from package_qt5-base) makes qmake work

Some franken build proved that both 131-132 and line 54 have to be removed/commented out in order to provide working qt5-base
→ https://gist.github.com/swiftgeek/d3b7a415547d65c07675/revisions

Hopefully tomorrow morning i will get clean build with those changes

seds removed starting from qt5 5.4.0-2.

1. Why changing title to [qt4] only?
2. I have issues with clean build as compilation eats more resources without those lines
3. Exactly the same `find` also exists in 18 other package function (i guess svntogit has some lag, can't tell if that's fixed too).

1. Because as I said this is fixed with qt5-* 5.4.0-2
2. qt5 builds here, I just dropped the sed line nothing more. qt5-wayland-git builds too.
3. find usage is fine.

Please try to be more patient with testing, it's very easy to get false results (especially with qt5) and definitely try to not close issues before somebody has chance to test it.
Neither qt5-* 5.4.0-2 hit the repo yet nor even svngit updated, that's definitely way too early

I will definitely test that in VM once it does, as it takes way less time, resources and disk space than build of qt5

I didn't release -2 yet because I'm doing another try by setting our {C,LD}FLAGS used in makepkg.conf.
To be more precise, I'm trying right now:
sed -i -e "s|^\(QMAKE_CFLAGS_RELEASE.*\)|\1 ${CFLAGS}|" qtbase/mkspecs/common/gcc-base.conf
sed -i -e "s|^\(QMAKE_LFLAGS_RELEASE.*\)|\1 ${LDFLAGS}|" qtbase/mkspecs/common/g++-unix.conf

But as I said before, just removing every sed line fixed the qtwayland build that was broken since ages because of weird issues during linking phase.

I believe that archlinux do have a testing repository…
And what is the reasoning by doing that sed at all? Nobody else is doing that, so it looks more like ricing, that can cause issues very hard to diagnose. This seems to count as unnecessary patching

Sure, but there's no need to push -2 and then -3 after some hour. So please wait ;-)

It's important to use our FLAGS when building (otherwise why setting them in makepkg.conf?!). Fedora also do the same way.

@BaSh but sets those flags for anyone using qmake unless you revert them after the build.

You could change them in the makefiles like you do with other variables

# Fix paths
find "${QTDIR}" -name Makefile -exec sed -i "s|/usr/lib/qt/bin/qdoc|${QTDIR}/qtbase/bin/qdoc|g" {} +
.
.
.
find "${QTDIR}" -name Makefile -exec sed -i "s|.*CFLAGS.*|CFLAGS = ${CFALGS}|g" {} +
etc or something similar.

or possibly with configure passing your own mkspecs using -platform
or maybe with -device-option e.g.,
-device-option "QMAKE_CFLAGS = $CFLAGS" "QMAKE_CFLAGS_RELEASE =" "QMAKE_CXXFLAGS = $CXXFLAGS" "QMAKE_CXXFLAGS_RELEASE =" "QMAKE_LFLAGS = $LDFLAGS" "QMAKE_LFLAGS_RELEASE ="

Note: I haven't tried any of this so it may not work.

You can try making franken build - qt5-base should finish within 1h so you can just remove all other package functions and add "|| true" to make, so when you hit ^c makepkg carries on to packaging qt5-base ;)

Still, I think that setting sane *FLAGS in qmake is OK. Fedora does the same way too.
I'll ask in #qt-labs and #archlinux-dev for some opinion.

I pushed 5.4.0-2 packages in [extra] because at least  FS#38819  is fixed now.

As i said - testing is needed, as i still get negative results (not tested under vm nor even rebooted yet)
Incremental testing would remove need for me to recompile it for 6h with each change with possible OoM -.-

Please explain what you mean for "negative results".
Also, if you still have issues please file a new bug report since this was about QMAKE_LFLAGS_RPATH (which are now gone anyway, so *this* bug is fixed for Qt5).

Then please stop marking issues as "fixed" before it's tested at all -.- (  FS#38819  and probably many others by extrapolation from negative feelings)

Copying *.prl files from working builds makes qmake working again so binaries are good
So most possibly it's that find line that exists in every package function

Last thing about our *FLAGS usage, I did ask on IRC and:
Arch Linux devs thinks is OK to use our *FLAGS because this way our packages built using qmake are optimized.
Qt devs said ours are "sane defaults" *FLAGS and what we do makes sense because the entire system is built that way.

Please file a NEW bug report about your issue. Explains the steps so I get what is wrong.

NEW? This is 1 year old issue, please try not to hide it. I'm just happy that parched came along now with technical attempt rather than plain bruteforcing.  FS#43186  is one of ¿two narrowed down issues with qt5 PKGBUILD

And if you didn't notice previous comment contained information that prepare/build stage »seems« to be ok with those *FLAGS changes, even though *.prl are getting broken in package functions

And i can fully confirm that this part of  FS#38819  (part that produced invalid binaries) only after producing clean build that compiles qt5-wayland , branch 5.4.1 with no crazy hacks/patches/whatever.

If you would just wait for others to test changes (perhaps using testing repo), before forcing closure of issues we could just focus on bugs. Please.

Then let's start from scratch because I missed the point here.

If I got it right you are commenting here, but you are referring to the issue described in  FS#38819 ?
*This* issue ( FS#43186 ) is about QMAKE_LFLAGS_RPATH usage and then we went off topic.

You could call  FS#43186  a subbug of  FS#38819  (or duplicate). But  FS#43186  is so specific that i would either have to modify build files (in prepare) in order to see if it is indeed fixed or just fix whole  FS#38819  and have both fixed (or mix and match prl with binaries from past builds in case of other results).

To be clear how presumably working PKGBUILD should look like - https://gist.github.com/swiftgeek/2996746f925d9759fdc5/revisions
Franken build proves it works, clean build takes lots of resources and time.
If clean build works then this (  FS#43186  ) is proved to be fixed, while solution to  FS#38819  is clear (composed of  FS#43186  + gist above)

Your change to *FLAGS (fedora, missing comment above those lines will make it as hard as  FS#38819  to debug when it will stop working - you could probably count on fedora guys figuring it out sooner, with change showing up in their git log) seems to work (again clean build will test that) and i guess it will make compilation process easier on resources.

So i hope in 6-7h everything will be crystal clear
# IMHO parched is still right and method of setting *FLAGS should be changed in both arch and fedora as it introduces inconsistent behavior from toolchain
# But there is no known case of something getting broken from this - which will be extremely hard to pinpoint

OK, everything should be fixed with 5.4.0-3.

Hmm, I still don't like it :P

Isn't it Arch policy to leave packages vanilla when possible? By that I mean when someone is using qmake for a personal project not compilation of Qt. How qmake works now arbitrarily depends on what flags someone had set in makepkg.conf with Qt was compiled. I believe no package's functionality should depend on the persons who compiled its makepkg.conf.

If Qt's defaults aren't sane wouldn't it be better to try and get those changes upstream? If qmake is to be patched like this then so shouldn't cmake and all other build systems?

As the way it stands is kinda messy too, but technically not an issue.
CFLAGS = -pipe -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -Wall -W -D_REENTRANT -fPIE $(DEFINES)

I have created a mkspec that uses CFLAGS, CXXFLAGS, LDFLAGS which you can add to the package. This means one can simply do "qmake -spec linux-g++-flags" to use the environment flags. In the case of building qt itself, that would be the configure -platform option. Personally, I think this is the cleanest solution of the lot. Thoughts?