Sounds like your linux system is a little strange -- typically you create a symbolic link that manages this (so you can change versions without changing header files)..
On Apr 18, 3:40 am, "Lakin Wecker" <lakin.wec...@gmail.com> wrote:
> On 4/17/07, Andy Miller <nzmill...@gmail.com> wrote:
>
>
>
> > Sounds like your linux system is a little strange -- typically you create
> > a symbolic link that manages this (so you can change versions without
> > changing header files)..
>
> Actually, that's only done on some linux systems. That's because upgrading
> versions can cause version incompatibilities. On linux, the typical way to
> discover the needed compilation paths is to use pkgconfig and ask for the
> include path of a particular library which matches a version request.
>
> For instance for gtk+-2.0 on debian-based systems you would use the
> following command:
> pkg-config --cflags gtk+-2.0
> to discover these flags that are needed for compilation:
> -DPNG_NO_MMX_CODE -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
Ok sorry for butting in. The above post wasn't meant as a any slight
to Lakin (apologies in advance). Just the configure problems I
encountered with GTK.
>>> let's just stick to the matter at hand and that is succesfully compiling python-ogre on linux and getting those
'precious' binaries :)
Don't really know what you mean by the 'precious' binaries. The ogre/
cegui/ois should, with minor changes, compile quite easily. I'll be
sure to avoid repeating the above mistake,
On Apr 18, 4:48 am, "kresimir.s...@gmail.com"
Latin Wrecker, I was one of the other Linux users pushing for
autodetection, and I will get it when I build Python-Ogre again.
Believe it or not I have not had time to build Python-Ogre again since
I was the first to get it working a few months ago. Class and the
desperate need to finish my Python-Ogre based project has lead to me
to using windows version.
My Plan:
* Remove what ever remnants of reference to project CVS checkouts
there are (like needed to map into the ogre samples directory)
* Add pkg-config based autodetection with and scons configuration
module to check whether packages have been accurately detected.
* Make a simple example Posix config, that demonstrates overriding
the auto detected values.
I also need/want to support Mac users for the application I am
developing so you might see some Mac releated changes as well.
On Apr 17, 4:48 pm, "kresimir.s...@gmail.com"
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
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
SConstruct file:
----------------
CCFLAGS += ' -O3 -I./'
There may be issues with different versions of gcc, if you post your
problems I'm sure someone will help.
On Apr 18, 5:23 am, "kresimir.s...@gmail.com"
#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).
# This lets you call scons like: 'scons PROJECTS=ogre,cegui'
opts = Options(' custom.py')
opts.Add(ListOption('PROJECTS', 'Project to build wrappers for',
possible_projects, default_projects))
temp_env = Environment(options = opts)
tobuild = temp_env['PROJECTS']
I mean, I' like to avoid if anyhow possibile to go through the pain of
succesfully compiling and running python-ogre :)
I've compiled gcc4.0.4 and for the life of me I don't know how to
force scons to use it? I've installed it in /usr/local/gcc4 :?
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:
About packages: It will take a large effort, because Ogre itself
doesn't have update packages, and we use an unreleased and self
patched version of Boost. Does anyone have any ideas about reducing
package size?
On Apr 17, 11:33 pm, "rafaelrie...@gmail.com" <rafaelrie...@gmail.com>
wrote:
## Use custom compilier if wanted (things like ccache)
if hasattr(environment, 'cxx_compiler'):
_env['CXX'] = 'g++-4.0'
if hasattr(environment, 'cc_compiler'):
_env['CC'] = 'gcc-4.0 '
OgreOde
-----------
1.1) Path issue with Path issue with python_ogreode.h
Edited ogreode/python_ogreode_aliases.h
//#include "..\ogre\python_ogre_aliases.h"
#include "../ogre/python_ogre_aliases.h"
1.2) Python Version String Error Compiling
Replaced the python version string in ogreode/generate_code.py
with the one from
ogre/generate_code.py
##environment.ogreode.version
## , 'python_version' : '"%s"' %
sys.version } )
environment.ogre.version.replace("\n", "\\\n")
, 'python_version' : '"%s"' %
sys.version.replace("\n", "\\\n" ) } )
On Apr 18, 6:48 am, "Evan Metheny" <evanpm...@gmail.com> wrote:
> 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.
>
> #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).
>
> 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'
>
> > opts = Options('custom.py')
> > opts.Add(ListOption('PROJECTS', 'Project to build wrappers for',
> > possible_projects, default_projects))
> > temp_env = Environment(options = opts)
> > tobuild = temp_env['PROJECTS']
>
> 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?
>
kreso@thor:/data/python-ogre/python-ogre/demos/ogre$ python
Demo_SkyBox.py
Traceback (most recent call last):
File "Demo_SkyBox.py", line 12, in ?
import ogre.renderer.OGRE as ogre
File "/usr/lib/python2.4/site-packages/ogre/renderer/OGRE/
__init__.py", line 6, in ?
from _ogre_ import *
ImportError: /usr/lib/python2.4/site-packages/ogre/renderer/OGRE/
_ogre_.so: undefined symbol:
_ZN4Ogre9SingletonINS_14ArchiveManagerEE12ms_SingletonE
what's wrong ???
I compiled cegui, ogre and ois with scons (no ode or similar)
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.
>
> 2007/4/18, Irish <drummingpar...@gmail.com>:
I belive this may be (?) related to the newly implemented visibility
settings in ogre. From a search on the web I cam across this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17470
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.
shouli I try to compile ogre svn instead?
>> 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"
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::ArchiveManager>
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&)
Importing
======
ImportError: ./_ogre.so: undefined symbol:
_ZN4Ogre9SingletonINS_14ArchiveManagerEE12ms_SingletonE
>From Ogre (nm)
==========
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
>
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"
On Apr 21, 3:55 pm, Game_Ender <jli...@gmail.com> wrote:
On Apr 23, 11:12 am, "kresimir.s...@gmail.com"
one more thing, _ogre_.so and others are huge (~70 MB), how can I
scale that down? I've enabled -O3 optimisations in scons :?
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?
this error happens when running CEGUI demos in python-ogre
CMake Error: The source directory "/home/irish/Projects/python-ogre/
CEGUI-0.5.0/gccxml" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
boost-jam-3.1.13-1-linuxx86/LICENSE_1_0.txt
tar: boost-jam-3.1.13-1-linuxx86/LICENSE_1_0.txt: Cannot open:
Permission denied
tar: Skipping to next header
boost-jam-3.1.13-1-linuxx86/bjam
tar: Error exit delayed from previous errors
generating code
./python-ogre-installer: line 273: cd: python-ogre/code_generators/
ogre: No such file or directory
building python-ogre
./python-ogre-installer: line 292: cd: python-ogre: No such file or
directory
On May 12, 11:54 am, "Andy Miller" <nzmill...@gmail.com> wrote:
> There is some work going on with the script at the moment.. Your best bet
> is to run each line of the script individually to see where it breaks...
>
> I suspect the gccxml cvs download failed..
>
> Cheers
>
> Andy
>
I hope this helps someone else more than it helps me. I'm a bit
stuck.
and betagui doesn't exist yet. Anyone know where it's built, or
downloaded from?
On May 12, 11:38 pm, "Andy Miller" <nzmill...@gmail.com> wrote:
> Looks like it trying to install without superuser privledges (and it's not
> prompting you for a password???)..
>
> Can you try the new script that Renato just posted -- and if that fails wait
> a day and perhaps Jesse will have another update..
>
> I will be back into building under Linux in a couple of days (working
> through a snapshot build for Windows at the moment) so should be in a better
> position to help
>
> Cheers
> Andy
>
Sorry - my fault , will fix the svn
Andy
On 13/05/07, Irish <drummin...@gmail.com> wrote:
>
On May 13, 2:10 am, "Andy Miller" <nzmill...@gmail.com> wrote:
> Either remove betagui refernces from environment.py, or add the
> include path to pythonogreconfig_posix file - it doesn't matter what
> the entry is - just that it exists
>
> Sorry - my fault , will fix the svn
> Andy
>