Archlinux Python-Ogre Information


02-07-2011 05:12:32

Finally I got python-ogre working in archlinux in a clean way.

Note that you have to change "python" to "python2" for example, "sudo ln -s /usr/bin/python2 /usr/local/bin/python"

The first line assumes you're using yaourt for AUR frontend. Otherwise, just install ogre-1.7.2 pygccxml-svn py++-svn from AUR.

yaourt -S ogre-1.7.2 pygccxml-svn py++-svn #--noconfirm

svn co python-ogre

tar -jxvf ogre_src_v1-7-2.tar.bz2
mv ogre_src_v1-7-2 ogre

mkdir -p ./root/usr/include
ln -sf /usr/include/OGRE ./root/usr/include/
ln -sf /usr/include/OIS ./root/usr/include/
ln -sf /usr/include/boost ./root/usr/include/

python python-ogre/ -g -c ogre
python python-ogre/ -g -c ois
python python-ogre/ -b install


20-05-2012 21:13:42

Hello kkb110.
Sorry for ressurecting an old thread, but I'm out of idea.

I'm trying to get python-ogre to work on ArchLinux.
Following your instructions, I managed to get it to compile properly along with OIS, but when I try to import Ogre, I get the following error:

In [1]: import ogre.renderer.OGRE as ogre
ImportError: /usr/lib/python2.7/site-packages/ogre/renderer/OGRE/ undefined symbol: _ZN4Ogre9SingletonINS_17ControllerManagerEE12ms_SingletonE

$> nm -D | grep _ZN4Ogre9SingletonINS_17ControllerManagerEE12ms_SingletonE
U _ZN4Ogre9SingletonINS_17ControllerManagerEE12ms_SingletonE

I did check using nm and indeed Ogre::Singleton<Ogre::ControllerManager>::ms_Singleton is not defined (and so are other singletons, but I didn't reach the point where it could be a problem).
This specific symbol is not defined in any object generated by pyplusplus as far as I can tell.

Can you post the revisions of pygccxml & py++ you used as I have the feeling the prb is coming from the original code generation and not from the compilation. Or maybe you found a workaround for the current state of archlinux available tools.

Many thanks !


22-05-2012 07:22:51

What version of gcc does Archlinux use?

What does nm | grep 'ms_Singleton' report?

As a guess I would suspect this is related to visibility settings:

You could try disabling the visibility settings for Ogre in the main CMakeLists.txt
at the end of the test for visibility section i.e set(OGRE_GCC_VISIBILITY_FLAGS "").

First let us know the version of gcc and gccxml you are using since the above will probably require rebuilding the Ogre / module.


22-05-2012 13:42:40

What version of gcc does Archlinux use?

It is a bit of a moving target since Arch is a rolling update distrib. But in my case, the compilation has been done with GCC 4.7.0.
As for gccxml, I'm using the latest CSV as of 2012-05-20.

What does nm | grep 'ms_Singleton' report?

Good point, it doesn't report anything for ms_Singleton or for the missing symbol.

As a guess I would suspect this is related to visibility settings:

You could try disabling the visibility settings for Ogre in the main CMakeLists.txt
at the end of the test for visibility section i.e set(OGRE_GCC_VISIBILITY_FLAGS "").

I already tried to activate the visibility flags in python-ogre SConstruct with no luck. Maybe the problem starts at the original Ogre 1.7.2 compilation. I'm going to try desactivate visibility options during the initial Ogre compilation and will tell you if it works.

EDIT : Removing the visibility flags did do the trick for Ogre. I now have the proper symbols exported. I still have to recompile the bindings, but I think I'm on the right track :)
Thx Dermont. I think you solved it :D

For those having the same prb, just run this line in your ogre src folder:



22-05-2012 18:25:53

The symbols should already be exported, the only difference being disabling visibility exports global symbols.

1) Original:

00517dc0 b _ZN4Ogre9SingletonINS_17ControllerManagerEE11msSingletonE

2) Disabling visibility:

00591ce0 B _ZN4Ogre9SingletonINS_17ControllerManagerEE11msSingletonE

<edit> your symbols will be 'ms_Singleton' , 'msSingleton' is for ogre1.8.x <\edit>

(2) resolved this problem previously. There is a problem with the order of the SConstruct build command so enabling the SConstruct settings for visibility may not have been applied (not sure).

I'm not sure what the instructions the OP posted do or how you have set it up so picks up the correct OgreMain lib since the instructions don't appear to build with --usesystem, I'm assuming LD_LIBRARY_PATH as per the build instructions.

Anyway I'll try building with gcc 4.70 tomorrow.


22-05-2012 23:55:41

Everything is working and I managed to run the samples without problem. The simple mention of visibility options for Ogre was the key. Many thanks :)

In my case, the symbol was not exported at all when compiling with visibility options. Removing them really did the trick.

About python-ogre visibility options & problem with not applied flags, it may explain why I ended up with variable size lib (from 70MB up to ~300MB). I will try moving the -O3 & visibility flags around as per the link indications and see what works best.

As for the OP instructions, it does not indeed provide an explicit LD_LIBRARY_PATH but the ogre-1.7.2 package on Archlinux is set to replace the official ogre-1.8.0RC1 package. I guess that's why I didn't really thought about it. OP explanations produce an environment with only one Ogre installed.

I'm in the process of making a proper package for Archlinux so we can finally easly enjoy python-ogre on this distrib :)


23-05-2012 22:47:12

Glad you got it sorted.

I tried a build with gcc4.7 here on Ubuntu but run into the same problem as you. Strangely enough disabling the visibility settings in Ogre and enabling in the SConstruct file the module imported and is 50% the size at 40MB.

As per the last link I directed you to

_env['CXX'] ='g++ -O3 -Wno-deprecated -DBOOST_PYTHON_MAX_ARITY=19 -DBOOST_PYTHON_NO_PY_SIGNATURES -fvisibility=hidden -fvisibility-inlines-hidden -DOGRE_GCC_VISIBILITY '

I think the reason the visibility settings were commented out in the SConstruct file were due to different problems with various versions of gcc. There may have been other reasons.

I didn't try building Ogre in Release mode -DCMAKE_BUILD_TYPE=Release (default is RelWithDebInfo -O2) so I don't know if that will make a difference.