[Qt][Mac] Linking fails with Qt 5.1
Created attachment 197578 [details] Patch
Comment on attachment 197578 [details] Patch r=me but I'd prefer if the QMAKE_LFLAGS/CXXFLAGS setting could be replaced with CONFIG -= c++11 if it works. (mkspecs/features/c++11.prf adds those in the first place, and that should be processed after this .pri file)
Comment on attachment 197578 [details] Patch I agree with Simon, try CONFIG -= c++11 first.
Using CONFIG -= c++11 does not fix the issue for me. The build still fails because the linking command line still includes -stdlib=libc++.
In ANGLE.pri CONFIG does not even contain c++11 yet, and because QT_CONFIG does it is still added to CONFIG in mkspecs/features/qt_common.prf, which apparently happens after processing this pri file.
(In reply to comment #5) > In ANGLE.pri CONFIG does not even contain c++11 yet, and because QT_CONFIG does it is still added to CONFIG in mkspecs/features/qt_common.prf, which apparently happens after processing this pri file. Not sure why c++11 is handled that way, but QT_CONFIG -= c++11 should work around it.
(In reply to comment #6) > (In reply to comment #5) > > In ANGLE.pri CONFIG does not even contain c++11 yet, and because QT_CONFIG does it is still added to CONFIG in mkspecs/features/qt_common.prf, which apparently happens after processing this pri file. > > Not sure why c++11 is handled that way, but QT_CONFIG -= c++11 should work around it. Ok, I though changing QT_CONFIG would not be an option.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > In ANGLE.pri CONFIG does not even contain c++11 yet, and because QT_CONFIG does it is still added to CONFIG in mkspecs/features/qt_common.prf, which apparently happens after processing this pri file. > > > > Not sure why c++11 is handled that way, but QT_CONFIG -= c++11 should work around it. > > Ok, I though changing QT_CONFIG would not be an option. It's a bit hackish, but less so than changing the QMAKE_LFLAGS_CXX11
Created attachment 197586 [details] Patch
Comment on attachment 197586 [details] Patch Clearing flags on attachment: 197586 Committed r148204: <http://trac.webkit.org/changeset/148204>
All reviewed patches have been landed. Closing bug.
How is this supposed to work. If you build ANGLE with libstdc++ includes, the symbols are just going to be missing in the final binary. This is the result of merging this now: http://testresults.qt-project.org/ci/QtWebKit_dev_Integration/build_00098/macx-clang_developer-build_OSX_10.8/log.txt.gz ANGLE referencing libstdc++ specific stuff, which is never linked in.
(In reply to comment #12) > How is this supposed to work. If you build ANGLE with libstdc++ includes, the symbols are just going to be missing in the final binary. > > This is the result of merging this now: > http://testresults.qt-project.org/ci/QtWebKit_dev_Integration/build_00098/macx-clang_developer-build_OSX_10.8/log.txt.gz > > ANGLE referencing libstdc++ specific stuff, which is never linked in. ANGLE should not be build with c++11 support, and it wasn't when this got committed, since then the configuration in Qt might have changed, so this might not have an effect any more.
(In reply to comment #13) > (In reply to comment #12) > > How is this supposed to work. If you build ANGLE with libstdc++ includes, the symbols are just going to be missing in the final binary. > > > > This is the result of merging this now: > > http://testresults.qt-project.org/ci/QtWebKit_dev_Integration/build_00098/macx-clang_developer-build_OSX_10.8/log.txt.gz > > > > ANGLE referencing libstdc++ specific stuff, which is never linked in. > > ANGLE should not be build with c++11 support, and it wasn't when this got committed, since then the configuration in Qt might have changed, so this might not have an effect any more. It isn't but that means it will by default be build with libstdc++, where the final QtWebKit module is linked with libc++. This means we end up with the wrong symbols.