| View previous topic :: View next topic |
| Author |
Message |
nagmat84
Guru
Joined: 27 Mar 2007
Posts: 314
|
 Posted: Wed Apr 23, 2025 10:34 am Post subject: How to install shared libs into usr/lib64/foo/ with dolib? |
 |
|
How do I use dolib.so inside "src_install" of my custom ebuild such that "dolib.so <file>" does not install the file as "usr/lib64/file" but into a sub-directory with a project-specific name as in "usr/lib64/${PN}/<file>?
I see that some other packages also create package-specific subdirectories inside usr/lib64. Unfortunately, I am dealing with an upstream project which creates project-specific libraries with such wonderful names like "libscreen", "libcore", "libcommon" and even "libffmpeg" which are prone to name collisions. Hence, I would like to install them into a subdirectory inside lib64 instead of having them on the top level.
Additionally, and probably related, I get a QA notice for each of the libraries that the runtime path RPATH is wrong and is automatically fixed. The message is | Code: |
Auto fixing rpaths for /var/tmp/portage/<category>/<package>/image/usr/lib64/libcore.so
* QA Notice: The following files contain insecure RUNPATHs
* Please file a bug about this at https://bugs.gentoo.org/
* with the maintainer of the package.
* /var/tmp/portage/<category>/<package>/image/usr/lib64/libcore.son RPATH: /var/tmp/portage/<category>/<package>/work/build/<child path> |
Indeed, I can confirm from the build log that the build command for each of the affected libraries contains "-Wl,-rpath,/var/tmp/portage/<category>/<package>/work/build/<child path>", for example as in | Code: |
/usr/bin/x86_64-pc-linux-gnu-g++
-fPIC
-O2
-march=znver3
-mshstk
--param=l1-cache-line-size=64
--param=l1-cache-size=32
--param=l2-cache-size=512
-pipe
-Wl,-O1
-Wl,--as-needed
-Wl,-z,pack-relative-relocs
-Wl,--dependency
-file=core/CMakeFiles/core.dir/link.d
-shared -Wl,-soname,libcore.so
-o core/libcore.so
core/CMakeFiles/core.dir/consumer/frame_consumer.cpp.o
core/CMakeFiles/core.dir/consumer/output.cpp.o
...
core/CMakeFiles/core.dir/video_channel.cpp.o
core/CMakeFiles/core.dir/video_format.cpp.o
-Wl,-rpath,/var/tmp/portage/media-video/casparcg-server-2.4.3/work/server-2.4.3-stable/src_build/common
/usr/lib64/libsfml-graphics.so
/usr/lib64/libsfml-window.so
/usr/lib64/libsfml-system.so common/libcommon.so |
However, there is nothing in the CMakeLists.txt which would suggest that option. While it is nice that Portage seemingly fixes this error automatically during the installation phase I rather prefer to fix it at its origin. How do I do that? |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2215
|
| Posted: Wed Apr 23, 2025 12:37 pm Post subject: |
|
|
Bypass dolib.so and set CMAKE_INSTALL_LIBDIR in src_configure to have cmake do it for you. Also, make sure to use get get_libdir function to determine if it is lib or lib64.
I do not have comments on the RPATH
Edit: | example: | src_configure() {
local mycmakeargs=(
-DCMAKE_INSTALL_LIBDIR="/usr/$(get_libdir)/${PN}"
)
cmake_src_configure
} |
|
|
| Back to top |
|
|
nagmat84
Guru
Joined: 27 Mar 2007
Posts: 314
|
| Posted: Wed Apr 23, 2025 1:18 pm Post subject: |
|
|
| grknight wrote: | | Bypass dolib.so and set CMAKE_INSTALL_LIBDIR in src_configure to have cmake do it for you. |
Unforunately, the CMakeList.txt does not contain any instructions for installation. Thats why cmake_src_install fails (because their is no target "install" for Ninja, i.e. "ninja install" fails.) That's why I have to use dolib.* and dobin in the first place. |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 2215
|
| Posted: Wed Apr 23, 2025 1:20 pm Post subject: |
|
|
| nagmat84 wrote: | | grknight wrote: | | Bypass dolib.so and set CMAKE_INSTALL_LIBDIR in src_configure to have cmake do it for you. |
Unforunately, the CMakeList.txt does not contain any instructions for installation. Thats why cmake_src_install fails (because their is no target "install" for Ninja, i.e. "ninja install" fails.) That's why I have to use dolib.* and dobin in the first place. |
Time to patch the files then after leaning how CMake installs these files. |
|
| Back to top |
|
|
wjb
l33t
Joined: 10 Jul 2005
Posts: 655
Location: Fife, Scotland
|
| Posted: Thu Apr 24, 2025 11:43 am Post subject: |
|
|
| nagmat84 wrote: | | ...an upstream project which creates project-specific libraries with such wonderful names like "libscreen", "libcore", "libcommon" and even "libffmpeg" which are prone to name collisions... |
So while you are patching the CMakeList.txt, also spend a little time to change these names (and offer the patch for this to upstream) |
|
| Back to top |
|
|
nagmat84
Guru
Joined: 27 Mar 2007
Posts: 314
|
| Posted: Thu Apr 24, 2025 11:53 am Post subject: |
|
|
| wjb wrote: | | nagmat84 wrote: | | ...an upstream project which creates project-specific libraries with such wonderful names like "libscreen", "libcore", "libcommon" and even "libffmpeg" which are prone to name collisions... |
So while you are patching the CMakeList.txt, also spend a little time to change these names (and offer the patch for this to upstream) |
While I probably should take the time to fix that, I probably won't do it and I doubt that my patches are welcomed upstream. The entire build system is a mess. Their (unpatched) build system is a CMakeLists.txt which actually calls python scripts which then try to download other sources (as a side load) via curl, which then are piped into a shell interpreter which then tries to spawn a Docker image which contains the actual build system. I would not even know where to start patching that. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
