-
-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
qt5 5.7.0 #2087
qt5 5.7.0 #2087
Conversation
Thanks! You beat me to it this time! 😉 I was still in the process of building things locally and performing some tests. Anyway, the build is re-queued with sufficient buffer before it times out. Let's what our build bot has to say about this new major release … I guess we'll know more in about three hours. ⌛ |
One of the builds (mavericks) has already failed. It failed on the |
First, let's wait until the other two builds finish before taking any action or jumping to any conclusions.
Unfortunately, this is not looking good. Our Mavericks box is frequently the fastest, but this was way too fast for a Qt build and given the other errors, it makes me think that—for reasons yet unknown to me—the whole QtWebEngine module wasn't built. This would be consistent with the observed build time.
Since you already have a working Qt 5.7.0 locally, can you try building |
When you make changes to the branch, please also remove these lines (currently 53–55) in |
|
I'm always hopeful Qt has made significant strides in build time reduction, but yeah, from over 2 hours to 50 minutes with those failures seems deeply suspicious. The generated Mavericks bottle is also only 46.78MB compared to 91.31MB for El Cap and 91.08MB for Yosemite. 91MB is about consistent with the bottles for recent Qt5 releases. |
Yeah, there's something going wrong with the web engine build on Mavericks. I checked the bottles myself, and the only missing files are related to QtWebEngine, QtWebEngineCore, QtWebEngineWidgets, and QtWebView. I'd like to see the output of the |
Hmm. While looking up to see if the Web Engine had any additional requirements on top of Qt itself, I found this: http://doc.qt.io/qt-5/qtwebengine-platform-notes.html#os-x It says that 10.9 (Mavericks) should be able to build the Web Engine, though the page does list some caveats that I'm not sure the build server meets. It says that it needs Xcode 5.1 or later, which seems like it might be a newer version than the one that came with Mavericks. Earlier on the page, it also mentions requiring "Bison, Flex" and "GPerf". From what I can tell, Mavericks (with the command-line tools installed) should have all of those, but I wonder if there was a version difference for one of those libraries between 10.9 and 10.10 that's causing the issue. |
Yes, there's something weird going on with the QtWebEngine build on Mavericks. This much is clear.
I re-scheduled the build on our machines and collected the configure logs. Have replaced the somewhat random temporary directory with
None of the stuff listed there sounds like it should create a problem on Mavericks.
Shouldn't be the issue. All our machines are updated to the latest Xcode still supported on that OS X release, i.e. for 10.9 this is Xcode 6.2 and the matching Command Line Tools (see |
I've scanned over the logs you provided and didn't find anything incredibly useful unfortunately. I was hoping that the configuration output specified what modules were being compiled, but it only names a few in that output. I'm worried the answer I'm looking for is from the output of the make command, but I don't personally want to scan through an hour of logs. Maybe doing something like "grep error" would reveal something. The weren't many differences in the configurations, but one difference did stand out. 10.10 and 10.11 differed from 10.9 with the support for c++1z and AVX512, but neither of those should be an issue. The other difference is that the 10.9 config had the "Using gold linker" option turned on. This had me really confused, as my research on the "gold linker" says that it only supports ELF formats. I don't know if this is a cause for the issues, but it's the only thing I see so far. |
The C++1z and AVX stuff is to be expected, as that's related to what the compiler supports and of course the slightly older Clang distributed with Xcode 6.2 doesn't support everything the one from Xcode 7.3.1 supports. The full build log might help, but it is a bit tricky to capture on our test bot because the test bot makes sure to automatically clean up after itself. Maybe that's something we need to improve so that the logs of a build can be more easily retrieved in case there is no obvious error or not in the last few lines that are printed on a failed build. (But here it doesn't fail, it just skips building one part of the library.) I agree that the “Using gold linker” stuff is really suspicious, as it doesn't make sense on OS X. To me this sounds like a bug that was introduced in the |
Well, adding the |
Yes, sadly no luck there. Thanks for trying and keep the ideas coming if they pop into your head. I'll try to diagnose this further in the coming days, but don't have the time to do that right now. |
Hi, I would like to inform that Qt 5.6.1 link is dead[0] at[1] as it has been replaced by new revision[2]. I know you are trying to fix problems with Qt 5.7 and will update formula for that but I guess for the time being, master should be fixed for not having that problem :) [0] https://download.qt.io/official_releases/qt/5.6/5.6.1/single/qt-everywhere-opensource-src-5.6.1.tar.xz PS: I have just shifted to Mac from my linux machine and Thanks to homebrew for rescuing me! |
@Ashish-Bansal Thank you for letting us know! I created #2350 to address this, but it will still take a few hours until this has passed CI, bottles have been built, and the PR can be merged. It's rather annoying when upstream decides to completely remove a previously published release from their download servers. |
@UniqMartin Thanks! And yes, I completely agree with that, they shouldn't really delete the previous revision from their servers. |
I tried to take a look at this, but I'm a bit clueless as well. I tried asking in the I also diffed the configure output between 10.9 and 10.11 - other than some failing checks, here's the difference: --- 01.configure-10.11 2016-06-30 09:29:48.596819069 +0200
+++ 01.configure-10.9 2016-06-30 09:29:48.610152403 +0200
@@ -1,17 +1,17 @@
Build options:
- Configuration .......... accessibility audio-backend avx avx2 avx512cd avx512er avx512f c++11 c++14 c++1z compile_examples concurrent corewlan cups doubleconversion freetype full-config getaddrinfo getifaddrs harfbuzz iconv ipv6ifname large-config largefile medium-config minimal-config nis no-pkg-config opengl pcre png poll_poll precompile_header qpa qpa qt_framework reduce_exports release securetransport shared small-config sse2 sse3 sse4_1 sse4_2 ssl ssse3 system-zlib
+ Configuration .......... accessibility audio-backend avx avx2 c++11 c++14 compile_examples concurrent corewlan cups doubleconversion freetype full-config getaddrinfo getifaddrs harfbuzz iconv ipv6ifname large-config largefile medium-config minimal-config nis no-pkg-config opengl pcre png poll_poll precompile_header qpa qpa qt_framework reduce_exports release securetransport shared small-config sse2 sse3 sse4_1 sse4_2 ssl ssse3 system-zlib use_gold_linker
Build parts ............ libs tools
Mode ................... release
Using sanitizer(s)...... none
- Using C++ standard ..... c++1z
- Using gold linker....... no
+ Using C++ standard ..... c++14
+ Using gold linker....... yes
Using new DTAGS ........ no
Using PCH .............. yes
Using LTCG ............. no
Target compiler supports:
SSE .................. SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
AVX .................. AVX AVX2
- AVX512 ............... AVX512F AVX512ER AVX512CD
+ AVX512 ............... <none>
Qt modules and options:
Qt D-Bus ............... no So nothing new to what you already mentioned above... |
FWIW, this change mentions it needs SDK 10.10_.3_ or later - I only can see it's using 10.10 from the build log, maybe with an older patch version? |
Seems like that's the culprit indeed - IRC logs:
|
I believe the formula scripts can be fairly complicated. It sounds to me like we may need to have a rule, such that building qt5 without a "no webengine" argument would be unsupported on 10.9. We might be able to get past that by manually replacing the bottle for 10.9 with the 10.10 version, but I don't know how easy it would be to do that... The other thing we could do is manually update the SDK version. I remember reading something about setting a custom SDK version in Xcode before. It may not be that easy with a build script (instead of an .xcodeproj file), but it might work (and save us the headache later). |
@The-Compiler Thanks for finding this and for investigating this further! This commit pretty much explains it all. So the bottom line is that the QtWebEngine module cannot be built with an SDK prior to 10.10.3, meaning this automatically excludes OS X 10.9 as the latest officially supported Xcode is 6.2. The saddening part is that this nontrivial change to the build requirements isn't documented anywhere (as far as I can see), neither in the documentation you pointed out nor the Qt 5.7.0 Change Files. Building on a newer machine (but with a deployment target of 10.9) and then using this is theoretically possible, but doesn't work with our CI setup. Modifying the Xcode that we use on our 10.9 CI is not an option (and not practical either), as that could create more trouble for other formulae and will only help with the bottles, but 10.9 users building from source (with Xcode 6.2) would still be left out. I'm currently seeing these options:
If I had to order these options by preference, that would be: 1, 3, 2. @DomT4 What are your thoughts on the situation and the options we have here? Any other options that I'm overlooking? |
ok, loads of information :) Can we get a quick tl;dr? From what I can see, Qt 5.7 is not in homebrew as QtWebEngine doesn't compile on older OS X versions. However, there's also a comment indicating that this is fixed in the 5.7 - branch, so it's a matter of backporting a couple of fixes? Or is is generally not supported by the Qt folks any more? (In which case I might be able to help by driving over to the Qt Adlershof office with a crate of beer ;)) |
@haraldF The "quick tl;dr" is that an ideological war is starting on how these sorts of projects should be distributed. As to the status of the PR, we're already tried 2 patches from the 5.7 branch, but are still experiencing compile errors. There has been some discussion about just dropping support for the versions of OS X that are failing, but that would involve editing a large number of formulas dependent on it. If you know of what other patches are needed to get this working, link them here, and I'd be willing to update the PR with them and let the bot take another attempt at it (if the project members are willing to let it run for long enough). |
Yes, @LRFLEW summarized it nicely. I think the simple/desirable solution is one of:
All other solutions require more work (and will probably result in some grief for the 10.9 folks) and also mean someone would need to step up and do this work. |
FYI: Looks like that requirement gets bumped to 10.10 again with Qt 5.8 as Chromium doesn't build anymore otherwise. |
Hmm, if that's true, then we may want to reconsider what option we take. @UniqMartin What's your thoughts? |
Since 10.9 is no longer a supported build environment for the QtWebEngine module (inherited from Chromium that it is built on top of) but we want to either ship a complete Qt will all of its modules and we want/have to continue to support from-source builds, I'm increasingly of the opinion that we should just bite the bullet and raise the minimum macOS requirement to 10.10. Though Alexandru Croitor has so far done a wonderful job of restoring compatibility with older build environments on macOS, this will always be a game of catching up and may very soon turn out to be impractical. And I fear it's always going to be an afterthought in the overall Qt release process, so future breakage seems likely. If @DomT4 and @MikeMcQuaid don't have strong feelings that we should pursue a different path, let's just raise the minimum macOS requirement and kill 10.9 support in |
To be fair, if I do end up fixing 10.9 compilation on Qt 5.8, and it is fixed for 5.7.1, the only catching up will have to be for patch releases of 5.8. And given that the Chromium version will not be updated anymore for the 5.8 patch releases of Qt, there is little chance something will break after the initial hurdle. And in Qt 5.9, 10.9 support will be officially dropped for all Qt modules. The patch that @The-Compiler mentioned (requiring 10.10) was committed because the 5.7 -> 5.8 merge was blocked by the 10.9 compilation issues. If I fix the 10.9 issues, I'll lower the requirements back to 10.9. |
I agree 100%. If/when our users complain we can point them to Qt to voice their complaints. |
Aye. It might be good to give Travis a heads-up given a decent chunk of our Qt5 usage is CI based and Travis' default CI is 10.9, but in principle I agree we're fighting a losing battle here. |
@DomT4 We probably owe Travis an email anyway to try and convince them to update their images to the split brew/core repos. |
Yeah. It'd be helpful to everyone if they upgrade some of their preinstalled formulae as well; at the moment a wad of people using Travis have had to add A general update & raising the default OS X image to at least 10.10 would be ideal on all sides, IMO. We can at least reassure them that once Homebrew is 1.0 the breaking changes to core code are going to be less frequent. |
Alternatively: we wait until 1.0 and then guarantee it. |
The build error would manifest as follows: ``` ... Making install in libparser clang -DHAVE_CONFIG_H -I. -I.. -I../libparser -I../libutil -I../libdb -I../libglibc -I../libutil -g -O2 -c -o parser.o parser.c clang -DHAVE_CONFIG_H -I. -I.. -I../libparser -I../libutil -I../libdb -I../libglibc -I../libutil -g -O2 -c -o C.o C.c clang -DHAVE_CONFIG_H -I. -I.. -I../libparser -I../libutil -I../libdb -I../libglibc -I../libutil -g -O2 -c -o Cpp.o Cpp.c make[1]: *** No rule to make target `asm_parse.c', needed by `asm_parse.o'. Stop. make: *** [install-recursive] Error 1 ``` The call `sh reconf.sh` does not fail even if bison fail. Enabling `set -x` in the script showed the following: ``` ... +'[' -f asm_parse.y ']' +bison -d -o asm_parse.c asm_parse.y asm_parse.y:76.14-19: syntax error, unexpected string, expecting = ... ``` global build deps ref: http://cvs.savannah.gnu.org/viewvc/global/global/libparser/HACKING?revision=1.4&view=markup gperf OSX refs: * Homebrew/legacy-homebrew#7794 (comment) * Homebrew/legacy-homebrew#11039 (comment) * Homebrew#2087 (comment)
The build error would manifest as follows: ``` ... Making install in libparser clang -DHAVE_CONFIG_H -I. -I.. -I../libparser -I../libutil -I../libdb -I../libglibc -I../libutil -g -O2 -c -o parser.o parser.c clang -DHAVE_CONFIG_H -I. -I.. -I../libparser -I../libutil -I../libdb -I../libglibc -I../libutil -g -O2 -c -o C.o C.c clang -DHAVE_CONFIG_H -I. -I.. -I../libparser -I../libutil -I../libdb -I../libglibc -I../libutil -g -O2 -c -o Cpp.o Cpp.c make[1]: *** No rule to make target `asm_parse.c', needed by `asm_parse.o'. Stop. make: *** [install-recursive] Error 1 ``` The call `sh reconf.sh` does not fail even if bison fail. Enabling `set -x` in the script showed the following: ``` ... +'[' -f asm_parse.y ']' +bison -d -o asm_parse.c asm_parse.y asm_parse.y:76.14-19: syntax error, unexpected string, expecting = ... ``` global build deps ref: http://cvs.savannah.gnu.org/viewvc/global/global/libparser/HACKING?revision=1.4&view=markup gperf OSX refs: * Homebrew/legacy-homebrew#7794 (comment) * Homebrew/legacy-homebrew#11039 (comment) * #2087 (comment)
@LRFLEW Any news on this? Thanks! |
Will wait for Qt 5.7.1. |
... or ship a snapshot? |
qt5-qtconnectivity seems to be fixed https://trac.macports.org/ticket/52203 |
If we can get something that compiles on our now three supported platforms (10.10 - 10.12) I'm happy to include it. |
brew install <formula>
(where<formula>
is the name of the formula you're submitting)?brew audit --strict --online <formula>
(after doingbrew install <formula>
)?I know that major version changes to qt5 have been more involved in the past, such as Homebrew/legacy-homebrew#50234. However, I saw that there was no open PR for this, so I went ahead and made one.