Ok thanks for the "heads up" on scons, never really use it. I'm just about to continue building the other modules (ogre,cegui,ois already work). I'll post here if I find anything releveant to your setup log.
OgreOde ----------- 1.1) Path issue with Path issue with python_ogreode.h
> With andy's comment about my system maybe being wierd i decided that i would > do a fresh install of dapper (compiled with gcc-4.0 unlike edgy gcc 4.1). > Will post with details.
> > 'cegui', 'ode', #'ogreode', 'ogreal'] > > possible_projects = ['ois'] > > I think you can do this directly via the scons script (scons ois - it > > didn't work for me).
> in order to do this with scons directly without editing the script the > command would be
> scons PROJECTS=ogre
> this overrides the hard coded variable possible_projects/default_projects > as stated below
> # This lets you call scons like: 'scons PROJECTS=ogre,cegui'
> I mean, I' like to avoid if anyhow possibile to go through the pain of
> > succesfully compiling and running python-ogre :)
> I would like to see python-ogre in a 'source' .rpm or .deb, fro clean > deployment and distribution?
> On 4/17/07, dermont <dermontg...@gmail.com> wrote:
> > > lol :) > > Yep out of order, sorry.
> > The way I did it was to compile one library at a time, i.e:
> > #possible_projects = ['ogre' , 'ois', 'ogrerefapp', 'ogrenewt', > > 'cegui', 'ode', #'ogreode', 'ogreal'] > > possible_projects = ['ois'] > > I think you can do this directly via the scons script (scons ois - it > > didn't work for me).
> > Also to reduce compile times with ogre and python-ogre:
> > CXXFLAGS="-O3" ./configure (the following is optional --with-gui=Xt) > > - reduces .so file to 5.5MB
> > > > Don't really know what you mean by the 'precious' binaries. The ogre/ > > > > cegui/ois should, with minor changes, compile quite easily.
> > > lol :)
> > > I mean, I' like to avoid if anyhow possibile to go through the pain of > > > succesfully compiling and running python-ogre :) > > > I'm currently compiling gcc-4.0.4 (debian has 4.1.2) and will > > > recompile the whole thing all over again, but if someone beat's me to > > > it, I wouldn't mind using his/hers binaries :D
My friend suggested one thing: install debian bootstrap, with ONLY base system, and compile python-ogre (and maybe trying with autoapt (if possible, I don't know), to download and install the packages as the compile is on process). When it finished, you'll have an detailed dependency structure needed ONLY to compile it. I think this is an good idea, I'll try it later... later! hhehe
Interesting, I'm waiting the Ubuntu Feisty to become available. It will have newer packages versions, maybe can help us. (I hope).
Well, when I get home, I'll share what I've done to compile.
> That's actually a great idea. If possible, please put down all the > "must-haves" for everything needed to compile it. Maybe "phases" > because that's what it seems like we need. A good install script may > be a good idea too, or even an apt repository with all the > dependencies. If we can get hosting, I'll do what I can to help with > organizing a set of Ubuntu apt packages.
> Right now I have a fresh install of Ubuntu Feisty (set for release in > 2 days, still Beta currently) and am waiting for the official release > to install python-ogre because a lot of our apt packages will be > updated then. If we can get a tenative list of steps together here, > I'll be a guinea pig.
> On Apr 17, 11:33 pm, "rafaelrie...@gmail.com" <rafaelrie...@gmail.com> > wrote: > > Hummm maybe we should write an clear detailed documentation explaining > > how to compile python-ogre on Linux. I'm writing down all steps I'm > > doing to compile it. In the end I'll share it.
-- Rafael Riedel Belo Horizonte, Minas Gerais Debian GNU/Linux - Testing Linux Registered user: #102363 <counter.li.org>
That is not needed I know exactly what is need to build python Ogre, I have almost all the dependencies (including GCC_XML and boost) checked into my project SVN repository. Like I have mentioned several times before on the list you need to maintain a separate environment for python-ogre by using --prefix command when compiling the packages that have to be compiled by hand. You also need to edit your LD_LIBRARY, and PKG_CONFIG paths accordingly. Use something like "--prefix=/home/ me/python-ogre/dev". Then when you make install everything will be installed there.
Now on to the issue with the missing symbol, that is an odd one, using c++filt it turns out that symbol is: Ogre::Singleton<Ogre::ArchiveManager>::ms_Singleton. Has anyone seen this before?
On Apr 18, 5:19 pm, "Rafael Riedel" <rafaelrie...@gmail.com> wrote:
> My friend suggested one thing: install debian bootstrap, with ONLY base > system, and compile python-ogre (and maybe trying with autoapt (if possible, > I don't know), to download and install the packages as the compile is on > process). When it finished, you'll have an detailed dependency structure > needed ONLY to compile it. I think this is an good idea, I'll try it > later... later! hhehe
> Interesting, I'm waiting the Ubuntu Feisty to become available. It will have > newer packages versions, maybe can help us. (I hope).
> Well, when I get home, I'll share what I've done to compile.
> > That's actually a great idea. If possible, please put down all the > > "must-haves" for everything needed to compile it. Maybe "phases" > > because that's what it seems like we need. A good install script may > > be a good idea too, or even an apt repository with all the > > dependencies. If we can get hosting, I'll do what I can to help with > > organizing a set of Ubuntu apt packages.
> > Right now I have a fresh install of Ubuntu Feisty (set for release in > > 2 days, still Beta currently) and am waiting for the official release > > to install python-ogre because a lot of our apt packages will be > > updated then. If we can get a tenative list of steps together here, > > I'll be a guinea pig.
> > On Apr 17, 11:33 pm, "rafaelrie...@gmail.com" <rafaelrie...@gmail.com> > > wrote: > > > Hummm maybe we should write an clear detailed documentation explaining > > > how to compile python-ogre on Linux. I'm writing down all steps I'm > > > doing to compile it. In the end I'll share it.
> Now on to the issue with the missing symbol, that is an odd one, using > c++filt it turns out that symbol is: > Ogre::Singleton<Ogre::ArchiveManager>::ms_Singleton. Has anyone seen > this before?
> On Apr 18, 5:19 pm, "Rafael Riedel" <rafaelrie...@gmail.com> wrote: > > My friend suggested one thing: install debian bootstrap, with ONLY base > > system, and compile python-ogre (and maybe trying with autoapt (if > possible, > > I don't know), to download and install the packages as the compile is on > > process). When it finished, you'll have an detailed dependency structure > > needed ONLY to compile it. I think this is an good idea, I'll try it > > later... later! hhehe
> > Interesting, I'm waiting the Ubuntu Feisty to become available. It will > have > > newer packages versions, maybe can help us. (I hope).
> > Well, when I get home, I'll share what I've done to compile.
> > > That's actually a great idea. If possible, please put down all the > > > "must-haves" for everything needed to compile it. Maybe "phases" > > > because that's what it seems like we need. A good install script may > > > be a good idea too, or even an apt repository with all the > > > dependencies. If we can get hosting, I'll do what I can to help with > > > organizing a set of Ubuntu apt packages.
> > > Right now I have a fresh install of Ubuntu Feisty (set for release in > > > 2 days, still Beta currently) and am waiting for the official release > > > to install python-ogre because a lot of our apt packages will be > > > updated then. If we can get a tenative list of steps together here, > > > I'll be a guinea pig.
> > > On Apr 17, 11:33 pm, "rafaelrie...@gmail.com" <rafaelrie...@gmail.com> > > > wrote: > > > > Hummm maybe we should write an clear detailed documentation > explaining > > > > how to compile python-ogre on Linux. I'm writing down all steps I'm > > > > doing to compile it. In the end I'll share it.
As a rough and ready test I recompiled ogre with gcc3.4.6 (no visibility). I didn't do a full rebuild of the ogre module and the modules imported fine.
I've tried updating the scons build (to no avail) to include: "fvisibility=hidden -fvisibility-inlines-hidden - DOGRE_GCC_VISIBILITY "
I've haven't attempted a full build of boost with gcc3.4.6 or gcc4.1.x due to the problems compiling python-ogre with these compilers.
On Apr 19, 10:50 am, Game_Ender <jli...@gmail.com> wrote:
> That is not needed I know exactly what is need to build python Ogre, I > have almost all the dependencies (including GCC_XML and boost) checked > into my project SVN repository. Like I have mentioned several times > before on the list you need to maintain a separate environment for > python-ogre by using --prefix command when compiling the packages that > have to be compiled by hand. You also need to edit your LD_LIBRARY, > and PKG_CONFIG paths accordingly. Use something like "--prefix=/home/ > me/python-ogre/dev". Then when you make install everything will be > installed there.
> Now on to the issue with the missing symbol, that is an odd one, using > c++filt it turns out that symbol is: > Ogre::Singleton<Ogre::ArchiveManager>::ms_Singleton. Has anyone seen > this before?
> On Apr 18, 5:19 pm, "Rafael Riedel" <rafaelrie...@gmail.com> wrote:
> > My friend suggested one thing: install debian bootstrap, with ONLY base > > system, and compile python-ogre (and maybe trying with autoapt (if possible, > > I don't know), to download and install the packages as the compile is on > > process). When it finished, you'll have an detailed dependency structure > > needed ONLY to compile it. I think this is an good idea, I'll try it > > later... later! hhehe
> > Interesting, I'm waiting the Ubuntu Feisty to become available. It will have > > newer packages versions, maybe can help us. (I hope).
> > Well, when I get home, I'll share what I've done to compile.
> > > That's actually a great idea. If possible, please put down all the > > > "must-haves" for everything needed to compile it. Maybe "phases" > > > because that's what it seems like we need. A good install script may > > > be a good idea too, or even an apt repository with all the > > > dependencies. If we can get hosting, I'll do what I can to help with > > > organizing a set of Ubuntu apt packages.
> > > Right now I have a fresh install of Ubuntu Feisty (set for release in > > > 2 days, still Beta currently) and am waiting for the official release > > > to install python-ogre because a lot of our apt packages will be > > > updated then. If we can get a tenative list of steps together here, > > > I'll be a guinea pig.
> > > On Apr 17, 11:33 pm, "rafaelrie...@gmail.com" <rafaelrie...@gmail.com> > > > wrote: > > > > Hummm maybe we should write an clear detailed documentation explaining > > > > how to compile python-ogre on Linux. I'm writing down all steps I'm > > > > doing to compile it. In the end I'll share it.
> As a rough and ready test I recompiled ogre with gcc3.4.6 (no > visibility). I didn't do a full rebuild of the ogre module and the > modules imported fine.
No, you should stick with current version of ogre.
>> wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
Yes I think I said that above. The problem with singletons, for me, initally cropped up on pyogre when I moved from ogre1.4.0RC1 to ogre1.4. For me, compiling pyogre with gcc3.4.6 resolved it. The "gcc3.4.6 ogre only compile" was only a hack to see if it resolved the singleton problem ( I know I should go through the whole build cycle gccxml, python-ogre gcc with gcc3 but it doesn't work)
Three people (all Ubuntu) have posted this problem. Here gcc4.0.3 'nm' reports the singleton symbols as undefined. I've tried tracking this down with various combinations of gcc - compiling ogre, gccxml , running pygccxml (with visiblity flags on/off), compiling pygccxml (with visiblity flags on/off) to no avail. I'm probably missing some basic step here but I don't know what.
As always you should wait for the offical developers to guide you. I know I am.
<kresimir.s...@gmail.com> wrote: > wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
> shouli I try to compile ogre svn instead?
> > As a rough and ready test I recompiled ogre with gcc3.4.6 (no > > visibility). I didn't do a full rebuild of the ogre module and the > > modules imported fine.
> No, you should stick with current version of ogre.
> >> wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
> Yes I think I said that above. The problem with singletons, for me, > initally cropped up on pyogre when I moved from ogre1.4.0RC1 to > ogre1.4. For me, compiling pyogre with gcc3.4.6 resolved it. The > "gcc3.4.6 ogre only compile" was only a hack to see if it resolved the > singleton problem ( I know I should go through the whole build cycle > gccxml, python-ogre gcc with gcc3 but it doesn't work)
> Three people (all Ubuntu) have posted this problem. Here gcc4.0.3 > 'nm' reports the singleton symbols as undefined. I've tried tracking > this down with various combinations of gcc - compiling ogre, gccxml , > running pygccxml (with visiblity flags on/off), compiling pygccxml > (with visiblity flags on/off) to no avail. I'm probably missing some > basic step here but I don't know what.
> As always you should wait for the offical developers to guide you. I > know I am.
> <kresimir.s...@gmail.com> wrote: > > wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
> > shouli I try to compile ogre svn instead?
> > > As a rough and ready test I recompiled ogre with gcc3.4.6 (no > > > visibility). I didn't do a full rebuild of the ogre module and the > > > modules imported fine.
> typo: > >> compiling pygccxml(with visiblity flags on/off) to no avail > compiling python-ogre(with visiblity flags on/off) to no avail
> On Apr 20, 12:14 pm, dermont <dermontg...@gmail.com> wrote: > > >> shouli I try to compile ogre svn instead?
> > No, you should stick with current version of ogre.
> > >> wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
> > Yes I think I said that above. The problem with singletons, for me, > > initally cropped up on pyogre when I moved from ogre1.4.0RC1 to > > ogre1.4. For me, compiling pyogre with gcc3.4.6 resolved it. The > > "gcc3.4.6 ogre only compile" was only a hack to see if it resolved the > > singleton problem ( I know I should go through the whole build cycle > > gccxml, python-ogre gcc with gcc3 but it doesn't work)
> > Three people (all Ubuntu) have posted this problem. Here gcc4.0.3 > > 'nm' reports the singleton symbols as undefined. I've tried tracking > > this down with various combinations of gcc - compiling ogre, gccxml , > > running pygccxml (with visiblity flags on/off), compiling pygccxml > > (with visiblity flags on/off) to no avail. I'm probably missing some > > basic step here but I don't know what.
> > As always you should wait for the offical developers to guide you. I > > know I am.
> > <kresimir.s...@gmail.com> wrote: > > > wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
> > > shouli I try to compile ogre svn instead?
> > > > As a rough and ready test I recompiled ogre with gcc3.4.6 (no > > > > visibility). I didn't do a full rebuild of the ogre module and the > > > > modules imported fine.
>> Can you confirm it is only this one singleton that fails...
No from what I've seen it applies to all singletons, creating a simple module for say pyogre:
with singletons results in undefined symbols without imports OK.
Here's a sample output from nm on the ogre .so for the LogManagerSingleton.
# nm gcc 3.46 compiled release mode ======================== 0019b5f4 t _GLOBAL__I__ZN4Ogre9SingletonINS_10LogManagerEE12ms_SingletonE 0019ad50 T _ZN4Ogre10LogManager12getSingletonEv 0019ad38 T _ZN4Ogre10LogManager15getSingletonPtrEv -> 0046fc64 B _ZN4Ogre9SingletonINS_10LogManagerEE12ms_SingletonE 003a9600 r _ZZN4Ogre10LogManager12getSingletonEvE19__PRETTY_FUNCTION__ 003a9680 r _ZZN4Ogre9SingletonINS_10LogManagerEEC1EvE19__PRETTY_FUNCTION__ 003a9640 r _ZZN4Ogre9SingletonINS_10LogManagerEED1EvE19__PRETTY_FUNCTION__
# nm gcc 4.0.3 compiled (-g -O2) ===================== 00154c06 t global constructors keyed to _ZN4Ogre9SingletonINS_10LogManagerEE12ms_SingletonE 00154aa6 T Ogre::LogManager::getSingleton() 00154a90 T Ogre::LogManager::getSingletonPtr() -> 003cac24 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton 00307ae0 r Ogre::LogManager::getSingleton()::__PRETTY_FUNCTION__ 00307b60 r Ogre::Singleton<Ogre::LogManager>::Singleton()::__PRETTY_FUNCTION__ 00307b20 r Ogre::Singleton<Ogre::LogManager>::~Singleton()::__PRETTY_FUNCTION__
>From nm manual:
--------------
If lowercase, the symbol is local; if uppercase, the symbol is global (external). "B" The symbol is in the uninitialized data section (known as BSS).
# PythonOgre nm _ogre_.so ================== 01f1115c t global constructors keyed to _Z38register_SingletonArchiveManager_classv 01f10c92 T register_SingletonArchiveManager_class() 029b37e0 V guard variable for boost::python::converter::detail::registered_base<Ogre::Singleton<Ogre::Arc hiveManager> const U Ogre::ArchiveManager::getSingleton() U Ogre::ArchiveManager::getSingletonPtr() 01f11182 W Ogre::Singleton<Ogre::ArchiveManager>::getSingleton() U Ogre::Singleton<Ogre::ArchiveManager>::ms_Singleton 01f111d0 W Ogre::Singleton<Ogre::ArchiveManager>::getSingletonPtr() 01f11256 W boost::detail::sp_counted_impl_pd<Ogre::Singleton<Ogre::ArchiveManager>*, boost::python::converter::shared_ptr_deleter>::get_deleter(std::type_info const&)
========== 003c8c18 b _ZN4Ogre9SingletonINS_14ArchiveManagerEE12ms_SingletonE (formatted) 003c8c18 b Ogre::Singleton<Ogre::ArchiveManager>::ms_Singleton
Since it also occuring with pyogre it's probaly a build problem on my end. I'm going to try a fresh install of everything on another computer unless anyone has any ideas.
On Apr 20, 1:23 pm, "Andy Miller" <nzmill...@gmail.com> wrote:
> Can you confirm it is only this one singleton that fails... > Thanks > Andy
> On 20/04/07, dermont <dermontg...@gmail.com> wrote:
> > typo: > > >> compiling pygccxml(with visiblity flags on/off) to no avail > > compiling python-ogre(with visiblity flags on/off) to no avail
> > On Apr 20, 12:14 pm, dermont <dermontg...@gmail.com> wrote: > > > >> shouli I try to compile ogre svn instead?
> > > No, you should stick with current version of ogre.
> > > >> wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
> > > Yes I think I said that above. The problem with singletons, for me, > > > initally cropped up on pyogre when I moved from ogre1.4.0RC1 to > > > ogre1.4. For me, compiling pyogre with gcc3.4.6 resolved it. The > > > "gcc3.4.6 ogre only compile" was only a hack to see if it resolved the > > > singleton problem ( I know I should go through the whole build cycle > > > gccxml, python-ogre gcc with gcc3 but it doesn't work)
> > > Three people (all Ubuntu) have posted this problem. Here gcc4.0.3 > > > 'nm' reports the singleton symbols as undefined. I've tried tracking > > > this down with various combinations of gcc - compiling ogre, gccxml , > > > running pygccxml (with visiblity flags on/off), compiling pygccxml > > > (with visiblity flags on/off) to no avail. I'm probably missing some > > > basic step here but I don't know what.
> > > As always you should wait for the offical developers to guide you. I > > > know I am.
> > > On Apr 20, 4:45 am, "kresimir.s...@gmail.com"
> > > <kresimir.s...@gmail.com> wrote: > > > > wait, isn't python ogre having prebrems with gcc3 as well as gcc4.1?
> > > > shouli I try to compile ogre svn instead?
> > > > > As a rough and ready test I recompiled ogre with gcc3.4.6 (no > > > > > visibility). I didn't do a full rebuild of the ogre module and the > > > > > modules imported fine.
I just got to this point as well, and that symbol is missing. Its quite odd, I am checking a very old binary I have and it has the same list of missing symbols. So the old _ogre_.so and new one both show this (for all singletons): U Ogre::Singleton<Ogre::LogManager>::ms_Singleton U Ogre::Singleton<Ogre::FontManager>::ms_Singleton
Still I did find on difference though, and this is probably the reason for the issue, here is some of the output of:
"nm libOgreMain.so | c++filt | grep -i ms_singleton" on the old Ogre binary that I got Python-Ogre working with: 003d9684 B Ogre::Singleton<Ogre::LogManager>::ms_Singleton 003d8e40 B Ogre::Singleton<Ogre::FontManager>::ms_Singleton
and here is the new one: 003c8a64 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton 003c80e0 b Ogre::Singleton<Ogre::FontManager>::ms_Singleton
So the symbols have switched from global to local, which is probably why the link if failing. Now to find what changed in the Ogre build files to cause this.
<kresimir.s...@gmail.com> wrote: > can someone who has built python-ogre please upload their binaries? so > I can at leest fool arround with python-ogre until this gets resolved
Hah, got it. After removing all the symbol visibility stuff and rebuilding Ogre I was able to import Ogre just fine. I think it might be fixable another way, by applying the fix show in the bug report dermont linked to. I will investigate if I have the time.
On Apr 21, 3:55 pm, Game_Ender <jli...@gmail.com> wrote:
> I just got to this point as well, and that symbol is missing. Its > quite odd, I am checking a very old binary I have and it has the same > list of missing symbols. So the old _ogre_.so and new one both show > this (for all singletons): > U Ogre::Singleton<Ogre::LogManager>::ms_Singleton > U Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> Still I did find on difference though, and this is probably the reason > for the issue, here is some of the output of:
> "nm libOgreMain.so | c++filt | grep -i ms_singleton" on the old Ogre > binary that I got Python-Ogre working with: > 003d9684 B Ogre::Singleton<Ogre::LogManager>::ms_Singleton > 003d8e40 B Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> and here is the new one: > 003c8a64 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton > 003c80e0 b Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> So the symbols have switched from global to local, which is probably > why the link if failing. Now to find what changed in the Ogre build > files to cause this.
> <kresimir.s...@gmail.com> wrote: > > can someone who has built python-ogre please upload their binaries? so > > I can at leest fool arround with python-ogre until this gets resolved
> I just got to this point as well, and that symbol is missing. Its > quite odd, I am checking a very old binary I have and it has the same > list of missing symbols. So the old _ogre_.so and new one both show > this (for all singletons): > U Ogre::Singleton<Ogre::LogManager>::ms_Singleton > U Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> Still I did find on difference though, and this is probably the reason > for the issue, here is some of the output of:
> "nm libOgreMain.so | c++filt | grep -i ms_singleton" on the old Ogre > binary that I got Python-Ogre working with: > 003d9684 B Ogre::Singleton<Ogre::LogManager>::ms_Singleton > 003d8e40 B Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> and here is the new one: > 003c8a64 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton > 003c80e0 b Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> So the symbols have switched from global to local, which is probably > why the link if failing. Now to find what changed in the Ogre build > files to cause this.
> <kresimir.s...@gmail.com> wrote: > > can someone who has built python-ogre please upload their binaries? so > > I can at leest fool arround with python-ogre until this gets resolved
>>I commented out the entire section in configre.in that dealt with symbol visibility
That was the first thing that I tried as well. The module imported ok and the demos ran fine. However for all demos I encountred a seg fault on program unloading (looked like on unloading the GL plugin). Can you confirm that this isn't the case with you. Ideally the visibility settings should be configurable in ogre.
On Apr 22, 5:08 am, Game_Ender <jli...@gmail.com> wrote:
> Oh, by stuff I mean I commented out the entire section in configre.in > that dealt with symbol visibility.
> On Apr 21, 3:55 pm, Game_Ender <jli...@gmail.com> wrote:
> > I just got to this point as well, and that symbol is missing. Its > > quite odd, I am checking a very old binary I have and it has the same > > list of missing symbols. So the old _ogre_.so and new one both show > > this (for all singletons): > > U Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > U Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > Still I did find on difference though, and this is probably the reason > > for the issue, here is some of the output of:
> > "nm libOgreMain.so | c++filt | grep -i ms_singleton" on the old Ogre > > binary that I got Python-Ogre working with: > > 003d9684 B Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > 003d8e40 B Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > and here is the new one: > > 003c8a64 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > 003c80e0 b Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > So the symbols have switched from global to local, which is probably > > why the link if failing. Now to find what changed in the Ogre build > > files to cause this.
> > <kresimir.s...@gmail.com> wrote: > > > can someone who has built python-ogre please upload their binaries? so > > > I can at leest fool arround with python-ogre until this gets resolved
> >>I commented out the entire section in configre.in that dealt with symbol visibility
> That was the first thing that I tried as well. The module imported ok > and the demos ran fine. However for all demos I encountred a seg fault > on program unloading (looked like on unloading the GL plugin). Can you > confirm that this isn't the case with you. Ideally the visibility > settings should be configurable in ogre.
> On Apr 22, 5:08 am, Game_Ender <jli...@gmail.com> wrote:
> > Oh, by stuff I mean I commented out the entire section in configre.in > > that dealt with symbol visibility.
> > On Apr 21, 3:55 pm, Game_Ender <jli...@gmail.com> wrote:
> > > I just got to this point as well, and that symbol is missing. Its > > > quite odd, I am checking a very old binary I have and it has the same > > > list of missing symbols. So the old _ogre_.so and new one both show > > > this (for all singletons): > > > U Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > U Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > Still I did find on difference though, and this is probably the reason > > > for the issue, here is some of the output of:
> > > "nm libOgreMain.so | c++filt | grep -i ms_singleton" on the old Ogre > > > binary that I got Python-Ogre working with: > > > 003d9684 B Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > 003d8e40 B Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > and here is the new one: > > > 003c8a64 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > 003c80e0 b Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > So the symbols have switched from global to local, which is probably > > > why the link if failing. Now to find what changed in the Ogre build > > > files to cause this.
> > > On Apr 20, 7:06 pm, "kresimir.s...@gmail.com"
> > > <kresimir.s...@gmail.com> wrote: > > > > can someone who has built python-ogre please upload their binaries? so > > > > I can at leest fool arround with python-ogre until this gets resolved
> Ok I just recompiled with the above change you suggested, no seg > faults and everything works OK. Thanks.
> On Apr 22, 1:07 pm, dermont <dermontg...@gmail.com> wrote:
> > >>I commented out the entire section in configre.in that dealt with symbol visibility
> > That was the first thing that I tried as well. The module imported ok > > and the demos ran fine. However for all demos I encountred a seg fault > > on program unloading (looked like on unloading the GL plugin). Can you > > confirm that this isn't the case with you. Ideally the visibility > > settings should be configurable in ogre.
> > On Apr 22, 5:08 am, Game_Ender <jli...@gmail.com> wrote:
> > > Oh, by stuff I mean I commented out the entire section in configre.in > > > that dealt with symbol visibility.
> > > > I just got to this point as well, and that symbol is missing. Its > > > > quite odd, I am checking a very old binary I have and it has the same > > > > list of missing symbols. So the old _ogre_.so and new one both show > > > > this (for all singletons): > > > > U Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > > U Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > > Still I did find on difference though, and this is probably the reason > > > > for the issue, here is some of the output of:
> > > > "nm libOgreMain.so | c++filt | grep -i ms_singleton" on the old Ogre > > > > binary that I got Python-Ogre working with: > > > > 003d9684 B Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > > 003d8e40 B Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > > and here is the new one: > > > > 003c8a64 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > > 003c80e0 b Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > > So the symbols have switched from global to local, which is probably > > > > why the link if failing. Now to find what changed in the Ogre build > > > > files to cause this.
> > > > On Apr 20, 7:06 pm, "kresimir.s...@gmail.com"
> > > > <kresimir.s...@gmail.com> wrote: > > > > > can someone who has built python-ogre please upload their binaries? so > > > > > I can at leest fool arround with python-ogre until this gets resolved
> No problem, now if only my app would work right..., currently chasing > down a problem in OgreNewt.
> On Apr 22, 2:11 am, dermont <dermontg...@gmail.com> wrote:
> > Ok I just recompiled with the above change you suggested, no seg > > faults and everything works OK. Thanks.
> > On Apr 22, 1:07 pm, dermont <dermontg...@gmail.com> wrote:
> > > >>I commented out the entire section in configre.in that dealt with symbol visibility
> > > That was the first thing that I tried as well. The module imported ok > > > and the demos ran fine. However for all demos I encountred a seg fault > > > on program unloading (looked like on unloading the GL plugin). Can you > > > confirm that this isn't the case with you. Ideally the visibility > > > settings should be configurable in ogre.
> > > > > I just got to this point as well, and that symbol is missing. Its > > > > > quite odd, I am checking a very old binary I have and it has the same > > > > > list of missing symbols. So the old _ogre_.so and new one both show > > > > > this (for all singletons): > > > > > U Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > > > U Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > > > Still I did find on difference though, and this is probably the reason > > > > > for the issue, here is some of the output of:
> > > > > "nm libOgreMain.so | c++filt | grep -i ms_singleton" on the old Ogre > > > > > binary that I got Python-Ogre working with: > > > > > 003d9684 B Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > > > 003d8e40 B Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > > > and here is the new one: > > > > > 003c8a64 b Ogre::Singleton<Ogre::LogManager>::ms_Singleton > > > > > 003c80e0 b Ogre::Singleton<Ogre::FontManager>::ms_Singleton
> > > > > So the symbols have switched from global to local, which is probably > > > > > why the link if failing. Now to find what changed in the Ogre build > > > > > files to cause this.
> > > > > <kresimir.s...@gmail.com> wrote: > > > > > > can someone who has built python-ogre please upload their binaries? so > > > > > > I can at leest fool arround with python-ogre until this gets resolved
I comented out the visibility part in ogrenew/configure.in and recompiled ogre with scons, but the unresolved external still remains? Have I done something wrong? is that the correct file I should coment out the visibility stuff from?
You don't to recompile Python-Ogre, you need to recompilie Ogre itself. So, go to configure.in and comment out the lines about visibility (32-53 for me) then run "./bootstrap", "./configure <your other options>", "make; make install". Then just try python-ogre again. No need to spend all that time recompiling the wrapper. There is no scons involved here.
<kresimir.s...@gmail.com> wrote: > I comented out the visibility part in ogrenew/configure.in and > recompiled ogre with scons, but the unresolved external still remains? > Have I done something wrong? is that the correct file I should coment > out the visibility stuff from?
a new issue: RuntimeError: DynamicModule::DynamicModule - Failed to load module 'libCEGUIExpatParser.so': /usr/lib/libCEGUIExpatParser.so: undefined symbol: _ZTIN5CEGUI9XMLParserE
I assume the solution is similar: recompile cegui without visibility?
