Using different tool chain than the one used to build Qt

stephenju

I am kind of confused on the tool chains right now. Specifically, the dependencies on the libraries used.

Say I build Qt 5 with default tool chain which is Apple LLVM (clang) on OS X 10.7. The resulting Qt dylibs depends on /usr/lib/libstdc++.6.dylib which is the only tool chain specific lib from what I can tell.

Then I use a different tool chain, say GCC 4.7 from MacPorts, to build my own application. It will than depend on /opt/local/lib/gcc47/libstdc++.6.dylib.

The resulting application will now link against 2 different copies (and versions) of libstdc++.6.dylib when run. My question is: will this be an issue?

One possible fix (if it's a problem) I can think of is to use GCC and specify -static-libstdc++ and -static-libgcc to build Qt and my app. Is this a good idea? Or can I just use install_name_tool to change my app's dependency to the /usr/lib one?

Thanks.

tobias.hunger

Disclaimer: As said before: I do not really use a mac.

You can load an arbitrary number of libraries. From that point of view loading /usr/lib/libstdc++.6.dylib and /opt/local/lib/gcc47/libstdc++.6.dylib at the same time is just fine. But of course in this case the symbols provided by those libraries will clash, triggering error messages or nasty side effects.

You can not avoid this clash of symbols by making one or the other library static. So static linking will not help at all.

stephenju

So the only solution is to use the same exact tool chain with Qt and my app. Right?

This poses an interesting issue for people trying out C++11 features like me. Qt itself doesn't require C++11 enabled. Most people will just install or build it without C++11. Now depending on what compiler you use, the library mix-and-match may happen:

GCC links against libstdc++ with or without C++11 enabled. So it should be fine. But when C++11 is enabled, Clang requires linking against libc++ instead of libstdc++. Now the app and Qt will be loading different ones. I would think that is a BAD thing. :)

What I am trying to do is to use GCC 4.7 instead of Apple's clang sine GCC has better C++11 support. Now I am stuck as the mixed up libraries. I tried building Qt 5 with GCC 4.7 without success. Some part of Qt is using Apple extensions.

Off to try building Qt with clang 3.1 from MacPorts. Fun. Fun. Fun...

stephenju

Well. Qt 5 doesn't like clang 3.1, at least not the version in MacPorts. It's complaining about using reinterpret_cast in constexpr:

@/Qt/5.0/qtbase/include/QtCore/../../src/corelib/tools/qbytearray.h:392:29: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr]
Q_DECL_CONSTEXPR inline QByteArray(QByteArrayDataPtr dd)
^
/Qt/5.0/qtbase/include/QtCore/../../src/corelib/tools/qbytearray.h:393:13: note: reinterpret_cast is not allowed in a constant expression
: d(reinterpret_cast<Data *>(dd.ptr))
^
@

So that's a no go. But I finally get it going by building Qt 5 with Apple LLVM-GCC 4.2, then use GCC 4.7 tool chain for C++11 feature. Using install_name_tool, I then change the references to libstc++ in the binary from 4.7 to the system ones. This is probably no kosher but it works so far.

One of my problem is I need to deploy it to 10.6. So I can't use Apple clang since libc++ does not exist in 10.6. Just another monkey wrench Apple throws my way. :)

stephenju

I find a way to skip install_name_tool steps. By adding linker flags to have GCC skips its own default libraries, I am able to specify which exact copies of GCC libraries to use:

@QMAKE_LFLAGS += -nodefaultlibs /usr/lib/libstdc++.dylib /usr/lib/libgcc_s.1.dylib@

This forces GCC to link to the system provided libstdc++ and libgcc. Those in OS X 10.6/7 seem to be compatible with GCC 4.7. This makes my resulting app deployable to OS X 10.6 without including my own copies of GCC libraries.

To sum things up:

Revert system GCC to Apple's 4.2 by using MacPorts select command:
@sudo port select gcc none@
Configure and build Qt 5 with -platform and -SDK options:
@./configure -developer-build -opensource -confirm-license -nomake examples -nomake tests -platform macx-g++ -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk@
Select GCC 4.7 for project:
@sudo port select gcc mp-gcc47@
Add QMAKE_LFLAGS above to my project:
@QMAKE_LFLAGS += -nodefaultlibs /usr/lib/libstdc++.dylib /usr/lib/libgcc_s.1.dylib@

Now my project can be built with GCC 4.7 and C++11 enabled while deployable back to OS X 10.6. Yeah!

johngull

Hello,

Did anybody tried to use same procedure and deploy to MacOS 10.9?

For me it cause crash in dynamic_cast for Qt objects. As far as i understand Qt refers to /usr/lib/libgcc_s.1.dylib, but on MacOS 10.9 this is symlink to clang libc++.

The only solution i found is to use install_name_tool for all Qt Frameworks i keep with application.
Maybe it will help to somebody :)

But maybe somebody has any advice how to make it better.