Create Task
Maniphest T430

JOBS: OSX: How to properly configure qt5 (i.e. w/o using MacPorts)
Closed, ResolvedPublic
Actions

Description

My ports-list.txt states that there are quite a few dependencies needed for qt5:

zlib openssl dbus jpeg tiff libmng libpng mysql55 pkgconfig icu pcre libiconv sqlite3
  • I think we can do (for a start) without mysql55.
  • Also we should skip pkgconfig, as it doesn't exist on a bare OSX system.
  • System libs exist for zlib, openssl, jpeg, tiff, pcre, iconv and sqlite3.
  • These should be shipped with qt5: libmng, libpng
  • Don't know what to do about these:
    • glib: Where do we get this?
    • icu: Set to -no-icu at the moment, but why?
    • dbus: Set to -dbus, but what to do about this, as we can't use MacPorts' port:dbus anymore?

Related Objects

• kaning created this task.Jun 22 2015, 9:32 PM
• kaning updated the task description. (Show Details)
• kaning raised the priority of this task from to Needs Triage.
• kaning added a project: build.kde.org.
• kaning moved this task to Awaiting Response on the build.kde.org board.
• kaning mentioned this in T270: DEPS: OSX: Missing deps (or not found due to their location under /opt/local).
• kaning added subscribers: • kaning, bcooksley, scarlettclark.
• kaning added a comment.EditedJun 22 2015, 9:37 PM

My first build trial using this slightly modified qt5config:

configureCommand=%(configureExecutable)s -debug -opensource -confirm-license -shared -force-pkg-config -no-mtdev -no-harfbuzz -openssl-linked -no-xinput2 -no-xcb-xlib -no-libudev -no-egl -make libs -make tools -nomake examples -nomake tests -verbose -nis -cups -iconv -no-evdev -no-icu -fontconfig -no-pch -dbus -no-xcb -separate-debug-info -directfb -no-linuxfb -no-kms -no-framework -optimized-qmake -no-sql-db2 -no-sql-ibase -plugin-sql-mysql -system-sqlite -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite2 -no-sql-tds -platform macx-clang -no-openvg -force-debug-info -no-strip -prefix {instPrefix} -v -glib

ended with this error:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -headerpad_max_install_names -Wl,-dead_strip -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -stdlib=libc++ -mmacosx-version-min=10.7 -Wl,-rpath,@loader_path/../../../../lib -Wl,-rpath,/opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/lib -o ../../../bin/Linguist.app/Contents/MacOS/Linguist .obj/numerus.o .obj/translator.o .obj/translatormessage.o .obj/qm.o .obj/qph.o .obj/po.o .obj/ts.o .obj/xliff.o .obj/batchtranslationdialog.o .obj/errorsview.o .obj/finddialog.o .obj/formpreviewview.o .obj/globals.o .obj/main.o .obj/mainwindow.o .obj/messageeditor.o .obj/messageeditorwidgets.o .obj/messagehighlighter.o .obj/messagemodel.o .obj/phrasebookbox.o .obj/phrase.o .obj/phrasemodel.o .obj/phraseview.o .obj/printout.o .obj/recentfiles.o .obj/sourcecodeview.o .obj/statistics.o .obj/translatedialog.o .obj/translationsettingsdialog.o .obj/simtexth.o .obj/qrc_linguist.o .obj/moc_batchtranslationdialog.o .obj/moc_errorsview.o .obj/moc_finddialog.o .obj/moc_formpreviewview.o .obj/moc_mainwindow.o .obj/moc_messageeditor.o .obj/moc_messageeditorwidgets.o .obj/moc_messagehighlighter.o .obj/moc_messagemodel.o .obj/moc_phrasebookbox.o .obj/moc_phrase.o .obj/moc_phrasemodel.o .obj/moc_phraseview.o .obj/moc_recentfiles.o .obj/moc_sourcecodeview.o .obj/moc_statistics.o .obj/moc_translatedialog.o .obj/moc_translationsettingsdialog.o   -L/Users/marko/WC/KDECI-builds/kf5-qt5/qt5/qtbase/lib -lQt5PrintSupport_debug -framework DiskArbitration -framework IOKit -lQt5Xml_debug -L/Users/marko/WC/KDECI-builds/kf5-qt5/qt5/qttools/lib -lQt5UiTools_debug -lQt5Widgets_debug -lQt5Gui_debug -framework OpenGL -framework AGL -lQt5Core_debug 
ld: warning: direct access in QMetaTypeId<QUiTranslatableStringValue>::qt_metatype_id() to global weak symbol QMetaTypeId<QUiTranslatableStringValue>::qt_metatype_id()::metatype_id means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in QMetaTypeId<QUiTranslatableStringValue>::qt_metatype_id() to global weak symbol QMetaTypeId<QUiTranslatableStringValue>::qt_metatype_id()::metatype_id means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in int qRegisterNormalizedMetaType<QUiTranslatableStringValue>(QByteArray const&, QUiTranslatableStringValue*, QtPrivate::MetaTypeDefinedHelper<QUiTranslatableStringValue, (QMetaTypeId2<QUiTranslatableStringValue>::Defined) && (!(QMetaTypeId2<QUiTranslatableStringValue>::IsBuiltIn))>::DefinedType) to global weak symbol QtMetaTypePrivate::QMetaTypeFunctionHelper<QUiTranslatableStringValue, true>::Construct(void*, void const*) means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in int qRegisterNormalizedMetaType<QUiTranslatableStringValue>(QByteArray const&, QUiTranslatableStringValue*, QtPrivate::MetaTypeDefinedHelper<QUiTranslatableStringValue, (QMetaTypeId2<QUiTranslatableStringValue>::Defined) && (!(QMetaTypeId2<QUiTranslatableStringValue>::IsBuiltIn))>::DefinedType) to global weak symbol QtMetaTypePrivate::QMetaTypeFunctionHelper<QUiTranslatableStringValue, true>::Destruct(void*) means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in int qRegisterNormalizedMetaType<QUiTranslatableStringValue>(QByteArray const&, QUiTranslatableStringValue*, QtPrivate::MetaTypeDefinedHelper<QUiTranslatableStringValue, (QMetaTypeId2<QUiTranslatableStringValue>::Defined) && (!(QMetaTypeId2<QUiTranslatableStringValue>::IsBuiltIn))>::DefinedType) to global weak symbol QtMetaTypePrivate::QMetaTypeFunctionHelper<QUiTranslatableStringValue, true>::Create(void const*) means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in int qRegisterNormalizedMetaType<QUiTranslatableStringValue>(QByteArray const&, QUiTranslatableStringValue*, QtPrivate::MetaTypeDefinedHelper<QUiTranslatableStringValue, (QMetaTypeId2<QUiTranslatableStringValue>::Defined) && (!(QMetaTypeId2<QUiTranslatableStringValue>::IsBuiltIn))>::DefinedType) to global weak symbol QtMetaTypePrivate::QMetaTypeFunctionHelper<QUiTranslatableStringValue, true>::Delete(void*) means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
Compiliation step exited with non-zero code, assuming failure to build from source for project qt5.
• kaning updated the task description. (Show Details)Jun 22 2015, 9:38 PM
• kaning updated the task description. (Show Details)Jun 22 2015, 9:40 PM
• kaning updated the task description. (Show Details)Jun 22 2015, 9:45 PM
• kaning updated the task description. (Show Details)Jun 22 2015, 9:48 PM
• kaning updated the task description. (Show Details)Jun 22 2015, 9:55 PM
• kaning added a comment.Jun 24 2015, 9:34 PM

Can we not serve glib and dbus using the CI system's scripts/config/projects/*.cfg and identifiers.json like in case of e.g. libssh?

scarlettclark added a comment.Jun 25 2015, 4:21 PM

huh? I have no idea what you mean, sorry.

• kaning added a comment.EditedJun 25 2015, 5:34 PM

I mean that we deliver those two dependencies like you did it also for mlt, for instance. (But those two projects pull in some more dependencies which would also to be considered.)

Well, I won't be able to contribute much, as it is, since I lack knowledge and most of all time!!
There are changes upcoming on my end which will make it close to impossible for me to be nearly as active as I have been in the past year...

bcooksley added a comment.Apr 14 2016, 1:06 AM

Question: do we want to try to self compile Qt 5 for OSX or should we just use the Digia/Qt Company binaries?

Considering DBus is a fish out of water on these platforms i'd tend to push for them not to be made available, but that's a discussion which probably needs to be had on kde-frameworks-devel. I know the Krita developers certainly go without DBus on Windows.

• kaning added a comment.EditedApr 14 2016, 5:48 AM

Using Digia's binaries would save KDE's CI system a lot of extra-hassle, yes...

... but on the other hand: the past has shown that building it ourselves helps to locate some hidden Qt issues.

Re dbus: it is in use on OSX, but yes, it comes with MacPorts. Hmmm, can't it be installed as an additional dependency, even without MacPorts, Homebrew or whatever in place?

scarlettclark added a comment.Apr 14 2016, 11:12 PM

The idea is that users do not have to install anything outside the dmg file. So unless it can be bundled, I say no.
Digia qt binaries is fine with me.

bcooksley added a comment.Apr 15 2016, 10:28 AM

In general i'd recommend avoiding D-Bus if at all possible - it's just another element to go wrong.
In theory one probably could bundle it, but if it isn't really needed by applications (which won't be talking to each other) then I see no reason to bloat our bundles further with it.

A way to actually do all the bundling as part of CMake or a similar process would be needed of course. ECM is probably the best place to put that. Until QSP is sorted i'd also recommend disabling execution of tests on OSX as they're pointless.

bcooksley changed the visibility from "All Users" to "Public (No Login Required)".Apr 15 2016, 10:28 AM
rjvbb added a subscriber: rjvbb.Apr 15 2016, 1:10 PM

I don't know about MS Windows, but MacPorts has only a few minor patches for DBus on OS X. Given that, I'm tempted to view DBus as a cross-platform desktop bus at least for Unix-based platforms. It's definitely not a fish out of the water, at most a bit of a weird duck in the pond (to stick with Aqua references :)).

Proper DBus functionality is going to be much more dependent on issues related to QSP than on DBus itself.

Re: bundling: Qt comes with macdeployqt which takes care of much (if not all) of the bundling.
But just let me register a request when it's still time: whatever ultimate implementation for creating standalone app bundles, please make it something that can be turned off *without* need for hacking CMake files. One solution could be to determine the install location of things based on QSP output.
I've been spending a lot of time setting up MacPorts ports for K*5 software which install only the application executable and icon in an app bundle and the rest in the usual locations under ${prefix}. IMVHO this can only help in getting the software to work optimally under the most familiar conditions before (eventually and optionally AFAIAC) creating standalone app bundles for the applications where that makes sense.
I wouldn't want to see that effort go to waste because of an imposed decision that KF5 applications are to be built *only* as standalone app bundles on OS X.

• kaning added a comment.Apr 15 2016, 6:01 PM

+1 from me, René!

bcooksley closed this task as Resolved.May 26 2017, 12:23 PM
bcooksley claimed this task.

The new CI system will be relying on the Platform (either through Qt Company, or other packaging system) to provide Qt so this won't be an issue going forward as we won't be compiling Qt ourselves.

Any issues will need to be resolved with the packager for the Platform (which we probably need to work within constraints wise anyway).