Bug#826384: libogre-1.9.0: Does not setup its own runtime link paths (ldconfig)

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist


Hi,

2016-06-05 9:05 GMT+01:00 shasheene <shasheene at gmail.com>:
> Package: libogre-1.9.0
> Version: libgre-1.9-dev, libogre-1.8-dev (and on Wheezy, libogre-1.7.4-dev)
> Severity: important
>
> Dear Maintainer,
>
> I have encountered this bug when attempting to build the example code for a library named 'libhand' [1], which I have recently took upon myself to maintain and update to support modern Debian/Linux.
>
> The package libogre-dev (and its related variants) on Debian 7/8 or Ubuntu 12.04/14.04/16.04 does not appear to setup its runtime link parameters correctly.
>
> The issue occurs when OGRE attempts to dynamically load a plugin with loadPlugin() [2] I get the following output:
> *-*-* OGRE Initialising
> *-*-* Version 1.8.0 (Byatis)
> Loading library RenderSystem_GL
> Exception: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL.  System Error: RenderSystem_GL.so: cannot open shared object file: No such file or directory in DynLib::load at /build/ogre-1.8-LbVXIp/ogre-1.8-1.8.0+dfsg1/OgreMain/src/OgreDynLib.cpp (line 91)
>
> I have found a work around, if I first run:
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/x86_64-linux-gnu/OGRE-1.9.0
> sudo ldconfig
>
> The application then succeeds to create a rendered image.
>
> I am fairly new to OGRE, so I could be misusing the API (there is another call, installPlugin() that suggests using loadPlugin() if possible). I do know that loadPlugin() can use a plugin.cfg file (that specifies the linking paths), but this is not the Debian way to do runtime linking. As a user of libogre-dev, that's not a portable solution: using a script to populate the exact path to the shared objects (depending on architecture) inside a local plugin.cfg file seems to wrong way to go about it.
>
> I would have thought the /etc/ld.so.conf.d/[arch]-linux-gnu.conf file would have sufficed for the search paths. given it doesn't appear to maybe the OGRE deb file should do something like deploy a file to /etc/ld.so.conf.d/ and run `sudo ldconfig` when it installs.
>
> [1] https://github.com/jonkeane/libhand
> [2] http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_root.html#af0744e85bddb05885a91809bcdf8f864

As you say above, the path to the plugins is provided via plugins.cfg,
along with the set of plugins that the application wants to load (so
the application avoids "paying" for resources that doesn't use, avoids
crashes if the plugins don't work in the given hardware --which
happened in the past--, etc.).

At some point this file plugins.cfg was provided in Debian by the OGRE
packages, but after asking upstream it looks like most OGRE
installations and non-Linux platforms do not provide a "default"
plugins.cfg, and in the OGRE world applications are the ones providing
this file.

This is what other applications in Debian using OGRE already do.


Adding paths globally through /etc/ld.so.conf.d/ is not a good
solution, I think, because then all searches for libraries would be
forced to look into that directory, even if they are not OGRE
applications at all.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>