cumbersome LD_LIBRARY_PATH problem

Problems building or running the engine, queries about how to use features etc.
User avatar
paul424
Gnome
Posts: 380
Joined: Thu May 24, 2012 7:16 pm
x 19

cumbersome LD_LIBRARY_PATH problem

Post 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 ?

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5511
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1379

Re: cumbersome LD_LIBRARY_PATH problem

Post 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:

  1. Set the RPATH to "./" and make sure the working directory for app launcher is properly setup (like you'd do on Windows).
  2. 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.

slapin
Bronze Sponsor
Bronze Sponsor
Posts: 148
Joined: Fri May 23, 2025 5:04 pm
x 5

Re: cumbersome LD_LIBRARY_PATH problem

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