search

chaosfire / vdrift-ogre

Automatically exported from code.google.com/p/vdrift-ogre
0 stars 0 forks source link

Can't find Ogre plugin libraries (resulting in segfault) on openSUSE 11.4 64-bit and Debian #48

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
The game does not start. I receive the following output:

anixx@anixx-desktop:~> stuntrally
INFO: Home directory: /home/anixx
INFO: Config defaults directory: /usr/share/stuntrally/config
INFO: User config directory: /home/anixx/.config/stuntrally
INFO: Data directory:
INFO: User data directory: /home/anixx/.local/share/stuntrally
INFO: Cache directory: /home/anixx/.cache/stuntrally
INFO: Log directory: /home/anixx/.config/stuntrally
INFO: Starting VDrift-Ogre: 2010-05-01, O/S: Unix-like
INFO: 0 joysticks found.
INFO: Loading car controls from: /home/anixx/.config/stuntrally/controls.cfg
INFO: Sound initialization information:
ERROR: Can't open sound file: /sounds/tire_squeal.wav
Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
SceneManagerFactory for type 'DefaultSceneManager' registered.
Registering ResourceManager for type Material
Registering ResourceManager for type Mesh
Registering ResourceManager for type Skeleton
MovableObjectFactory for type 'ParticleSystem' registered.
OverlayElementFactory for type Panel registered.
OverlayElementFactory for type BorderPanel registered.
OverlayElementFactory for type TextArea registered.
Registering ResourceManager for type Font
ArchiveFactory for archive type FileSystem registered.
ArchiveFactory for archive type Zip registered.
DDS codec registering
FreeImage version: 3.10.0
This program uses FreeImage, a free, open source image library supporting all 
common bitmap formats. See http://freeimage.sourceforge.net for details
Supported formats: 
bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm
,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,
jp2
Registering ResourceManager for type HighLevelGpuProgram
Registering ResourceManager for type Compositor
MovableObjectFactory for type 'Entity' registered.
MovableObjectFactory for type 'Light' registered.
MovableObjectFactory for type 'BillboardSet' registered.
MovableObjectFactory for type 'ManualObject' registered.
MovableObjectFactory for type 'BillboardChain' registered.
MovableObjectFactory for type 'RibbonTrail' registered.
Loading library /usr/lib/OGRE/RenderSystem_GL
An exception has occured: OGRE EXCEPTION(7:InternalErrorException): Could not 
load dynamic library /usr/lib/OGRE/RenderSystem_GL.  System Error: 
/usr/lib/OGRE/RenderSystem_GL.so: cannot open shared object file: No such file 
or directory in DynLib::load at 
/usr/src/packages/BUILD/ogre_src_v1-7-1/OgreMain/src/OgreDynLib.cpp (line 91)
INFO: Obtained audio device:
      Frequency: 44100
      Format: 32784
      Bits per sample: 16
      Channels: 2
      Silence: 0
      Samples: 1024
      Size: 4096
      Exiting
Segmentation fault

This happens both with the package which I built in the openSUSE build service 
as well as with a package which I converted from the Ubuntu's one with alien.

Original issue reported on code.google.com by neptu...@mail.ru on 6 Apr 2011 at 10:41

GoogleCodeExporter commented 8 years ago 
You should check were OGRE plugins are installed on your system. As it says 
there, it cannot load /usr/lib/OGRE/RenderSystem_GL.so, which makes me suspect 
that the plugins are hidden in some obscure place, or maybe not installed at 
all. The path for the plugins can be set in config/plugins_nix.cfg file if 
needed.

Original comment by tapiovie...@gmail.com on 7 Apr 2011 at 8:06

GoogleCodeExporter commented 8 years ago 
It is installed in /usr/lib64/OGRE/RenderSystem_GL.so, since this is a 64-bit 
system. I wonder why it searches for the library in /usr/lib.

Original comment by neptu...@mail.ru on 7 Apr 2011 at 8:15

GoogleCodeExporter commented 8 years ago 
shouldn't /usr/lib be a symlink to /usr/lib64 on 64 bit systems?

Original comment by tapiovie...@gmail.com on 7 Apr 2011 at 8:19

GoogleCodeExporter commented 8 years ago 
Of course, not. 32-bit libraries are placed in /usr/lib and 64-bit libraries 
are placed in /usr/lib64. This is common at least for openSUSE, Fedora and 
Mandriva.

Original comment by neptu...@mail.ru on 7 Apr 2011 at 8:20

GoogleCodeExporter commented 8 years ago 
Yes, I googled a bit and found that out about those distros. On 
Debian/Ubuntu-based systems the lib dirs are /usr/lib32 and /usr/lib64 and 
/usr/lib is symlink to the native libs (on 32 bit systems, there might only be 
/usr/lib). Then again I think e.g. Arch uses only /usr/lib no matter the 
platform.

What makes this trickier, is that the plugin path is set in a config file and 
it doesn't seem to allow for alternatives. So it seems some CMake magic is 
needed to generate the plugins file during build process.

Original comment by tapiovie...@gmail.com on 7 Apr 2011 at 8:43

GoogleCodeExporter commented 8 years ago 
Hmm, using a cmake config file for generating the plugins file has some 
implications for running from source tree. I'm thinking best would be to ditch 
the plugins file entirely, allow some cmake path changing and also add a 
parameter or env variable for changing it without recompilation.

Original comment by tapiovie...@gmail.com on 7 Apr 2011 at 8:55

GoogleCodeExporter commented 8 years ago 
FindOGRE.cmake defines a var OGRE_PLUGIN_DIR_REL for the ogre plugins path. We 
should pass this var on to the compiler and then load the plugins.

Another advantage is that if we can load the libs dynamically, we only have to 
load the lib for the RenderSystem we are actually using.

Original comment by scrawl...@gmail.com on 7 Apr 2011 at 4:44

GoogleCodeExporter commented 8 years ago

Original comment by scrawl...@gmail.com on 7 Apr 2011 at 5:14

GoogleCodeExporter commented 8 years ago 
We decided to implement a method in pathmanager for this, also it will check 
for an environment variable, and if it is there, use it instead of the default. 
Like this, it will also be possible to change the ogre plugin path without 
recompiling sr, using the environment variable.

Original comment by scrawl...@gmail.com on 7 Apr 2011 at 5:26

GoogleCodeExporter commented 8 years ago 
Mercurial tip should now be able to handle the situation.

In addition, OGRE_PLUGIN_DIR env variable can be given for really obscure 
plugin paths.

Original comment by tapiovie...@gmail.com on 7 Apr 2011 at 6:21

GoogleCodeExporter commented 8 years ago

Original comment by tapiovie...@gmail.com on 9 Apr 2011 at 11:55

GoogleCodeExporter commented 8 years ago 
Same issue on debian:
*-*-* Version 1.7.3 (Cthugha)
Loading library /RenderSystem_GL
An exception has occured: 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 
/home/fabrizio/Scrivania/stuntrally/ogre_src_v1-7-3/OgreMain/src/OgreDynLib.cpp 
(line 91)
INFO: Exiting
Errore di segmentazione

How to fix?

Original comment by fabrixx2 on 10 Jul 2011 at 8:46

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I don't know much since I'm building on Windows.
But it looks like RenderSystem_GL library wasn't installed or is somewhere else 
than we wanted. Try to find if you have this file anywhere on disk and set in 
config to point it, like in Comment 1.

Original comment by Cry...@gmail.com on 10 Jul 2011 at 11:25

GoogleCodeExporter commented 8 years ago 
Determining by the paths in the error message, you have compiled Ogre yourself, 
have you also installed it and if so, where? Latest stuntrally from git can 
dynamically find the standard paths (/usr/[local/]lib and friends) as stated in 
comment #10. Not sure if this is yet in a released version, what version are 
you using? In case of older version, you should either try compiling from git, 
or set the correct path in the ogre config file.

Original comment by tapiovie...@gmail.com on 11 Jul 2011 at 5:35

GoogleCodeExporter commented 8 years ago 
I'm fairly certain that this is an issue that is already fixed in source (see 
my previous comment), so unless anything new arises, I'll close this in a 
couple of days.

Original comment by tapiovie...@gmail.com on 11 Jul 2011 at 5:38

GoogleCodeExporter commented 8 years ago 
Closing.

Original comment by tapiovie...@gmail.com on 14 Jul 2011 at 8:29