Latest Linux Build

[Andy Miller]

Team

I've updated the SVN and wiki build instructions for Linux with the following changes

• Where possible using standard Linux packages for the support libraries
• Exceptions to this are Nvidia CG and gccxml.  Both "probably" work OK with the standard packages however they are rather old and we know of bugs in both so suggest updating them as part of the Python-Ogre build
• Boost Python is now included in the SVN and will be built (and installed) as part of the build instructions (it's the "boost_python" module) - as an aside we also build the latest boost data-time and thread modules but intentionally don't install them on Linux (where we are using the standard packages for these modules) -- however we need them on Windows hence build then all.
• We use the --usesytem option on most of the build to force all libraries into standard linux places (thanks to Ben for implementing this some time back)
• The Ogre, OIS and CEGUI source is retrieved and built for you (as before), however these are not patched in any way so if you already have them installed then they can be used -- I would expect that once up to date Linux packages become available for these then we will use the package system to retrieve them instead.
• Only Ogre and OIS have currently been tested -- CEGUI is next with more to follow...
• PythonOgreConfig_system.py is used for the config settings when using the --usesystem option just in case you need to tweak anything.

Let me know if you have any issues and please update the wiki as you see appropriate.

Andy

[Steve Freitas]

Cool!

Okay, here's how far I've gotten. I'm building without --usesystem.

1) I had to change struct Ogre::EdgeListBuilder::vectorLess in OgreEdgeListBuilder.h to be public.

2) In python-ogre/environment.py I had to change line 637 to read: lib='libboost_python'

3) The bindings to CEGUI wouldn't build for me, I got the same error as Enrico.

The native Ogre demos run great.

When running Demo_Grass.py I got this error:

OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library /home/steve/dev/sim/src171/root/usr/lib/OGRE/Plugin_CgProgramManager.  System Error: /home/steve/dev/sim/src171/root/usr/lib/OGRE/Plugin_CgProgramManager.so: cannot open shared object file: No such file or directory in DynLib::load at /home/steve/dev/sim/src171/ogre/OgreMain/src/OgreDynLib.cpp (line 91)

I couldn't find Plugin_CgProgramManager.so anywhere, but I did find root/usr/lib64/libCg.so and root/usr/lib64/libCgGL.so. Adding root/usr/lib64 to LD_LIBRARY_PATH didn't help. I don't recall this happening last time I tried it... Where in the process does this module get built?

Steve

--
You received this message because you are subscribed to the Google Groups "Python Ogre Developers" group.
To post to this group, send email to python-ogre...@googlegroups.com.
To unsubscribe from this group, send email to python-ogre-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/python-ogre-developers?hl=en.

[Enrico Zschemisch]

Hi,

Am Freitag 19 Februar 2010 08:54:27 schrieb Steve Freitas:
> 1) I had to change struct Ogre::EdgeListBuilder::vectorLess in
> OgreEdgeListBuilder.h to be public.

Yeah, had the same.

> 2) In python-ogre/environment.py I had to change line 637 to read:
> lib='libboost_python'

Mhm, I used my distribution's boost-python, which worked.

> I couldn't find Plugin_CgProgramManager.so anywhere, but I did find
> root/usr/lib64/libCg.so and root/usr/lib64/libCgGL.so. Adding
> root/usr/lib64 to LD_LIBRARY_PATH didn't help. I don't recall this
> happening last time I tried it... Where in the process does this module
> get built?

This library is part of Ogre and should have been built with/by Ogre. If it is
not there the Ogre build system could somehow not find your Cg.

Regards,
Enrico

[Enrico Zschemisch]

Hi Andy,

Am Freitag 19 Februar 2010 04:38:53 schrieb Andy Miller:
> - The Ogre, OIS and CEGUI source is retrieved and built for you (as

> before), however these are not patched in any way so if you already have

there are at least two people where Ogre needs patching. How about you and
everbody else?

Regards,
Enrico

[Steve Freitas]

Ahh. Now I remember last time I had installed the Debian package nvidia-cg-toolkit. I'll install that now and see if it builds it.

Steve

[Steve Freitas]

On Fri, 2010-02-19 at 10:38 +0100, Enrico Zschemisch wrote:

This library is part of Ogre and should have been built with/by Ogre. If it is 
not there the Ogre build system could somehow not find your Cg.

Okay, I re-installed nvidia-cg-toolkit and that did it, guess the build script isn't finding what it needs internally. That needs a patch somewhere, not sure where though! :-D Got a bunch of the demos running now, will give a full report tomorrow.

Steve

[Andy Miller]

OK - so I'm ONLY testing with --usesystem so if you are following the latest instructions and are not using --usesystem you are going to have to mess with library paths to ensure you are pulling the right libraries..

What version of gccxml are you using (are you building it as part of Python-Ogre or using a package/system version?)

Oh -- and what version of Python are you using?? Perhaps you are using 2.5 which is why we are seeing some small differences ??

Under Linux (Ubuntu 32 bit) 'vectorLess' is not exposed so I don't understand why it would be on your systems -- however it's easy enough to fix in the code generation stage by simply excluding it -- which I've done in the latest SVN (so you don't need to patch Ogre)

Don't understand the issue with cg (assuming you installed it as part of the Python-Ogre install) -- could you run

python python-ogre/BuildModule.py -r -b cg --usesystem -v >log 2>&1

and see whats going on (in 'log')

Thanks

Andy

--

[Steve Freitas]

On Fri, 2010-02-19 at 20:38 +0800, Andy Miller wrote:

OK - so I'm ONLY testing with --usesystem so if you are following the latest instructions and are not using --usesystem you are going to have to mess with library paths to ensure you are pulling the right libraries..

Okay. I'm testing without it because I don't want to clutter my system paths up while I'm experimenting with this. I'm sure I won't be the only one who wants to build this way, so I'd like to get it working smoothly. It's probably causing the issue with Cg, see below...

What version of gccxml are you using (are you building it as part of Python-Ogre or using a package/system version?)

I'm building it as part of Python-Ogre, it's not installed on my system otherwise.

Oh -- and what version of Python are you using?? Perhaps you are using 2.5 which is why we are seeing some small differences ??

Yep, 2.5. There are some substantial libraries that Debian hasn't moved to 2.6 yet, AFAICT. I expect that'll change as we move closer to the release of Squeeze.

Under Linux (Ubuntu 32 bit) 'vectorLess' is not exposed so I don't understand why it would be on your systems -- however it's easy enough to fix in the code generation stage by simply excluding it -- which I've done in the latest SVN (so you don't need to patch Ogre)

Okay, thanks. I'll do a full rebuild just to verify the fix works here too.

Don't understand the issue with cg (assuming you installed it as part of the Python-Ogre install) -- could you run

python python-ogre/BuildModule.py -r -b cg --usesystem -v >log 2>&1

and see whats going on (in 'log')

Attached (log_cg_build.txt). I uninstalled the nvidia-cg-toolkit package beforehand. Didn't see a smoking gun in there so I did the same thing for the ogre build (log_ogre_build_wo_cg.txt). That one may shed a bit more light, looks like it's looking in a system path when it shouldn't. I also tried again after reinstalling nvidia-cg-toolkit (log_ogre_build_with_cg.txt).

Thanks!

Steve

[Andy Miller]

Great -- and did I read a previous message correctly in that you now have demos working on 64bit Linux with Ogre 1.7 ???

Thanks

Andy

--

[Andy Miller]

With regards to the CG lib it looks like a bug in the cmake scripts for Ogre..  They are looking for the cg lib in /usr/lib whereas the Nvidia files are installed in /usr/lib64..

What is the 'correct' behaviour for a 64 bit system?  Should we change the Python-Ogre install script to copy the CG libs from /usr/lib64 to /usr/lib OR  (perhaps 'and') do we report this as a bug to the Ogre development team?

Thanks

Andy

On 20 February 2010 05:04, Steve Freitas <sfl...@ihonk.com> wrote:

--

[Steve Freitas]

On Sat, 2010-02-20 at 08:42 +0800, Andy Miller wrote:

With regards to the CG lib it looks like a bug in the cmake scripts for Ogre..  They are looking for the cg lib in /usr/lib whereas the Nvidia files are installed in /usr/lib64..

Or, in my case when nvigia-cg-toolkit wasn't installed, they lived in ~/development/root/usr/lib64. If we're going to allow the user to pull down and build Cg without --usesystem, we need to find it in a place like that.

What is the 'correct' behaviour for a 64 bit system?  Should we change the Python-Ogre install script to copy the CG libs from /usr/lib64 to /usr/lib OR  (perhaps 'and') do we report this as a bug to the Ogre development team?

The correct behavior is going to be up to the distribution maintainer of the package in question, I guess. Not sure what the policy is. A look into my system's /usr/lib, /usr/lib64 AND /usr/lib32 yields a shedload of libs. Maybe the right answer is for it to look in lib64 first, then lib32, then lib.

Steve

[Steve Freitas]

On Sat, 2010-02-20 at 08:37 +0800, Andy Miller wrote:

Great -- and did I read a previous message correctly in that you now have demos working on 64bit Linux with Ogre 1.7 ???

Yep! Success! Thanks!

Under Linux (Ubuntu 32 bit) 'vectorLess' is not exposed so I don't understand why it would be on your systems -- however it's easy enough to fix in the code generation stage by simply excluding it -- which I've done in the latest SVN (so you don't need to patch Ogre)

Okay, thanks. I'll do a full rebuild just to verify the fix works here too.

It died here again during "python python-ogre/BuildModule.py -g -e -c ogre", thusly:

/home/steve/dev/sim/src172/root/usr/include/OGRE/OgreEdgeListBuilder.h: In function ‘void register_mapVector3_class()’:
/home/steve/dev/sim/src172/root/usr/include/OGRE/OgreEdgeListBuilder.h:227: error: ‘struct Ogre::EdgeListBuilder::vectorLess’ is protected
generated/ogre_1.7.0RC1/mapVector3.pypp.cpp:12: error: within this context
scons: *** [build_dir_2.5/ogre_1.7.0RC1/mapVector3.pypp.os] Error 1

I did a fresh download. Did you check in those changes after you sent that email?

Steve

[Andy Miller]

OK update from SVN and try again -- also if it fails can you send me the compile log file -- basically I want to know what file it was in when it failed (suspect it was mapVector3)..

Thanks

Andy

[Steve Freitas]

By the way, just wanted to mention that I've installed from scratch again using the LinuxBuildV4 instructions and I no longer have the problem with vectorLess. Not sure why it popped up once more before now, but I probably hadn't sanitized my build environment sufficiently. Thanks again for all the help!

Now I'm going to try building some modules...

Steve

[Andy Miller]

Only Ogre and OIS are currently 'clean' -- I'm sure others will work however I won't get to do additional cleanup until next weekend..

Andy

[Enrico Zschemisch]

Hi,

Am Samstag, den 20.02.2010, 01:42 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:

> What is the 'correct' behaviour for a 64 bit system?

correct behaviour is to put the libraries into $PREFIX/lib64. However, on
my system /usr/lib is a symlink to /usr/lib64/

[Enrico Zschemisch]

Hi,

Am Samstag, den 20.02.2010, 02:08 +0100 schrieb Steve Freitas
<sfl...@ihonk.com>:

> A look
> into my system's /usr/lib, /usr/lib64 AND /usr/lib32 yields a shedload
> of libs. Maybe the right answer is for it to look in lib64 first, then
> lib32, then lib.

lib32 is the place for 32 bit libraries (needed to run 32 Bit applications
on a 64Bit system).

Regards,
Enrico