When we distribute a linux engine along with the Editor, this engine is built not simply using a makefile, but using debian scripts. What is also special about these scripts, is that they configure "rpath" for the engine, hardcoding "lib32" or "lib64" subdirectories. This lets an engine built like that "magically" know to look for any dependencies in ./lib32 or /lib64.
|
DEB_BUILD_OPTIONS="rpath=lib64" pbuilder-dist jessie amd64 build \ |
Such engine binary was intended to be used with the file structure deployed for the linux game ports by the Editor, where all libraries, including necessary game plugins, are placed into lib32/64 dirs relative to the engine binary.
This seem to be broken in the latest 3.6.0, where it cannot find a library in lib32/64 dir.
This can be noticed if a game is using plugins that also have extra custom dependencies, not installed in the system paths. (Like, another user-made library, or simply a so file that is distributed as-is) One good example is AGSSteam plugin (libagsteam.so) which also requires libsteam-api.so (part of the Steam SDK, afaik). Engine can find a plugin libagsteam.so itself if it's placed along with the engine, or the link to the plugin is created in the engine's dir (generated launch script does that, supposedly), because that is how it is coded. But agssteam's dependency is being searched by dlopen automatically, and it fails to find it in turn.
I previously spoke with @ericoporto about this, and he proposed to also set LD_LIBRARY_PATH in the game's launch script. (NOTE: this script is also generated by the Editor here)
I confirmed that this method fixes the problem.
But @morganwillcock claims that setting LD_LIBRARY_PATH is not recommended, and suggests to fix the problem with the bundle's build instead, where rpath is set, and is supposed to work. So I opened this ticket instead, for discussion and search of a reason why it stopped working in 3.6.0.
NOTE: I confirmed that pre-3.6.0 "bundle" engine builds work well (3.5.1, 3.5.0).
TEST GAME:
test--350steamplugin.zip
PS. There's still an issue of a "common" engine (built with makefile or CMake) not being able to do the same. I shall open a separate ticket for that. EDIT: #1865
When we distribute a linux engine along with the Editor, this engine is built not simply using a makefile, but using debian scripts. What is also special about these scripts, is that they configure "rpath" for the engine, hardcoding "lib32" or "lib64" subdirectories. This lets an engine built like that "magically" know to look for any dependencies in
./lib32or/lib64.ags/debian/make_ags+libraries.sh
Line 77 in 24fdb20
Such engine binary was intended to be used with the file structure deployed for the linux game ports by the Editor, where all libraries, including necessary game plugins, are placed into lib32/64 dirs relative to the engine binary.
This seem to be broken in the latest 3.6.0, where it cannot find a library in lib32/64 dir.
This can be noticed if a game is using plugins that also have extra custom dependencies, not installed in the system paths. (Like, another user-made library, or simply a so file that is distributed as-is) One good example is AGSSteam plugin (
libagsteam.so) which also requireslibsteam-api.so(part of the Steam SDK, afaik). Engine can find a pluginlibagsteam.soitself if it's placed along with the engine, or the link to the plugin is created in the engine's dir (generated launch script does that, supposedly), because that is how it is coded. But agssteam's dependency is being searched bydlopenautomatically, and it fails to find it in turn.I previously spoke with @ericoporto about this, and he proposed to also set
LD_LIBRARY_PATHin the game's launch script. (NOTE: this script is also generated by the Editor here)I confirmed that this method fixes the problem.
But @morganwillcock claims that setting
LD_LIBRARY_PATHis not recommended, and suggests to fix the problem with the bundle's build instead, whererpathis set, and is supposed to work. So I opened this ticket instead, for discussion and search of a reason why it stopped working in 3.6.0.NOTE: I confirmed that pre-3.6.0 "bundle" engine builds work well (3.5.1, 3.5.0).
TEST GAME:
test--350steamplugin.zip
PS. There's still an issue of a "common" engine (built with makefile or CMake) not being able to do the same. I shall open a separate ticket for that. EDIT: #1865