qt5-mac-devel build fails on OS X 10.6.8 #1
Comments
|
On Tuesday September 15 2015 17:44:27 maximumspatium wrote: Hello Max,
Thank you! It's good to know that I'm not doing this only for myself!
Can you try the latest commit? You're right that I don't always test new patches with the legacy Qt version, my bad. I've done so now, but only up to the patching step. I haven't checked whether the font weight improvement patch introduces regressions (compile-time or otherwise), ditto for the qFatal patch.
Yes and no: it doesn't use the compilers from Xcode, but I reckon you still need to have Xcode installed.
Note that if you just want to have a recent Qt version regardless of how (or maybe preferably NOT through MacPorts), there is also a trick. Qt 5.4 doesn't build on OS X 10.6, but that's all: it will work just fine and all software I tried built just fine with it. Have you considered setting up a 10.6 ("Server") VM in which you can then run that older software? I've found it works fine even with my PPC versions of Adobe Illustrator and InDesign ... Cheers, |
|
Hello René, thank you very much for looking into the issue. I've just tried the latest commit. Unfortunately, it still doesn't work. Here a small excerpt from the build log: :debug:patch Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2" && /usr/bin/patch -p0'
For what purpose XCode is required then?
If Qt5.4 does work fine on 10.6, it won't use any specific >= 10.7 API. Therefore, it should be possible to get it built under 10.6 too, right?
This is something I could give a try. Does Qt install any symlinks or additional tools to /usr/lib/bin, /usr/bin, /usr/local etc? I need to compile a software package that requires C++11 and Qt 5.3 or above so I need at least the proper header files... Many thanks once again! |
|
On Wednesday September 16 2015 12:53:09 maximumspatium wrote:
Hi,
Can you try once more? I shouldn't maintain multiple patches that touch the same file...
> Yes and no: it doesn't use the compilers from Xcode, but I reckon you still need to have Xcode installed.
For what purpose XCode is required then?
To have the system headerfiles and the rest of the SDKs, and maybe other things from the toolchain.
If Qt5.4 does work fine on 10.6, it won't use any specific >= 10.7 API. Therefore, it should be possible to get it built under 10.6 too, right?
It's more complicated than that. I don't recall the exact details, but Qt 5.4+ will not build on OS X 10.6 . Even getting 5.3.2 to build was a challenge!
This is something I could give a try. Does Qt install any symlinks or additional tools to /usr/lib/bin, /usr/bin, /usr/local etc? I need to compile a software package that requires C++11 and Qt 5.3 or above so I need at least the proper header files...
No, it installs everything where you tell it to, and then modifies the frameworks, config files and qmake so that they function from there.
Be aware though that C++11 support can be flaky/incomplete on 10.6, even when using a recent clang version. I myself found the C++11 support in MacPorts' gcc-4.9 more reliable, but nowadays it is possible to install libc++ for use with MacPorts clang. There's a whole recipe on how to do that on the MacPorts site. If that interests you, you'll probably want to do it before you build Qt!
Cheers,
Ren�
|
It still fails at the same place: :info:patch patching file qtbase/src/platformsupport/fontdatabases/mac/qcoretextfontdatabase.mm I did "git pull" followed by "port clean --all qt5-mac-devel"... |
|
On Wednesday September 16 2015 14:46:44 maximumspatium wrote:
Doh, of course it did ... the push hadn't gone through. Should be fine now. R. |
|
Patching passes now, thanks a lot! Configure fails with the following error: :info:configure -no-use-gold-linker: invalid command-line switch It looks like |
|
On Wednesday September 16 2015 16:18:08 maximumspatium wrote:
OK, final change/commit for this, I hope : for me it configures now (under 10.9, with the +legacy variant). Cheers, |
|
Hello René, thank you for the patches. I've already moved to the next step - Building. This is a good news although the build still fails. This command breaks the build: :info:build /usr/bin/clang -c -pipe -O2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_USE_ICU -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/mkspecs/macx-clang -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/src/corelib -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/include -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/include/QtCore -I../../include -I../../include/QtCore -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/include/QtCore/5.3.2 -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/include/QtCore/5.3.2/QtCore -Iglobal -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/src/3rdparty/harfbuzz/src -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/src/3rdparty/md5 -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/src/3rdparty/md4 -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/src/3rdparty/sha3 -I.moc -I. /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/src/corelib/tools/qstring_mac.mm -o .obj/qstring_mac.o It looks like Macport's own ICU @55.1_0 couldn't be found. Moreover, I noticed that the command above still invokes Below the Qt 5.3.2 configuration extracted from the recent build log: :info:configure Build parts ............ libs tools It cleanly shows that C++11 has been disabled which is BAD because it indicates that Clang 3.5 from Macports hasn't been recognized. ICU is there but the ancient Apple compiler 3.0 doesn't recognize it for some unknown reason. What do you think? |
|
On Thursday September 17 2015 14:10:49 maximumspatium wrote: Hi Max,
Do you have /opt/local/bin/clang and /opt/local/bin/clang++ and if so, where do they point to? The ucal.h header not found issue rings a bell, but a distant one.
Does your build log show anything related to the compiler selection process in the Portfile? I remember it wasn't easy at all to get Qt's build system to accept anything but the system compiler, and it's not impossible that my hack isn't as robust as I thought. Cheers, |
Yes, the following message will be displayed: The configure step DOES indeed use the above mentioned compiler (clang 3.5.2). But the build still falls back to the system compiler (Apple Clang 3.0). What I don't understand is why does C++11 test fail? I've already installed libcxx and libcxxabi and rebased the whole Macports system to libc++ as described here: https://trac.macports.org/wiki/LibcxxOnOlderSystems The Qt build log clearly shows that libc++ couldn't be found: :info:configure /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/build/qtbase/bin/clang++ -c -pipe -O2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -std=c++11 -stdlib=libc++ -mmacosx-version-min=10.7 -Wall -W -fPIE -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/mkspecs/macx-clang -I/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/config.tests/common/c++11 -I. -o c++11.o /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/config.tests/common/c++11/c++11.cpp Does it all mean that I end up having a broken Clang 3.5.2 installation? Thank you a lot for all the patience with my old system! |
|
I've just conducted two simple tests:
The next one (linking) doesn't work: clang++ -v -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -stdlib=libc++ -o c++11 c++11.o clang version 3.5.2 (tags/RELEASE_352/final)
Could you kindly help? Is it my fault? Everything looks like a broken Clang installation, does it? Thousands thanks in advance and sorry for being off-topic! |
|
On Thursday September 17 2015 15:50:21 maximumspatium wrote: Hi,
I have no experience at all with using libc++ on OS X 10.6.8 but there are a few things you have to know:
Try the link with -L/opt/local/lib, and check if there is a difference when you leave out the -Wl,-syslibroot arguments. R. |
Best regards |
|
On Friday September 18 2015 06:18:13 maximumspatium wrote:
Did you try without the sysroot SDK argument? If you did and still get the not found error it looks like you ran into a clang bug indeed. It might be useful to include a link to this exchange when you file a ticket. I'm still looking at the build failure and trying to get the compiler selection "just right". R. |
Yes, I've tried without sysroot/SDK argument with
Great! Thanks a lot! |
|
On Friday September 18 2015 11:49:40 maximumspatium wrote:
Erm, you shouldn't have to add -L/usr/lib ...
I think I'm making progress. I'm working with qt5-mac-devel-x11 (which in facts builds all of qtbase, but doesn't even extract all the rest of Qt so is much leaner for testing). It appears to be building now, using my links to the selected clang compilers in /opt/local/bin . Your mileage may still vary though because I'm using clang-mp-3.6 and doing this under 10.9.5 . This shouldn't take much more than 30min, after which I'll push the new port to git. R. |
You're right - it's not required indeed :)) |
|
On Friday September 18 2015 12:04:30 maximumspatium wrote:
OK, so there's no bug in macports-clang. Remember how I said that an SDK selection can do funny things? You just witnessed one; libc++ isn't part of the 10.6 SDK, so even if you install it into the system you still cannot access it through the official 10.6 SDK. Think of it as a way to make sure that you target only official, stock libraries. I've push a new commit, please try it and let me know how it goes. R. |
I got the same error regarding ICU. The configure step uses Macports' clang whereas the buld step persistently switches to system clang (/usr/bin/clang). I'm sorry to take up so much of your time fighting with a legacy configuration. Should we give up or try once again? P.S.: I could try some things out if you'd give me some pointers... |
|
On Friday September 18 2015 13:50:28 maximumspatium wrote:
From the very first file that is built?
I saw that there is an ICU patch; can you confirm that it has been applied?
I can try to reproduce your issue in my 10.6 VM, but as I said I won't be able to do that the next few days. %> port clean qt5-mac-devel both commands should not return any hits, so let me know what you find. If you get no results, you can still try this: %> fgrep clang -R (those search in a convoluted way for clang references that are not in a bin directory, a priori that should be "clang" without any path info at all in your case.) R. |
I did everything exactly as you said (clean followed by configure followed by fgrep). The search has revealed several hardcoded _/usr/bin/clang_. %> fgrep /usr/bin/clang -R /opt/local/var/macports/build/opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtwebkit/Source/WebCore/bindings/scripts/CodeGeneratorObjC.pm: } elsif (-x "**/usr/bin/clang**") { %> fgrep /usr/bin/clang -R /opt/local/var/macports/build/opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/build/qtbase/config.status: LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -Os' CXXFLAGS='-Os' CFLAGS='-Os' CXX='**/usr/bin/clang++_' CC='/usr/bin/clang**' /opt/local/var/macports/build/opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/configure -platform macx-clang -sdk macosx10.6 -prefix /opt/local -archdatadir /opt/local/libexec/qt5-mac -docdir /opt/local/libexec/qt5-mac/doc -headerdir /opt/local/libexec/qt5-mac/include -plugindir /opt/local/libexec/qt5-mac/plugins -importdir /opt/local/libexec/qt5-mac/imports -qmldir /opt/local/libexec/qt5-mac/qml -datadir /opt/local/libexec/qt5-mac -libdir /opt/local/libexec/qt5-mac/lib -bindir /opt/local/libexec/qt5-mac/bin -libexecdir /opt/local/libexec/qt5-mac/libexec -translationdir /opt/local/libexec/qt5-mac/translations -sysconfdir /opt/local/libexec/qt5-mac/etc/xdg -examplesdir /opt/local/libexec/qt5-mac/examples -testsdir /opt/local/libexec/qt5-mac/tests -hostbindir /opt/local/libexec/qt5-mac/bin -hostlibdir /opt/local/libexec/qt5-mac/lib -hostdatadir /opt/local/libexec/qt5-mac -release -opensource -confirm-license -shared -force-pkg-config -no-pulseaudio -no-mtdev -no-harfbuzz -openssl-linked -no-xinput2 -no-xcb -no-xcb-xlib -no-libudev -no-egl -make libs -make tools -nomake examples -nomake tests -verbose -nis -cups -iconv -no-evdev -icu -fontconfig -no-pch -dbus-linked -glib -directfb -no-linuxfb -no-kms -framework -optimized-qmake -system-sqlite -no-sql-db2 -no-sql-ibase -no-sql-mysql -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite2 -no-sql-tds -no-openvg -process "$@" |
Everything looks good in first sight. I didn't verify whether it has been patched correctly. It just passes. Here the appropriate excerpt: :info:patch ---> Applying patch-icutest.pro.diff |
|
On Friday September 18 2015 14:31:49 maximumspatium wrote:
See, this helped. Turns out that MacPorts has a habit of resetting certain things to what it thinks should be the correct value, and of course that doesn't become apparent if you're working per phase like I usually do.
This is something I've missed; I'll take a look at that next. R. |
|
Hello René, congratulations! We've made a huge progress with Qt 5.3.2! It builds now just well although the build doesn't succeed for the time being. But first the good news:
The build currently chokes on :info:build /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-mac-devel/qt5-mac-devel/work/qt-everywhere-opensource-src-5.3.2/qtbase/src/widgets/dialogs/qfontdialog.cpp:333:1: error: invalid argument type 'QStringList' to unary expression Could you kindly look into this? I could send you the mispatched file if you want, so please just say me a word... Thank you for the awesome job! |
|
On Saturday September 19 2015 09:30:57 maximumspatium wrote:
Ahhh, good!
AAargh :) No need to send me the file, I get the same patch errors. I was half expecting some errors with the font patch, but not stupid ones like a stray +. Oh well...
Awesome would have been if it built without this whole trial-and-error process! Cheers, |
|
Hi again,
OK, it looks like this one was easy; I committed a corrected patch.
R.
|
|
René, building the Qt 5.3.2 with the latest patches (rev ae2f83b) succeed. So we moved a step further. Great news, isn't? Installation chokes on the "Staging into destroot" step with the following error: :info:destroot ---> Patching qt5: s|${developer_dir}|/Developer|g |
|
On Saturday September 19 2015 13:14:42 maximumspatium wrote:
further. Great news, isn't?
Whew!
:debug:destroot Backtrace: can't read "qt_cmake_module_dir": no such variable
Ah ... in this case my fault is just trying to support the flaky upstream Qt5 portgroup rather than imposing my own.
I'll be interested to know where the .cmake files are going to be installed in the end!
To save you time: use port's -o argument (e.g. sudo port -o install qt5-mac-devel): this will save you from having to do the whole build all over again. But do this before:
%> sudo rm -rf `port work qt5-mac-devel`/destroot
Cheers,
Ren�
|
Executed as you said: first |
|
On Saturday September 19 2015 14:51:43 maximumspatium wrote:
Executed as you said: first `sudo rm...` and then `sudo port -o install`. Macports restarts with the "Staging into destroot" and fails soon with `can't read "qt_cmake_module_dir": no such variable`. It seems I have to delete the whole installation and start over again. Argggh...
Don't ... it seems that my last push didn't go through again.
R.
|
|
:info:destroot ---> Patching libQtXmlPatterns.prl: /QMAKE_PRL_BUILD_DIR/d |
|
On Saturday September 19 2015 15:13:48 maximumspatium wrote:
Oh shoot, of course. I'll look into the differences (in the "post-destroot" stage) between mine and mcalhoun's way of installing things (locations). I probably should never have allowed the 5.3.2 version to install any other way than mine, but in reality this whole difference in install layout arose long after I had developed, tested and put to rest the 5.3.2 build. Of course you can decide to install my qt5-mac-devel-kde port (after doing yet another pull), if you don't mind the additional patches and are OK with not having all of qt5 under its own prefix under /opt/local/libexec (and rebuilding). If the Qt5 apps you need come from Linux and support Freedesktop stuff (including sharing with, say, GTk/gnome based apps) you may even find that qt5-mac-devel-kde works better. I too started out with all of Qt in its own prefix when I started making coinstallable Qt4 and Qt5 ports. But quickly ran into issues (with Qt4 in its own prefix, can't remember exactly what) that made me rethink and modify the original Qt4 install schema as little as possible to make it coinstallable. Cheers, |
|
I did |
|
On Sunday September 20 2015 02:59:40 maximumspatium wrote:
Oops, that's a misunderstanding . I only pushed a small change that should allow you to install qt5-mac-devel-kde, not qt5-mac-devel. That is in fact a different port, so it means you'll have to build it from scratch. If disk space is not an issue you can simply leave the build directory for qt5-mac-devel untouched, and finish building it when I manage to get the errors out of the Portfile. To recap: My install layout was developed and tested months before mcalhoun remembered he was the main qt5-mac maintainer and decided to ignore all my efforts. Cheers, |
|
Ok, I've started building |
|
On Sunday September 20 2015 03:46:41 maximumspatium wrote:
Eh? And it's building clang 3.7 from source I guess? Aie, that shouldn't happen either, it should have accepted your existing clang 3.5 (or 3.6?) just like the main port did ... R.
|
|
On Sunday September 20 2015 03:46:41 maximumspatium wrote:
This may actually be a side-effect (undesired...) of MacPort's compiler whitelisting feature. I'd advise to kill the process and do a sudo clean clang-3.7 llvm-3.7 unless you're actually interested in experimenting with a compiler version that may not even be released yet (and have issues on OS X 10.6). I'm taking a priority look at getting qt5-mac-devel-kde to accept clang-3.5 or clang-3.6 if they're installed. BTW: let's take this to private email: rjvbertin AT gmail dot com . R. |
|
OK, I've pushed a change which appears to work here (it doesn't attempt to install any macports-clang version for since I have v3.6 installed, even after I blacklisted my system clang).
R.
|
Strips everything that isn't related to Qt5 or at least indirectly to KDE. For now I've left in both KDE4 and KF5; those could be moved to a branch if they get in the way and interfere with a clear overview. Note the 2 previous commits which upgrade mlt and qgit. Committed from host : Portia.local Committing to working copy : macstrop-mkae
Hello and thank you for working on the additional QT5 ports!
I've just tried to build the qt5-mac-devel port using your portfiles. Unfortunately, it fails on the patching step. It looks like an attempt to apply QT 5.4.2 to 5.3.2 sources. It doesn't work for all files because the sources diverge too much.
The following patches break the build:
https://github.com/RJVB/macstrop/blob/master/aqua/qt5-mac-devel/files/patch-qFatal-no-abort.diff
https://github.com/RJVB/macstrop/blob/master/aqua/qt5-mac-devel/files/patch-improve-fontweight-support5.diff
The first one contains a tiny difference that I just fixed manually. But the second one is much bigger so I don't know how to fix it.
Would you kindly help me to fix that issue? It looks like you've found a possibility to build Qt5 in 10.6.8 without XCode. That's exactly what I'm looking for. I really need QT5 in 10.6.8 because I currently cannot upgrade my OS because I heavily depend on an older software package that isn't available in >= 10.7.
Thank you in advance!
Best regards
Max
The text was updated successfully, but these errors were encountered: