Bug 411580 - kdeconnect-kde failed with "/usr/bin/ld: cannot open output file ../bin/kdeconnect: Is a directory"
Summary: kdeconnect-kde failed with "/usr/bin/ld: cannot open output file ../bin/kdeco...
Status: RESOLVED FIXED
Alias: None
Product: kdeconnect
Classification: Applications
Component: common (show other bugs)
Version: 1.3.5
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Philip C
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-04 06:50 UTC by farseerfc
Modified: 2019-09-12 17:27 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.