Bug 411580

Summary:	kdeconnect-kde failed with "/usr/bin/ld: cannot open output file ../bin/kdeconnect: Is a directory"
Product:	[Applications] kdeconnect	Reporter:	farseerfc
Component:	common	Assignee:	Philip C <cliabhach>
Status:	RESOLVED FIXED
Severity:	normal	CC:	albertvaka, arojas, cliabhach, matthijstijink
Priority:	NOR
Version First Reported In:	1.3.5
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description farseerfc 2019-09-04 06:50:28 UTC

SUMMARY

When trying to build kdeconnect-kde for git repo, make failed with
```
/usr/bin/ld: cannot open output file ../bin/kdeconnect: Is a directory
```

There is a directory called "bin/kdeconnect" where it shouldn't be.

By reverting the commit dedb4b1ed216a22eaedb33c114f3a30fea67839d, it can build normally.

STEPS TO REPRODUCE
1. On Arch Linux, build the kdeconnect-git package with this PKGBUILD: https://fars.ee/qiuO

OBSERVED RESULT
```
[  9%] Linking CXX executable ../bin/kdeconnect
[  9%] Building CXX object core/CMakeFiles/kdeconnectcore.dir/daemon.cpp.o
/usr/bin/ld: cannot open output file ../bin/kdeconnect: Is a directory
collect2: error: ld returned 1 exit status
make[2]: *** [app/CMakeFiles/kdeconnect.dir/build.make:129: bin/kdeconnect] Error 1
make[1]: *** [CMakeFiles/Makefile2:3885: app/CMakeFiles/kdeconnect.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[  9%] Building CXX object core/CMakeFiles/kdeconnectcore.dir/device.cpp.o
[  9%] Building CXX object core/CMakeFiles/kdeconnectcore.dir/core_debug.cpp.o
[  9%] Linking CXX executable ../bin/kdeconnect-settings
[ 10%] Building CXX object core/CMakeFiles/kdeconnectcore.dir/notificationserverinfo.cpp.o
[ 10%] Built target kdeconnect-settings
[ 10%] Linking CXX shared library ../bin/libkdeconnectcore.so
[ 10%] Built target kdeconnectcore
make: *** [Makefile:141: all] Error 2
```

EXPECTED RESULT

Build normally

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux 
KDE Plasma Version: 5.16.5
KDE Frameworks Version:  5.61.0
Qt Version: 5.13.0

ADDITIONAL INFORMATION
extra-cmake-modules: 5.61.0

Comment 1 Matthijs Tijink 2019-09-04 18:27:29 UTC

I cannot reproduce this, even with the same PKGBUILD and installed software versions. Do you have any uncommon configurations (gcc, etc.)?

Comment 2 farseerfc 2019-09-05 03:06:29 UTC

> I cannot reproduce this, even with the same PKGBUILD and installed software versions. Do you have any uncommon configurations (gcc, etc.)?

No, I use extra-x86_64-build command from extra/devtools package, which makes a clean chroot environment every time to build the package. It is documented here https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot#Convenience_way and used by Arch Linux packagers for official packages.

I can reproduce this both on my own desktop PC as well as a build server running Arch Linux.

Comment 3 Antonio Rojas 2019-09-05 17:24:22 UTC

This is only reproducible if you compile *without* krunner. Here's what's going on:

- If you *don't* have krunner: cmake calls find_package(ECM 5.48.0), from kdeconnect's CMakelists. Since 5.48.0>5.38.0, ECM sets CMAKE_LIBRARY_OUTPUT_DIRECTORY 
 to ${CMAKE_BINARY_DIR}/bin (see KDECmakeSettings), and all binaries are installed there - which causes this conflict between the kdeconnect dir used by plugins and the kdeconnect binary.

- If you *do* have krunner: after all of the above, krunner calls plasma, which in turn calls kpackage, which in turn calls find_package(ECM 1.6.0). Since 1.6.0<5.38.0, ECM *unsets* the CMAKE_LIBRARY_OUTPUT_DIRECTORY that was previously set - so now each binary is installed to its own dir and they don't conflict.

So this is a real bug, which is only masked by krunner pulling an import of an old version of ECM.

Comment 4 Antonio Rojas 2019-09-10 17:41:49 UTC

This should be fixed with c451d7064e86df055d80e7d2cb078e2966ef3cce

Comment 5 farseerfc 2019-09-11 00:15:00 UTC

(In reply to Antonio Rojas from comment #4)
> This should be fixed with c451d7064e86df055d80e7d2cb078e2966ef3cce

Thanks! I can confirm that this is fixed on my machines after c451d7064e86df055d80e7d2cb078e2966ef3cce.

Comment 6 Albert Vaca Cintora 2019-09-12 17:27:14 UTC

Might be worth fixing the underlying bug.