Bug 114435 – [Qt][Mac] Linking fails with Qt 5.1

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Andras Becsi]

[Qt][Mac] Linking fails with Qt 5.1

[Andras Becsi]

Created attachment 197578 [details]
Patch

[Simon Hausmann]

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)

[Tor Arne Vestbø]

Comment on attachment 197578 [details]
Patch

I agree with Simon, try CONFIG -= c++11 first.

[Andras Becsi]

Using CONFIG -= c++11 does not fix the issue for me. The build still fails because the linking command line still includes -stdlib=libc++.

[Andras Becsi]

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.

[Tor Arne Vestbø]

(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.

[Andras Becsi]

(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.

[Tor Arne Vestbø]

(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

[Andras Becsi]

Created attachment 197586 [details]
Patch

[Andras Becsi]

Comment on attachment 197586 [details]
Patch

Clearing flags on attachment: 197586

Committed r148204: <http://trac.webkit.org/changeset/148204>

[Andras Becsi]

All reviewed patches have been landed.  Closing bug.

[Allan Sandfeld Jensen]

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.

[Andras Becsi]

(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.

[Allan Sandfeld Jensen]

(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.