Your message dated Tue, 24 Mar 2026 13:43:58 +0000
with message-id <[email protected]>
and subject line Bug#1131525: Removed package(s) from unstable
has caused the Debian Bug report #826384,
regarding libogre-1.9.0: Does not setup its own runtime link paths (ldconfig)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
826384: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826384
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Version: 1.9.0+dfsg1-14.1+rm
Dear submitter,
as the package ogre-1.9 has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/1131525
The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.
Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)
--- End Message ---
