Getting Python-Ogre to work on OS X Snow Leopard

50 views
Skip to first unread message

Zectbumo

unread,
Oct 22, 2009, 3:50:45 AM10/22/09
to Python Ogre Developers
I would like to get Python-Ogre working on Snow Leopard. I tried to
use the BuildModule.py and it broke immediately with:
ValueError: list.index(x): x not in list

Looks like this project needs some help. First I would like to make
some modifications to the build script.

I would like to make changes like:
• Use curl instead of wget
• Use distutils to discover the python include and lib directories
• Update the download links
• Remove the --overwrite tar option
• Use Ogre-1.6.4 for the install instead of 1.6.1
• Update & cleanup the os x build instructions on the wiki
• Make the build work with the stock python2.6
• Build for the correct platform i386 or x86_64

Who would I coordinate with to make these modifications?

-alfred

sasha

unread,
Oct 22, 2009, 5:13:12 AM10/22/09
to python-ogre...@googlegroups.com
Hi Zectbumo,

i'm a snow leopard user,
i'm not a developper, i'm on this list from times .. hoping some one
in the future will be able to unstall python ogre on osx >= 10.5...
i'm really happy to ear the idea to have python-ogre working on snow
leopard
if you think can be usefull, i'm avaiable for any kind of test
providing build logs from a fresh snow leopard installation. or for
any test you need.

thanks!

Massimo.

Il giorno 22/ott/09, alle ore 09:50, Zectbumo ha scritto:

Ivan Vučica

unread,
Oct 22, 2009, 5:13:50 AM10/22/09
to python-ogre...@googlegroups.com
On Thu, Oct 22, 2009 at 09:50, Zectbumo <alf...@54.org> wrote:

I would like to get Python-Ogre working on Snow Leopard. I tried to
use the BuildModule.py and it broke immediately with:
ValueError: list.index(x): x not in list

I believe that Andy will need more info than that (e.g. a full backtrace) :-) 

 
Looks like this project needs some help. First I would like to make
some modifications to the build script.

I would like to make changes like:
  • Use curl instead of wget
  • Use distutils to discover the python include and lib directories
  • Update the download links
  • Remove the --overwrite tar option
  • Use Ogre-1.6.4 for the install instead of 1.6.1

These sound good to me, personally.
 
  • Update & cleanup the os x build instructions on the wiki

I did most of the verification and fixes on the OSXBuildV2 for revision 996. However I have a task of targetting Tiger and Leopard on i386 and ppc, and do that ASAP, so the entire check&fix was done with that in mind (that is, helping whoever needs PythonOgre to work now, immediately, without delay). If you can come up with better, cleaner instructions, perhaps it would be a good idea to start a new article and keep this as a reference on building from 996?
 
  • Make the build work with the stock python2.6
  • Build for the correct platform i386 or x86_64

Publishers demand PowerPC and 10.4 support, please don't forget about that. A universal binary would be far better than just i386 or just x86_64 or just PPC binary.

Who would I coordinate with to make these modifications?

Probably Andy :-)


--
Regards,

Ivan Vučica

Louis731

unread,
Oct 22, 2009, 11:43:15 AM10/22/09
to Python Ogre Developers
currently python ogre CAN work on leopard. I haven't tried snow
leopard yet, but I agree with Zectbumo, we need a fire and forget
package, preferably a MacPort one

Ivan Vučica

unread,
Oct 22, 2009, 12:56:29 PM10/22/09
to python-ogre...@googlegroups.com
On Thu, Oct 22, 2009 at 17:43, Louis731 <loui...@gmail.com> wrote:

currently python ogre CAN work on leopard.

Nobody mentioned Leopard ;-)
 
I haven't tried snow
leopard yet,
but I agree with Zectbumo, we need a fire and forget
package, preferably a MacPort one


What's wrong with Fink? :-)

I just want to point out that such a fire-and-forget package should be built with a lot of stuff in mind. There are several things that need tweaking on Mac OS X platform before a release for Mac can be called "stable".

* i386+PPC support. Arch-specific binaries are not (yet) acceptable.
* 10.4-10.6 support. 10.4 is minimum what publishers accept -- ergo, you can conclude that there's a lot of folks that wouldn't be able to play your game even if it's FLOSS unless you target a minimum of 10.4.
* Bugs. Fullscreen bug, anyone? It's easy to work around in C++, and since I did some work (see wiki), it should be easy to work around it in Python. But perhaps the wrapper itself should include the fix?

So a fire-and-forget package would be great ... after some of the aforementioned stuff is fixed. I've frozen the build I have at revision 996 since I can't afford to break anything or rebuild anything, so I don't know if Andy did any work on Mac port, but what I'm mentioning above is either what most developers would have trouble with, or what publishers and players would mind.

If I could diverge my concentration from the hyper-essential-work-at-hand, and if I actually had a private Mac sufficiently powerful to compile PythonOgre, I would invest additional  time in producing high-quality patches for inclusion in PO, fixing stuff and making stuff easier for people to use. Of course, if the quality of my patches would be acceptable.


That said, I'll see if I can make the basic packaging available; only ogre and ois are built, and I'd package only the frameworks and .../site-packages/ogre, with site-packages in one version for ppc, and one for i386. No promises though.
--
Regards,

Ivan Vučica

Andy Miller

unread,
Oct 23, 2009, 1:18:11 AM10/23/09
to python-ogre...@googlegroups.com
I would be VERY happy to take any fixes/changes/improvements etc relating to the Mac (or Linux for that matter) build.  

My current schedule won't allow me to look at the mac version my self for at least a couple of weeks:( 

The changes are likley to be in environment.py and PythonOgreConfig_posix.py so I'm happy to have you send updated version of these to me and I'll merge in the changes, or send me diffs if that's easier.

I did also look (a while back) at releasing a binary build for the Mac and I don't think it's that difficult -- only 'issue' was in getting the modules to link with a relative path (RPATH) for the library loading - if we can make this happen then the user doesn't have to mess with putting libraries in a system area or using ldconfig etc.    I recall I was able to get this to work with an absolute path but not a relative one, however hadn't tried it with everything packaged correctly so any work here would be appreciated..

Many Thanks
Andy



2009/10/23 Ivan Vučica <ivu...@gmail.com>

Zectbumo

unread,
Oct 23, 2009, 4:15:47 AM10/23/09
to Python Ogre Developers
Andy,

Great, I submitted some artifacts with patches on sourceforge. I still
have to patch ogre and ois builds, so more patches to come.

-alfred

On Oct 22, 10:18 pm, Andy Miller <nzmill...@gmail.com> wrote:
> I would be VERY happy to take any fixes/changes/improvements etc relating to
> the Mac (or Linux for that matter) build.
> My current schedule won't allow me to look at the mac version my self for at
> least a couple of weeks:(
>
> The changes are likley to be in *environment.py* and *
> PythonOgreConfig_posix.py* so I'm happy to have you send updated version of
> these to me and I'll merge in the changes, or send me diffs if that's
> easier.
>
> I did also look (a while back) at releasing a binary build for the Mac and I
> don't think it's that difficult -- only 'issue' was in getting the modules
> to link with a relative path (RPATH) for the library loading - if we can
> make this happen then the user doesn't have to mess with
> putting libraries in a system area or using ldconfig etc.    I recall I was
> able to get this to work with an absolute path but not a relative one,
> however hadn't tried it with everything packaged correctly so any work here
> would be appreciated..
>
> Many Thanks
> Andy
>
> 2009/10/23 Ivan Vučica <ivuc...@gmail.com>

Ivan Vučica

unread,
Oct 23, 2009, 7:35:12 AM10/23/09
to python-ogre...@googlegroups.com
On Fri, Oct 23, 2009 at 07:18, Andy Miller <nzmi...@gmail.com> wrote:
I did also look (a while back) at releasing a binary build for the Mac and I don't think it's that difficult -- only 'issue' was in getting the modules to link with a relative path (RPATH) for the library loading - if we can make this happen then the user doesn't have to mess with putting libraries in a system area or using ldconfig etc.    I recall I was able to get this to work with an absolute path but not a relative one, however hadn't tried it with everything packaged correctly so any work here would be appreciated..

py2app appears to fix up the libraries to use relative paths using macholib. Perhaps that should be looked into?
--
Regards,

Ivan Vučica

Zectbumo

unread,
Oct 24, 2009, 3:41:53 PM10/24/09
to Python Ogre Developers
So, I got up to the instruction:
python python-ogre/BuildModule.py -r -b ois ogre
in the wiki page http://wiki.python-ogre.org/index.php/OSXBuildV2
and I got this in the log.out:
GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file
OISEffect.cpp)

So I could try to change my gcc to use 4.0 or change the SDK to use
10.6. I'm going to go down the SDK 10.6 route. I changed my SDK to
10.6 by hard coding -sdk maosx10.6 after all the xcodebuild commands.
OIS and Ogre frameworks seem to compile okay now.

What would be the proper way to change the SDK that xcodebuild uses in
the BuildModule script? Is there already a PythonOgreConfig setting I
can set for this? Or should I go ahead and make a Config.MAC_SDK that
I can set to macosx10.6 and it will append it to the xcodebuild
instructions? I see a SDK=False, can I use that, or is that used for
something else?

Also, Is there any trouble anyone can see with mixing SDK versions?
For example if the CEGUI.framework was built using the macosx10.4u
would it matter later on that I built Ogre with macosx10.6?

-alfred

Ivan Vučica

unread,
Oct 24, 2009, 6:20:32 PM10/24/09
to python-ogre-developers
On Sat, Oct 24, 2009 at 21:41, Zectbumo <alf...@54.org> wrote:

So, I got up to the instruction:
python python-ogre/BuildModule.py -r -b ois ogre
in the wiki page http://wiki.python-ogre.org/index.php/OSXBuildV2
and I got this in the log.out:
GCC 4.2 is not compatible with the Mac OS X 10.4 SDK (file
OISEffect.cpp)

Wow, you learn something new every day :-O
 

So I could try to change my gcc to use 4.0 or change the SDK to use
10.6. I'm going to go down the SDK 10.6 route. I changed my SDK to
10.6 by hard coding -sdk maosx10.6 after all the xcodebuild commands.
OIS and Ogre frameworks seem to compile okay now.

You intend to build for 10.6 only? Wow, that's somewhat limiting your audience, no? I'd rather somehow set CC and CXX to older gcc/g++ than limit myself to 10.6 audience only.
 
What would be the proper way to change the SDK that xcodebuild uses in
the BuildModule script?

Since what the build system on mac does appears to be calling xcode's command line build tool to do its dirty work, I guess best way would be to either change the xcode project, or do what you did.
 
Is there already a PythonOgreConfig setting I
can set for this? Or should I go ahead and make a Config.MAC_SDK that
I can set to macosx10.6 and it will append it to the xcodebuild
instructions? I see a SDK=False, can I use that, or is that used for
something else?

All I know is that you will want to change the setting in PythonOgreConfig_posix.py, similar to what I described in OSXBuildV2 for getting 10.4 compatibility at later stage.
 

Also, Is there any trouble anyone can see with mixing SDK versions?
For example if the CEGUI.framework was built using the macosx10.4u
would it matter later on that I built Ogre with macosx10.6?

I smell possible trouble because of possibly differing versions of libstdc++. But I don't know.
 

Can you document your efforts by patching (in a clean way, please :-) ) OSXBuildV2 or creating OSXBuildV3? And, would you be so kind to try to get 10.4 compatibility later on, at some point?

--
Regards,

Ivan Vučica

Zectbumo

unread,
Oct 24, 2009, 9:48:34 PM10/24/09
to Python Ogre Developers


> You intend to build for 10.6 only? Wow, that's somewhat limiting
> your audience, no?

Well, my current audience is me, I just need to get this build to
work. I want to eventually have this as a configuration setting so
people have the option to choose.

> I smell possible trouble because of possibly differing versions of
> libstdc++. But I don't know.

Thanks for the heads up.

> Can you document your efforts by patching (in a clean way, please :-) )
> OSXBuildV2 or creating OSXBuildV3? And, would you be so kind to try to get
> 10.4 compatibility later on, at some point?
> --
> Regards,
>
> Ivan Vučica

Yes, I think I'll make an OSXBuildV3 page and document the install
procedure. I want my changes to be compatible with 10.4 but I don't
have a Tiger machine to check compatibility. So I would like to find
someone with Tiger to help me test my install procedure.

I submitted my patches I have so far to http://sourceforge.net/tracker/?group_id=186291&atid=916690
It's broken up into an issue at a time.

Is it possible to get a branch in SVN to work in instead?

-alfred

Andy Miller

unread,
Oct 25, 2009, 12:34:29 AM10/25/09
to python-ogre...@googlegroups.com
Suggest you save the patches until everything is working and then put
one entry on sourceforge for me to merge - and i won't get to this for
a week...

Andy
--
Sent from my mobile device

Zectbumo

unread,
Oct 26, 2009, 2:21:18 AM10/26/09
to Python Ogre Developers
Will do. I'll put it together all as one patch.

Zectbumo

unread,
Oct 26, 2009, 5:11:52 PM10/26/09
to Python Ogre Developers
Ok, I'm having problems compiling the ogre generated code using these
steps:
http://wiki.python-ogre.org/index.php/OSXBuild10.6

I get all the way to step 4 and the build fails. I had to fall back to
using SDK 10.5 since I couldn't get the Ogre framework to build using
the 10.6 SDK.

I can generate (-g) the ogre and ois code, but ogre won't compile (-
c).

I'm doing:

python python-ogre/BuildModule.py -c ogre

Many files compile, but the last g++ line in log.out is:
g++ -o build_dir_2.6/ogre_1.6.1/UserDefinedObject.pypp.os -c -I./ -O3 -
dynamic -fPIC -DBOOST_PYTHON_NO_PY_SIGNATURES -
DBOOST_PYTHON_MAX_ARITY=19 -ftemplate-depth-128 -finline-functions -
Wno-inline -Wall -no-cpp-precomp -gdwarf-2 -DNDEBUG -include strings.h
-include Carbon/Carbon.h -I/Users/alfred/Downloads/development/python-
ogre/generated/ogre_1.6.1 -arch i386 -D__ASSERTMACROS__ -F/Users/
alfred/Library/Frameworks -fPIC -I/Users/alfred/Downloads/development/
root/usr/include -I/Users/alfred/Downloads/development/ogre/OgreMain/
include -I/System/Library/Frameworks/Python.framework/Versions/2.6/
include/python2.6 -I/System/Library/Frameworks/Python.framework/
Versions/2.6/include/python2.6 -Ibuild_dir_2.6/ogre_1.6.1/None -
Igenerated/ogre_1.6.1/None generated/ogre_1.6.1/
UserDefinedObject.pypp.cpp


I got this error:
/System/Library/Frameworks/Python.framework/Versions/2.6/include/
python2.6/pyconfig.h:561:1: warning: this is the location of the
previous definition
generated/ogre_1.6.1/UTFString.pypp.cpp: In function ‘void
register_UTFString_class()’:
generated/ogre_1.6.1/UTFString.pypp.cpp:1453: error: address of
overloaded function with no contextual type information
generated/ogre_1.6.1/UTFString.pypp.cpp:2698: error: address of
overloaded function with no contextual type information
generated/ogre_1.6.1/UTFString.pypp.cpp:3057: error: address of
overloaded function with no contextual type information
generated/ogre_1.6.1/UTFString.pypp.cpp:3701: error: address of
overloaded function with no contextual type information

and in many places (about 23 errors) similar to this:
/Users/alfred/Downloads/development/root/usr/include/boost/python/
operators.hpp:212: error: ambiguous overload for ‘operator+’ in ‘l +
r’
/Users/alfred/Downloads/development/root/usr/include/boost/python/
operators.hpp:301: error: ambiguous overload for ‘operator+=’ in ‘l.
boost::python::back_reference<T>::get [with T =
Ogre::UTFString::_const_fwd_iterator&]() += r’

and about 500 warnings of the same kind:
/Users/alfred/Downloads/development/ogre/OgreMain/include/config.h:
27:1: warning: "HAVE_SNPRINTF" redefined

Any ideas how to move forward?

-alfred

Zectbumo

unread,
Oct 27, 2009, 4:56:53 AM10/27/09
to Python Ogre Developers
Ok, I put aside trying to get 10.6 to build. I installed Leopard and
tried to follow the instructions to get this build to work. I got all
the way to Step 4 in
http://wiki.python-ogre.org/index.php/OSXBuild10.5
And this time I was successful in compiling the ois generated code.
But, I still have trouble compiling the ogre generated code. This
problem looks different and seems easier to fix.

This was at the very end of the compiling stage where the 728 files of
ogre compiled generated code get linked. The log.out file says:
Undefined symbols:
"Ogre::ResourceGroupManager::_notifyWorldGeometryPrepareStageStarted
(std::basic_string<char, std::char_traits<char>, std::allocator<char>
> const&)", referenced from:

__ZN4Ogre20ResourceGroupManager39_notifyWorldGeometryPrepareStageStartedERKSs
$non_lazy_ptr in ResourceGroupManager.pypp.os
"Ogre::ResourceGroupManager::_notifyWorldGeometryPrepareStageEnded
()", referenced from:

__ZN4Ogre20ResourceGroupManager37_notifyWorldGeometryPrepareStageEndedEv
$non_lazy_ptr in ResourceGroupManager.pypp.os
ld: symbol(s) not found
collect2: ld returned 1 exit status
scons: *** [build_dir_2.5/ogre_1.6.1/ogre] Error 1

I looked into the file ogre/OgreMain/include/
OgreResourceGroupManager.h and found this:
void _notifyWorldGeometryPrepareStageStarted(const String&
description);
and
void _notifyWorldGeometryPrepareStageEnded(void);

but I don't find these methods implemented anywhere in the .cpp files.

I don't know what exactly this means, so can someone shed some light
here?

-alfred

Andy Miller

unread,
Oct 27, 2009, 5:39:38 PM10/27/09
to python-ogre...@googlegroups.com
Take a look at code_generators/ogre/generate_code.py -- line 316-318 probably need to be uncommented (and run the generate code step again)...

Guess I can leave them in and stick a try/except block around them so it works with all versions...

Andy

2009/10/27 Zectbumo <alf...@54.org>

Zectbumo

unread,
Oct 30, 2009, 4:27:56 AM10/30/09
to Python Ogre Developers
Thanks Andy, that worked. I was able to make it all the way through
Step 4 and added a Test Section which confirms my build works.

These instructions are ready to be reviewed and tested for building on
Leopard:
http://wiki.python-ogre.org/index.php/OSXBuild10.5

Now that I got this working it gives me a good starting point for
trying to get this working on Snow Leopard.

-alfred

Zectbumo

unread,
Nov 2, 2009, 1:50:27 AM11/2/09
to Python Ogre Developers
Ok, now that I have 10.5 working I went back to 10.6. I have just
about everything working in 10.6. The only thing I don't have working
is that the generated code is not being generated like in 10.5. I'll
start with the generating OIS code problems.

This is what is going on in generated/ois_1.0:
_ois_.main.cpp has this line:
#include "__type.pypp.hpp"

when it should have this line instead:
#include "vector_less__OIS_scope_Vector3__greater_.pypp.hpp"

I tried to use python2.5 instead of python2.6 but that didn't seem to
change anything. Is there any ideas how this could be happening?

-alfred

Andy Miller

unread,
Nov 2, 2009, 4:37:04 AM11/2/09
to python-ogre...@googlegroups.com
How about sending me the log from the code generation along with the generated files them selves (in a zip or tar file)

ie from code_generators/ois run "python generate_code.py >1 2>&1"

Send me '1' plus everything from generated/ois_1.0

Thanks
Andy

2009/11/2 Zectbumo <alf...@54.org>

Mark Paschal

unread,
Nov 3, 2009, 12:16:42 PM11/3/09
to Python Ogre Developers
Hi,

On Nov 1, 10:50 pm, Zectbumo <alf...@54.org> wrote:
> Ok, now that I have 10.5 working I went back to 10.6.

Oh, wow, thanks so much! I've been trying to build python-ogre on 10.5
off and on for a week, and could not for the life of me get boost to
build. With your patch in the wiki directions it totally builds for
me.

Thanks, and good luck with 10.6.


Mark Paschal
mark...@markpasc.org
Reply all
Reply to author
Forward
0 new messages