Page 1 of 1
cumbersome LD_LIBRARY_PATH problem
Posted: Fri Jun 20, 2025 5:25 pm
by paul424
Ogre Version: : 1 13 6 5:
Operating System: :Linux Tumbleweed:
Render System: :OpenGL3+
After reinstall of the Ogre lib on my machine I kept getting :
Code: Select all
./opendungeons-plus: error while loading shared libraries: Plugin_OctreeSceneManager.so.13.6:
cannot open shared object file: No such file or directory
adding the lib to the export LD_LIBRARY_PATH=/usr/lib/OGRE:$LD_LIBRARY_PATH fixes the problem. I see what mechanism cause this ( by reading ldconfig documentation)... but isn't that a big flaw of Ogre3d that on Linux one has to manually setup this ?
Re: cumbersome LD_LIBRARY_PATH problem
Posted: Fri Jun 20, 2025 11:07 pm
by dark_sylinc
Hi
paul424 wrote: Fri Jun 20, 2025 5:25 pm
but isn't that a big flaw of Ogre3d that on Linux one has to manually setup this
This is how Linux works in general. "RPATH" stores the folder where to look libraries for. There are several approaches. Upon installation, the installer could modify the elf files to change RPATH e.g. the installer could run:
Code: Select all
chrpath -r '/usr/lib/OGRE' /path/to/opendungeons-plus
The reason RPATH exists is that otherwise malware could force an app run to load the libraries from the wrong folder, which are under the attacker's control. If the app is not owned by the user (i.e. it's owned by root), then the attacker would have no way to control the app. But if the app just loads whatever library is on the working directory, then the attacker can control where the libraries are loaded from.
But of course for a videogame, this may be overkill. There's 2 more solutions besides the installer modifying the elf file using chrpath:
- Set the RPATH to "./" and make sure the working directory for app launcher is properly setup (like you'd do on Windows).
- Use
LD_LIBRARY_PATH which overrides RPATH (some consider LD_LIBRARY_PATH a security hole and is in fact forbidden on macOS with SIP enabled). Many apps put the launcher inside a shell script that first sets LD_LIBRARY_PATH, so that you don't launch the app directly, but rather the shell script.
For the first option, on CMake you can write:
Code: Select all
set_target_properties(my_executable PROPERTIES
BUILD_RPATH "./"
INSTALL_RPATH "./"
)
This will mimic Windows' behavior. Note that you can set more than one RPATH.
Re: cumbersome LD_LIBRARY_PATH problem
Posted: Sun Jun 22, 2025 6:39 pm
by slapin
Looks like build system issue as it fails to set runpath. I guess if you have only binaries, you can use chrpath tool. Otherwise you can set relative or absolute rpath using your build system. Also rpath is not security measure, it is just helper which allows for a binary to load libs from different paths. For security you need things like noexec mounts, IMA and selinux.