UiTools library not provided as a framework in qt-opensource-mac-x64-clang-5.x.x.dmg
-
Hello,
Why is the UiTools library only available as a static library and not as a shared library or framework on Mac?
Is it intended or is it an installer bug?
I observe that when I download qt-opensource-mac-x64-clang.*.dmg for 4.8.6, 5.6.2, 5.7.0 and 5.8.0.
There is also a growing list of static only libraries between these versions. Here is the list I collected (just listing the .a files not the .la/.prl files to keep the list readable):- 4.8.6 installer installs directly in the system hierarchy in /usr/lib/libQtUiTools.a (whereas frameworks for other libraries are installed in /Libraries/Frameworks)
5.* installers install in custom directories:
-
5.6.2: 5.6/clang_64/lib/
libQt5Bootstrap.a
libQt5OpenGLExtensions.a
libQt5OpenGLExtensions_debug.a
libQt5PlatformSupport.a
libQt5PlatformSupport_debug.a
libQt5QmlDevTools.a
libQt5UiTools.a
libQt5UiTools_debug.a
libqtfreetype.a
libqtfreetype_debug.a -
In addition to the libraries in 5.6.2, 5.7.0 adds the following static only libraries:
5.7/clang_64/lib/
libQt5QmlDebug.a
libQt5QmlDebug_debug.a -
In addition to the libraries in 5.7.0, 5.8.0 adds the following static only libraries:
5.8/clang_64/lib/
libQt5AccessibilitySupport.a
libQt5AccessibilitySupport_debug.a
libQt5CglSupport.a
libQt5CglSupport_debug.a
libQt5ClipboardSupport.a
libQt5ClipboardSupport_debug.a
libQt5DeviceDiscoverySupport.a
libQt5DeviceDiscoverySupport_debug.a
libQt5EventDispatcherSupport.a
libQt5EventDispatcherSupport_debug.a
libQt5FbSupport.a
libQt5FbSupport_debug.a
libQt5FontDatabaseSupport.a
libQt5FontDatabaseSupport_debug.a
libQt5GraphicsSupport.a
libQt5GraphicsSupport_debug.a
libQt5PacketProtocol.a
libQt5PacketProtocol_debug.a
libQt5PlatformCompositorSupport.a
libQt5PlatformCompositorSupport_debug.a
libQt5ThemeSupport.a
libQt5ThemeSupport_debug.a
libqtlibpng.a
libqtlibpng_debug.a
-
Hi and welcome to devnet,
It's nothing macOS specific you can take a look at the designer code in the qttools module.
-
Hi and welcome to devnet,
It's nothing macOS specific you can take a look at the designer code in the qttools module.
Hi @SGaist ,
Just to make sure I understand your answer. You are saying that it is expected to link only my executables against the UiTools library (because it is only provided as static) and to not link my custom shared libraries against it, right?
-
No, I'm not. You were asking whether it was a bug that the installed version of the library was static thus the answer: no it's not a bug. The configuration of that library project is clearly static.
-
Thanks @SGaist
Indeed I can see that qt5/qttools/src/designer/src/uitools/uitools.pro has an explicit:
CONFIG += staticMy question is now why is it that way? Why this restriction? What can't we have this library as a shared library or framework?
Should I open a jira case to request this or is there an underlying reason to have this library to be built only as static?
-
See commit
37a8e98cd004601623476fc0a390fc156c0b52f5
in qttools.You can also read the history of the file for more details.
By the way, why would you need that library to be shared ?
-
See commit
37a8e98cd004601623476fc0a390fc156c0b52f5
in qttools.You can also read the history of the file for more details.
By the way, why would you need that library to be shared ?
Here is the scenario that concerned me:
I create a shared library L of my own QWidgets, using uitools.
I create a executable E which uses uitools directly and uses L.
I will have to link L against the static uitools and link E against boh L and static uitools.
In this context, I could have duplicate symbols because I am linking against the uitools static library twice. -
IIRC, you should be safe. You are linking against your library for the symbol it provides not for the one that it is using from another library.
-
IIRC, you should be safe. You are linking against your library for the symbol it provides not for the one that it is using from another library.
It is not just about the symbols but also about the global state that uitools lib could bring.
-
Correct me if I am wrong but I suspect this is an instance of this issue (building with clang on Mac):
ld: warning: direct access in function 'QtPrivate::ValueTypeIsMetaType<QList<QWidget*>, true>::registerConverter(int)' from file 'libQt5UiTools.a(abstractformbuilder.o)' to global weak symbol 'QMetaTypeIdQtMetaTypePrivate::QSequentialIterableImpl::qt_metatype_id()::metatype_id' from file 'myclass.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
Or it might be due to https://bugreports.qt.io/browse/QTBUG-37962