Permission Error on configure_file of CMake during make pkg build

[gromain]

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 from libs/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:

build() {
  cd $pkgname
  patch --strip=1 --binary -i $srcdir/GetArch.cmake.patch
  mkdir -p build
  cd build
  cmake -DCMAKE_INSTALL_PREFIX=/usr -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config-gtk3 ..
  make pkg
}

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:

==> Starting build()...
patching file cmake/GetArch.cmake
-- Cmake version: 3.20.2.
-- Building: 
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Selected upload repository: david-register/ocpn-plugins-unstable
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    wxWidgets_CONFIG_EXECUTABLE


-- Build files have been written to: /home/carlina/.cache/yay/opencpn-plugin-oesenc-git/src/opencpn-plugin-oesenc-git/build
-- Cmake version: 3.20.2.
-- Building: pkg
-- Selected upload repository: david-register/ocpn-plugins-unstable
-- *** Staging to build oesenc_pi ***
-- Found Gettext: /bin/msgmerge (found version "0.21") 
-- Found OpenGL: /usr/lib/libOpenGL.so   
-- Found wxWidgets: -pthread;;;-lwx_baseu-3.0;-lwx_gtk3u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu_xml-3.0;-lwx_gtk3u_html-3.0;-lwx_gtk3u_adv-3.0 (found version "3.0.5") 
-- Found CURL: /usr/lib/libcurl.so (found version "7.76.1")  
-- Using bundled tinyxml
CMake Error at libs/oeserverd/CMakeLists.txt:48 (configure_file):
  Permission denied


CMake Error at libs/oeserverd/CMakeLists.txt:52 (configure_file):
  Permission denied

-- Configuring incomplete, errors occurred!
See also "/home/carlina/.cache/yay/opencpn-plugin-oesenc-git/src/opencpn-plugin-oesenc-git/build/CMakeFiles/CMakeOutput.log".
make[3]: *** [CMakeFiles/pkg-conf.dir/build.make:70: pkg-conf] Error 1
make[2]: *** [CMakeFiles/Makefile2:346: CMakeFiles/pkg-conf.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:405: CMakeFiles/pkg.dir/rule] Error 2
make: *** [Makefile:267: pkg] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

[gromain]

Problem seems to lie with the prefix -DCMAKE_INSTALL_PREFIX=/usr, since I can compile (almost) without it (not on the Raspberry though).

[jynio]

Unfortunately, I've got the same issue on rpi4 and X86-64 architecture (on manjaro)

[leamas]

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.

[nylocx]

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.

[leamas]

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.

[nylocx]

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?

[nylocx]

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.

[leamas]

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:

• The upstream development is focused on the managed plugins and the corresponding make tarball target which works just fine. Making an installation package like here is more or less in a "patches welcome" state.
• Having a ten years old toolchain adds a yet another layer of uncertainties.
• I can reproduce the error on Fedora 34 with cmake 3.20, using make pkg
• Latest versions of the plugin doesn't even support a plain make installwhich 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 pkgworks, 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....

foo.diff.gz

[leamas]

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.

bar.patch.gz

[leamas]

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...

[leamas]

... 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.

baz.patch.gz

[nylocx]

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.