Build failures with KSyntaxHighlighting 5.49
Needs ReviewPublic

Authored by asemke on Aug 25 2018, 11:40 AM.

Details

Reviewers
tcanabrava
Group Reviewers
KDE Edu
Cantor
Frameworks
Summary

For T5382 and T4760 we decided to switch to KSyntaxHighlighting. After having added the current released version of this library to cantor's build as per the attached patch, the build fails with the following linker error

bin/ld: cannot open output file ../../../bin/cantor/backends/cantor_maximabackend.so: Not a directory

Can somebody help here? What I'm doing wrong here?

This error doesn't happen with the older versions of KSyntaxHighlighting like 5.44.

Diff Detail

Repository
R55 Cantor
Lint
Lint Skipped
Unit
Unit Tests Skipped
asemke created this revision.Aug 25 2018, 11:40 AM
Restricted Application added a project: KDE Edu. · View Herald TranscriptAug 25 2018, 11:40 AM
Restricted Application added a subscriber: kde-edu. · View Herald Transcript
asemke requested review of this revision.Aug 25 2018, 11:40 AM
asemke edited the summary of this revision. (Show Details)Aug 25 2018, 11:43 AM
asemke edited the summary of this revision. (Show Details)

I think the issue is the

find_package(ECM 5.15.0 REQUIRED CONFIG)

to

find_package(ECM 5.49.0 REQUIRED CONFIG)

change

If I don't do that, it still links.
I think some changed ECM behavior is not to your liking.

I think the issue is the

find_package(ECM 5.15.0 REQUIRED CONFIG)

to

find_package(ECM 5.49.0 REQUIRED CONFIG)

change

If I don't do that, it still links.
I think some changed ECM behavior is not to your liking.

thanks @cullmann . It's strange somehow... I'll proceed with ECM 5.15 now and keep this review open a bit. Maybe somebody else knows what's going on here.

Perhaps other frameworks people know the exact cause.

mpyne added a subscriber: mpyne.Aug 25 2018, 11:32 PM

I don't know the cause myself but the ECM version works up until 5.38.0 in my own testing. So presumably the change in behavior is something introduced in that release of ECM?

The ECM documentation points to a specific change that may be related: https://api.kde.org/ecm/kde-module/KDECMakeSettings.html#build-settings

Using the KDE_SKIP_BUILD_SETTINGS option that is described just leads to different build failures for me, however. I think it's just a matter of adjusting some buildsystem-specific paths to reflect the new locations with newer ECM.

I don't know the cause myself but the ECM version works up until 5.38.0 in my own testing. So presumably the change in behavior is something introduced in that release of ECM?

Then that's easy: 7af93dd2

Finding why the cantor build fails requires more output (VERBOSE=1 make -j1) after removing CMakeCache.txt

I don't know the cause myself but the ECM version works up until 5.38.0 in my own testing. So presumably the change in behavior is something introduced in that release of ECM?

Then that's easy: 7af93dd2

Finding why the cantor build fails requires more output (VERBOSE=1 make -j1) after removing CMakeCache.txt

With this I'm getting

[ 25%] Linking CXX shared module ../../../bin/cantor/backends/cantor_nullbackend.so
cd /home/alex/Projekte/cantor/build_debug/src/backends/null && /usr/bin/cmake -E cmake_link_script CMakeFiles/cantor_nullbackend.dir/link.txt --verbose=1
/usr/bin/c++  -fPIC -std=c++0x -fno-operator-names -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -std=c++0x -fno-operator-names -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -pedantic -Wsuggest-override -Wlogical-op -Wzero-as-null-pointer-constant -fexceptions -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags  -shared  -o ../../../bin/cantor/backends/cantor_nullbackend.so CMakeFiles/cantor_nullbackend.dir/nullbackend.cpp.o CMakeFiles/cantor_nullbackend.dir/nullsession.cpp.o CMakeFiles/cantor_nullbackend.dir/nullexpression.cpp.o CMakeFiles/cantor_nullbackend.dir/nullcompletionobject.cpp.o CMakeFiles/cantor_nullbackend.dir/cantor_nullbackend_automoc.cpp.o ../../../bin/libcantorlibs.so.18.11.70 /usr/lib64/libKF5KIOFileWidgets.so.5.49.0 /usr/lib64/libKF5Bookmarks.so.5.49.0 /usr/lib64/libKF5Solid.so.5.49.0 /usr/lib64/libKF5KIOWidgets.so.5.49.0 /usr/lib64/libKF5KIOCore.so.5.49.0 /usr/lib64/libQt5Concurrent.so.5.11.1 /usr/lib64/libKF5JobWidgets.so.5.49.0 /usr/lib64/libKF5XmlGui.so.5.49.0 /usr/lib64/libKF5Completion.so.5.49.0 /usr/lib64/libKF5IconThemes.so.5.49.0 /usr/lib64/libKF5Archive.so.5.49.0 /usr/lib64/libKF5ItemViews.so.5.49.0 /usr/lib64/libKF5Service.so.5.49.0 /usr/lib64/libKF5ConfigWidgets.so.5.49.0 /usr/lib64/libKF5ConfigGui.so.5.49.0 /usr/lib64/libKF5ConfigCore.so.5.49.0 /usr/lib64/libKF5I18n.so.5.49.0 /usr/lib64/libKF5WidgetsAddons.so.5.49.0 /usr/lib64/libKF5Codecs.so.5.49.0 /usr/lib64/libKF5Auth.so.5.49.0 /usr/lib64/libKF5CoreAddons.so.5.49.0 /usr/lib64/libQt5DBus.so.5.11.1 /usr/lib64/libQt5Widgets.so.5.11.1 /usr/lib64/libQt5Gui.so.5.11.1 /usr/lib64/libQt5Network.so.5.11.1 /usr/lib64/libQt5Xml.so.5.11.1 /usr/lib64/libQt5Core.so.5.11.1 -Wl,-rpath,/home/alex/Projekte/cantor/build_debug/bin 
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not a directory

This error for cantor_nullbackend.so I always get for the second and later make calls. The first fails for cantor_maximabackend.so.

cgiboudeaux added a comment.EditedAug 26 2018, 8:23 PM

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not a directory

OK, I can reproduce and ironically, the issue is caused by a fix in kcoreaddons to fix a runtime issue with the commit I mentioned before.

Short version:
the cantor stuff uses the kcoreaddons_add_plugin macro with the INSTALL_NAMESPACE parameter pointing to "cantor/backends" This creates a cantor/backends subdir in ${CMAKE_BINARY_DIR}/bin/

The build fails locally because the linker can't create the cantor executable in ${CMAKE_BINARY_DIR}/bin. There's already a directory using the same name.

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not a directory

OK, I can reproduce and ironically, the issue is caused by a fix in kcoreaddons to fix build with the commit I mentioned before.

Short version:
the cantor stuff uses the kcoreaddons_add_plugin macro with the INSTALL_NAMESPACE parameter pointing to "cantor/backends" This creates a cantor/backends subdir in ${CMAKE_BINARY_DIR}/bin/

The build fails locally because the linker can't create the cantor executable in ${CMAKE_BINARY_DIR}/bin. There's already a directory using the same name.

I see. Thanks for the explanation. Since there is no urgent need to use for ECM 5.49, we can stick to 5.15 for a moment. Or are there any reasons not to do so?

David, Elvis, what's the nicest way to fix this ? (https://phabricator.kde.org/D15076#315803 for the details)

Hmm, I can only think of renaming the cantor folder to something else (but that would probably be annoying for packagers...)

dfaure added a comment.Sep 2 2018, 8:24 PM

Yes, maybe rename cantor to cantorplugins?

The plugins dir already has some subdirs named plasmacalendarplugins or ruqolaplugins.

Of course the loading code has to be adapted accordingly.

We need the plugins in the bin dir for autotests to be able to locate them. Although ECM's commit 7d6d5b1 makes me wonder how it's all supposed to work now (before that commit I would have said that we can just move the stuff to bin/plugins/ to avoid this clash, and adjust QT_PLUGIN_PATH in ECMAddTests). I need to research this further, I guess Windows finds them in the bin dir and other OSes do need QT_PLUGIN_PATH. In which case moving them won't be an option.

@dfaure That change was an urgent measure on my part, in order to allow KDevelop tests on the CI system to find something, and be able to complete successfully. At the moment they all hang due to being unable to find any plugins (they have an error popup...). The lack of available plugins was a result of the ECM code completely breaking QT_PLUGIN_PATH - this is why some Framework tests fail as well, being unable to find any KIO plugins (disabling this same logic in ECM was what gave me the output I emailed to you about a week ago). We'll find out if my urgent measure was successful next time the Dependency Builds run through.

tcanabrava resigned from this revision.May 6 2019, 12:24 PM