Open gromain opened 3 years ago
Problem seems to lie with the prefix -DCMAKE_INSTALL_PREFIX=/usr
, since I can compile (almost) without it (not on the Raspberry though).
Unfortunately, I've got the same issue on rpi4 and X86-64 architecture (on manjaro)
The idea is that the cmake standard variable CMAKE_INSTALL_PREFIX should handle this. For a packaged build to work, you need to install to some writable location.
This s not to say this it's tested, though.
I wanted to build on Arch Linux x86_64 and found the "bug". here is a patch for the cmake file
diff --git a/libs/oeserverd/CMakeLists.txt b/libs/oeserverd/CMakeLists.txt
index aefa3a7..a8213c8 100644
--- a/libs/oeserverd/CMakeLists.txt
+++ b/libs/oeserverd/CMakeLists.txt
@@ -49,3 +49,3 @@ elseif (UNIX AND ARCH STREQUAL "x86_64")
${CMAKE_CURRENT_LIST_DIR}/linux64/oeserverd
- ${CMAKE_INSTALL_PREFIX}/bin/oeserverd COPYONLY
+ ${CMAKE_BINARY_DIR}/oeserverd COPYONLY
)
@@ -53,3 +53,3 @@ elseif (UNIX AND ARCH STREQUAL "x86_64")
${CMAKE_CURRENT_LIST_DIR}/linux64/libsgllnx64-2.29.02.so
- ${CMAKE_INSTALL_PREFIX}/bin/libsgllnx64-2.29.02.so COPYONLY
+ ${CMAKE_BINARY_DIR}/libsgllnx64-2.29.02.so COPYONLY
)
I think using CMAKE_BINARY_DIR
is used in most other configs, so maybe this could be added to upstream as I don't think it will break anything.
Hm... I don't think this patch is sane. ${CMAKE_BINARY_DIR} is not an installation path, it's a location used during the build, often just the directory build. It is used for Apple as an intermediate location for the final installation, but for other platform this location should be configurable using CMAKE_INSTALL_PREFIX.
Hi, but we are during build I am running cmake build this should not write to system paths yet. This is only expected on the install step. But you might be right that I shouldn't have removed the /bin part, I will check the resulting distribution package for that. Because normally I want to build with a restricted user and cmake should restrict itself to the build directory during build time, the install prefix will than be used during install (in arch mostly with a combination of the DESTDIR env var). But my C++/cmake are almost a decade ago, so maybe I'm wrong on that.
Do you have a better idea to build as a restricted user and having the "right" prefix for a later install into the system?
The more I dig into it, it looks strange that configure with COPYONLY is used to perform a step that seems a lot like an install step. Maybe I have some time to investigate later. Currently my arch package is missing the binaries oeserverd
and libsgllnx64-2.29.02.so
as well as the localization directory as make install currently does not touch them.
Do you have a better idea to build as a restricted user and having the "right" prefix for a later install into the system?
cmake -DCMAKE_INSTALL_PREFIX=/usr ..; DESTDIR=/my/local/path make install
is supposed to make the trick. However:
make tarball
target which works just fine. Making an installation package like here is more or less in a "patches welcome" state.make pkg
make install
which I presume is what's needed here.The error I got when doing make pkg (the same as described here) was seemingly fixed by the attached patch (fixed to the point that make pkg
works, nothing more tested). But to actually support make DESTDIR=foo install one probably have to look into cmake /Targets.cmake and add a new target. To keep things sane it must have another name like make local-install or so
Sorry for bringing bad news....
OK, here is a sketch to a patch to Targets.cmake whichs adds a local-install target. It's just a sketch. It requires DESTDIR to point something writable already when running cmake, not only during make install.
we are during build I am running cmake build this should not write to system paths yet.
Indeed. So this code should be moved to cmake/PluginInstall.cmake using install(CODE...
... which I have sketch for below. It allows the cmake invocation to run without DESTDIR, postponing installations to make local-install
. This batch is on top of ~bar~ foo.
I have tried to used the idea from your patches to simplify the oeserverd CMakeLists.txt. Now I get the binaries installed fine with my package. The only thing that is still missing is the translation stuff, is this still needed, where should this be installed.
Hello again,
I'm building this plugin with a script from the Arch User Repository, but I'm stumbling on an error that I can't solve. There is apparently a permission error when Cmake is doing
configure_file
on files fromlibs/oeserverd/linux64/oeserverd
. This problem is observed both on my main computer running Manjaro on a x86_64 architecture and on a Raspberry Pi running Manjaro ARM 64 bits.The build script is available here, relevant part below:
The GetArch.cmake patch is here to fix the detection for arm64 architecture. Patch is there.
I've checked that this also happens when I manually build the package using a fresh pull from this repository. This is the CMakeOutput.log file: CMakeOutput.log
Cmake build message during build: