Building rev 1020 on Linux

[Ivan Vučica]

Hi,

I've ran an 'svn update' today, and I see that Linux Python-Ogre has been bumped to 1.6.4. As I've already mentioned, I'm using Ubuntu 8.04 LTS. This is being done precisely because it's LTS. I'm targetting only ogre, ois and cegui to be wrapped.

Patching with 1.6.1 patch now fails. Is there a 1.6.4 patch ready?

With GCC 4.2, which is 8.04's default, I'm still getting a problem with a member being protected as mentioned in 'Building rev 1018 on Linux'. This occurs in the compile-wrapper-code phase.

 With GCC 4.1, to which I switched, I'm now getting loads and loads of undefined references to STL string and STL allocator during the linking phase of compiling of native Ogre (that is, not the wrapper).

Excerpt:
...
OgreAnimation.cpp:(.text+0xf8c): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
.libs/OgreAnimation.o: In function `Ogre::Animation::~Animation()':
OgreAnimation.cpp:(.text+0x10d8): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
.libs/OgreAnimation.o:OgreAnimation.cpp:(.text+0x110e): more undefined references to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()' follow
.libs/OgreAnimation.o: In function `Ogre::Animation::getVertexTrack(unsigned short) const':
OgreAnimation.cpp:(.text+0x1fc8): undefined reference to `std::allocator<char>::allocator()'
OgreAnimation.cpp:(.text+0x2034): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
.......

and so on, ending with:

....
.libs/OgreFreeImageCodec.o:OgreFreeImageCodec.cpp:(.text._ZN4Ogre14FreeImageCodecD1Ev[Ogre::FreeImageCodec::~FreeImageCodec()]+0x2b): more undefined references to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()' follow
./.libs/libSSEsupport.a(libSSEsupport_la-OgreOptimisedUtilSSE.o): In function `Ogre::OptimisedUtilSSE::OptimisedUtilSSE()':
OgreOptimisedUtilSSE.cpp:(.text+0x1f7): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(char const*, unsigned int) const'
./.libs/libSSEsupport.a(libSSEsupport_la-OgreOptimisedUtilSSE.o): In function `Ogre::OptimisedUtilSSE::OptimisedUtilSSE()':
OgreOptimisedUtilSSE.cpp:(.text+0x3b9): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(char const*, unsigned int) const'
/usr/bin/ld: .libs/libOgreMain-1.6.4.so: hidden symbol `std::allocator<char>::allocator()' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[2]: *** [libOgreMain.la] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1


Since we need to distribute a single binary when doing commercial releases, meaning we have to avoid binary incompatibilities, here's a few questions:

1. What is the oldest GCC supported?
2. What is the oldest distro supported?
3. What revision of PythonOgre can you suggest to me which is working in stable manner on Linux?

And just a small remark:
Is it a good idea to continuously move target to new versions of libraries? Shouldn't it be better to just get stuff to work on all platforms, create a tag, perhaps produce binaries, and THEN switch to new version of Ogre, CEGUI, etc? This way there is never a stable release and how should one contribute patches for one version, when next week a decision may be made to switch to new Boost, Ogre, etc which would again break the whole thing and again move the goal of stability further away.

--
Regards,

Ivan Vučica

[Enrico Zschemisch]

Hi,

> Patching with 1.6.1 patch now fails. Is there a 1.6.4 patch ready?

I have attached my 1.6.4 patch, please try it.

> 1. What is the oldest GCC supported?
> 2. What is the oldest distro supported?
> 3. What revision of PythonOgre can you suggest to me which is working in
> stable manner on Linux?

I am sorry I can not answer these questions :-(

I am currently building on Debian Testing (AMD64) with boost 1.40, G++ 4.3
and 4.4. I will try with G++ 4.2 and see how it works. Unfortunately I
still have problems with script parsing when running any of the demos. I
had this problem with an earlier SVN revision before (cant remember which
one), then it was gone and now it is back :-(

Maybe we both should work together to get a working Linux build, Ivan?

Regards,
Enrico

[Andy Miller]

I'm currently working on updating the Linux build and things are looking OK -- only major issue is that you can't use the latest release Boost (1.40) instead you have to use the boost SVN (or probably 1.39 would be OK)

I've also updated generate_code.py to exclude the function that has an issue with the protected declaration..

Expect a couple of SVN updates over the next day or so to bring it up to date for Linux

Andy

2009/11/12 Enrico Zschemisch <enr...@vicampus.com>

[Enrico Zschemisch]

Hi Andy,

Am Donnerstag, den 12.11.2009, 15:51 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:

> I'm currently working on updating the Linux build and things are looking
OK
> -- only major issue is that you can't use the latest release Boost
(1.40)
> instead you have to use the boost SVN (or probably 1.39 would be OK)

Why is this?

Thanks,
Enrico

[Andy Miller]

1.40 has a bug related to Boost.Python :(  

Causes boost to fail when loading with a static property bug -- only happens with Python 2.6..

Andy

2009/11/12 Enrico Zschemisch <enr...@vicampus.com>

[Enrico Zschemisch]

Hi,

ah, okay. Just for reference: You are using boost svn, Python 2.6,
Microsoft Visual Studio 200x?

Thanks,
Enrico

[Andy Miller]

Linux is Ubuntu 9.10 standard build (Python 2.6, GCC 4.4.1 etc)

Windows is XP, MSVC 2008, Python 2.6, etc.

Both use Boost SVN, Ogre 1.6.4 or Ogre SVN (testing both)

Andy

2009/11/12 Enrico Zschemisch <enr...@vicampus.com>

[Enrico Zschemisch]

Hi,

just for reference: Python 2.6 with boost 1.38, 1.39 and 1.40 does not
work on Linux, too.

Regards,
Enrico

[Ivan Vučica]

Hi!

On Thu, Nov 12, 2009 at 15:51, Andy Miller <nzmi...@gmail.com> wrote:

I've also updated generate_code.py to exclude the function that has an issue with the protected declaration..

That would be fantastic! I'll take a look at diff for generate_code.py, I'm interested in learning what had to be done. Perhaps you could write something about it? 

 

Expect a couple of SVN updates over the next day or so to bring it up to date for Linux

For the time being, for company work, I've switched to stable branch, but since other work related to porting might take some time, I'll be compiling SVN in background every now and then (as long as I work on the quadcore, that is :-) ). For the record, current target is the Ubuntu LTS. Other targets are yet to be decided. Hopefully that'll be done soon so we can set up testing installations :-)

Thanks for all the amazing work! 
--
Regards,

Ivan Vučica

[Enrico Zschemisch]

Hi,

I managed to get a linux 64bit build working. Attached is a new
ogre_1.6.4.patch as well as a small patch for python-ogre's environment.py and
setup.py
The new ogre_1.6.4.patch has a workaround for the endless parsing problem. I
will test further if this is really needed. I think the biggest change is the
Boost SVN version...

I can now run most of the demos provided with python-ogre. Demo_Compositor
currently crashes with a segmentation fault.

System: Debian testing AMD64, boost SVN, GCC 4.3.4, python 2.5, Ogre 1.6.4

Please test this patch and provide feedback :-)

Thanks,
Enrico

[Andy Miller]

Question on your patch...

Does the 'j' option on the tar extract cause an error or did you simply remove it because its's no longer needed on newer version of tar?  -- if it doesn't cause an issue then I'm inclined to leave it in..

For the GroupManager patch would you be able to do some further debugging as it would seem that this is a fairly serious issue in Ogre and your patch is a little arbitrary in the way it works :)

What is the actual size of 'su' when it returns from getScriptPatterns and which script loader it is being processed at that time as presumably there is a 32/64 bit bug in here somewhere..

I do see OgreBillboardChain.cpp has a potential 64 bit bug with SEGMENT_EMPTY..  You might want to wrap that with a #if OGRE_ARCH_TYPE == OGRE_ARCHITECTURE_32 etc piece of code...

Regards

Andy

2009/11/14 Enrico Zschemisch <enr...@vicampus.com>

[Enrico Zschemisch]

Hi,

Am Samstag 14 November 2009 02:26:46 schrieb Andy Miller:
> Does the 'j' option on the tar extract cause an error or did you simply
> remove it because its's no longer needed on newer version of tar? -- if it
> doesn't cause an issue then I'm inclined to leave it in..

The 'j' is not needed when running tar and it causes no error to leave it in.
So leave it there .

> For the GroupManager patch would you be able to do some further debugging
> as it would seem that this is a fairly serious issue in Ogre and your
> patch is a little arbitrary in the way it works :)

Yeah, this patch is only intended for testing, not redistribution. I should
have made this clearer at the beginning...

> What is the actual size of 'su' when it returns from getScriptPatterns and
> which script loader it is being processed at that time as presumably there
> is a 32/64 bit bug in here somewhere..

2^31 patterns. I am not sure which script loader it is...

Regards,
Enrico

[Andy Miller]

Can you apply the following patch to your ogre source code and see if it solves the issue:

Index: OgreBillboardChain.cpp

===================================================================

--- OgreBillboardChain.cpp      (revision 9314)

+++ OgreBillboardChain.cpp      (working copy)

@@ -42,7 +42,7 @@

 #include "OgreStringConverter.h"

 namespace Ogre {

-       const size_t BillboardChain::SEGMENT_EMPTY = 0xffffffff;

+       const size_t BillboardChain::SEGMENT_EMPTY = (size_t(-1));

        //-----------------------------------------------------------------------

        BillboardChain::Element::Element()

        {

Regards

Andy

2009/11/15 Enrico Zschemisch <enr...@vicampus.com>

[Enrico Zschemisch]

Hi,

Am Sonntag, den 15.11.2009, 08:54 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:

> Can you apply the following patch to your ogre source code and see if it
> solves the issue:
>
> Index: OgreBillboardChain.cpp

this does not change anything for me so far.
The change in the Ogre Resource Manager is still needed as of now. I will
continuuing debugging this...

One questions though: why have the Linux build commands for boost changed
so dramatically? Why are you still relying on bjam? Recent Boost (1.40 and
SVN) is self-contained, extra bjam is not needed. Oh, and these changes are
not using multi cores (again).

Thanks,
Enrico

[Ivan Vučica]

On Mon, Nov 16, 2009 at 10:55, Enrico Zschemisch <enr...@vicampus.com> wrote:

One questions though: why have the Linux build commands for boost changed
so dramatically? Why are you still relying on bjam? Recent Boost (1.40 and
SVN) is self-contained, extra bjam is not needed. Oh, and these changes are
not using multi cores (again).

Indeed!

Enrico, I'm most grateful for your "make -j%i" % NUMBER_OF_CORES patches, that's exactly as it should be, imho.

 

--
Regards,

Ivan Vučica

[Andy Miller]

What are you specifically refering to?? 

The Boost build worked great for me under Ubuntu -- what problem are you having.. 

Is there an issue using bjam or are you simply pointing out that a shelly script can be used?  If so send me a patch...

The only change has been to simplify things -- however perhaps there is a 64 bit issue?.  

And where has the multi cores been removed ??? 

Andy

2009/11/16 Ivan Vučica <ivu...@gmail.com>

[Ivan Vučica]

On Mon, Nov 16, 2009 at 11:26, Andy Miller <nzmi...@gmail.com> wrote:

And where has the multi cores been removed ??? 

Andy

I'm not sure it was actually a part of trunk. But wherever you call "make", shouldn't you specify "-j[numofcoreshere]"?

That is, precisely what Enrico did in his patch(es)?

 

--
Regards,

Ivan Vučica

[Andy Miller]

And his patches have been incorporated into the trunk (as far as I know)...

If one has been missed please add it to the sourceforge tracker...

Regards

Andy

2009/11/16 Ivan Vučica <ivu...@gmail.com>

On Mon, Nov 16, 2009 at 11:26, Andy Miller <nzmi...@gmail.com> wrote:

--
Regards,

Ivan Vučica

[Enrico Zschemisch]

Hi,

Am Montag, den 16.11.2009, 11:36 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:

> If one has been missed please add it to the sourceforge tracker...

Okay, will do :-)

Has anyone tried building python-ogre without building CEGUI and OIS
separately? This works for me quite well, I am using the libraries provided
by my distribution (Debian).

Regards,
Enrico

[Ivan Vučica]

On Mon, Nov 16, 2009 at 11:36, Andy Miller <nzmi...@gmail.com> wrote:

And his patches have been incorporated into the trunk (as far as I know)...

If one has been missed please add it to the sourceforge tracker...

Heh, I haven't looked at the latest latest latest trunk, since I'm on my personal machine which is a bit ... underpowered to facilitate ogre building :-)

So, I apologize!

On Mon, Nov 16, 2009 at 11:42, Enrico Zschemisch <enr...@vicampus.com> wrote:

Hi,

Am Montag, den 16.11.2009, 11:36 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:

> If one has been missed please add it to the sourceforge tracker...

Okay, will do :-)


Has anyone tried building python-ogre without building CEGUI and OIS
separately? This works for me quite well, I am using the libraries provided
by my distribution (Debian).

Didn't Tim's packages use Debian/Ubuntu libs?

--
Regards,

Ivan Vučica

[Enrico Zschemisch]

Hi,

Am Montag, den 16.11.2009, 11:26 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:

> The Boost build worked great for me under Ubuntu -- what problem are you
> having..

Ah, I was not having *build* problems, except using only one CPU core when
I have eight of them.
This line environment.py:568:
"[0, PREFIX + '/bin/bjam release install --with-python --with-thread
--with-date_time --prefix='+PREFIX, os.path.join(os.getcwd(),
'boost-trunk') ]"
will not use multiple cores, as e.g. ogre uses to compile:
"make -j%i" % NUMBER_OF_CORES"

> Is there an issue using bjam or are you simply pointing out that a
shelly
> script can be used? If so send me a patch...

Okay, I will resend my patch about building boost.
We can debate very long if bjam is really needed or not. I am just asking
why you want to use it, when it is not needed anymore. I have no problem
with leaving it in :-)

However, I have a very big problem with wasting my bandwidth and time: You
are downloading a stable boost version, boost SVN trunk and bjam when only
one of these is really needed. Either Boost 1.40 or Boost SVN. Boost SVN is
a ~600MiB download (depending on compression, etc.) whereas boost 1.40 is
only ~40MiB. I leave in a place where you pay for every GiB download, so I
think this definitely makes a difference.

> And where has the multi cores been removed ???

See above.

Regards,
Enrico

[Andy Miller]

Boost 1.40 doesn't work with Python 2.6 hence the need for the SVN version -- I've made a change to do an svn export instead of a co which will save bandwidth...

Bjam is used as that's what has been required in the past and I haven't tested it any other way on Linux or the Mac (bjam is the only way on Windows that I know of) -- if we can do it differently I'm happy to make the change via a patch...

Regards

Andy

2009/11/16 Enrico Zschemisch <enr...@vicampus.com>

[Enrico Zschemisch]

Hi,

I just added a patch for the linux build system to the sourceforge
bugtracker. Please apply it or tell me, whats wrong :-)

If somebody has test feedback for this patch, please provide it (-:


Thanks,
Enrico

[Enrico Zschemisch]

PS: This patch would also help to close this bug:
http://sourceforge.net/tracker/?func=detail&aid=2884517&group_id=186291&atid=916690

[Andy Miller]

The multi cores on the bjam command looks great and I've implemented that..

However you have removed the aclocal and bootstrap from the ogre build -- is this causing an issue on your system? 

I have used it like this (with Ogre 1.6.4) on the latest Ubuntu only a few weeks ago without any issues (I didn't try 'not' running them :) )  -- and this is how the Ogre wiki documents the build -- so would like to check what goes wrong with them on your system (perhaps we will need to check a Linux type?)..

Many Thanks

Andy

2009/11/18 Enrico Zschemisch <enr...@vicampus.com>

Enrico

--

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.
For more options, visit this group at http://groups.google.com/group/python-ogre-developers?hl=.

[Enrico Zschemisch]

Hi,

Am Mittwoch, den 18.11.2009, 13:54 +0100 schrieb Andy Miller
<nzmi...@gmail.com>:

> The multi cores on the bjam command looks great and I've implemented
that..

Nice :)
This same change has been removed from the cegui-build, too. Can you add
that, too? If not, I will supply a small patch ;-)

> However you have removed the aclocal and bootstrap from the ogre build
--
> is this causing an issue on your system?

Your prerequistes-script does not install aclocal and libtool(ize), but
you are relying on them which does not fit together. And with Ogre 1.7 (svn
trunk), both tools are not needed anymore.

> this is how the Ogre wiki documents the build -- so would like to check
> what goes wrong with them on your system

Ah, okay. Usually there is no need to run both tools and I see no reason
to do so.
As the Ogre Wiki documents it that way, we should leave them in. Sorry for
the inconvenience.


Regards,
Enrico

[Andy Miller]

Is there any chance you can test the 64 bit build with the following patch -- it's is something I saw in the recent 1.7 trunk and (rev 9351) and I wonder if it's causing the issue you are seeing??

Thanks

Andy

Index: OgreScriptTranslator.cpp

===================================================================

--- OgreScriptTranslator.cpp (revision 9350)

+++ OgreScriptTranslator.cpp (revision 9351)

@@ -3806,7 +3806,7 @@

 

  if (prop->values.size() == 4)

  {

- size_t mrtIndex;

+ uint32 mrtIndex;

  getUInt(*getNodeAt(prop->values, 3), &mrtIndex);

  mUnit->setCompositorReference(compositorName, textureName, mrtIndex);

2009/11/16 Enrico Zschemisch <enr...@vicampus.com>

Enrico

--~--~---------~--~----~------------~-------~--~----~

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
-~----------~----~----~----~------~----~------~--~---

[Judd Cohen]

I'm trying to compile rev 1030 on Ubuntu 9.10 64bit - followed the wiki instructions, everything seemed to work. C++ demos work fine, but the python demos don't. They fail with:

OGRE EXCEPTION(5:ItemIdentityException): Could not find font BlueHighway in TextAreaOverlayElement::setFontName at OgreTextAreaOverlayElement.cpp (line 360)

I've double and triple checked resources.cfg, the media folder, and OgreCore.zip. It seems to be ignoring fontdef files entirely. Putting one in its own folder and adding it to the bootstrap group did nothing. Media locations are correct, its even loading textures in the same folder as the fontdef file.

Attached is the console output of a demo, let me know if you want any more information. I don't have a clue how to debug this further.

Judd

[Enrico Zschemisch]

Hi Judd,

this error is the "expected" behaviour when running the python-ogre demos
under 64 Bit Linux :-(
So far I have debugged it a little and know where it comes from. But I
dont know the root cause yet, so there is no fix...
You could try the patch Andy suggested in his last email (I will try that
tomorrow).


Regards,
Enrico

[Enrico Zschemisch]

Hi,

there is no such entry for Ogre 1.6.4. How can I easily switch to Ogre SVN?

Thanks,
Enrico

[Judd Cohen]

I apologize if this question is obvious; I know very little C++, and even less about GCC.

Is there an easy way to compile a 32bit Python-Ogre binary on a 64bit Linux system (Ubuntu 9.10)? I'm perfectly comfortable working with Linux (used to be a Linux server admin). I need to get my gamedev environment back up and running. and my projects use some of the newer modules like ogrenewt2. I'm not aware of any prebuilt binary packages that new.

I'm hoping it's something like, install some 32bit dev packages, change some config options and recompile? Maybe install a 32bit Python binary?

I'd be happy to throw together some ogrenewt2 demos once I'm back up and running, it's much faster than 1.5 :)

Thanks,

Judd

[Enrico Zschemisch]

Hi,

I have not done this, so take this with a grain of salt:
- install ogre-dependencies as 32Bit library (parts of these can be done
through the build script, other things like XServer libraries and all this
stuff have to come from your package management system)
- install 32bit Python
- compile ogre in 32bit mode (we could offer this through the build
script)
- Generate binding code for Ogre
- Compile binding code for Ogre in 32 Bit mode
- Install

This *should* work...


Regards,
Enrico

[Judd Cohen]

Hi Enrico, I really appreciate the help.

The part I'm really unclear on is compiling ogre and the binding code in 32 bit mode. From googling it, it seems like I just have to pass flags to gcc, but it sounds like every build system handles this differently - can I just pass a flag to ./configure for ogre? And for the binding code, I'm guessing i'll have to hack at BuildModule.py a bit?

Thanks,

Judd

Enrico

--

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.

[Judd Cohen]

Ah, nevermind, http://wiki.winehq.org/WineOn64bit explains it quite nicely. I think I can figure it out from here.

Thanks!

Judd

[Enrico Zschemisch]

Hi,

for packages with a configure-script this is quite easy, execute the
following:
export CFLAGS="-m32 "
export CXXFLAGS="-m32 "
./configure --host=x86-redhat-linux <other options, e.g. prefix>

The "redhat"-part might be replaced with your distribution. After
configure, run make and make install. I suggest installing CEGUI, OIS and
ogre manually first and *not* with the python-ogre build script. If you
have problems with this, you can contact me on ICQ (72778726) or let's
exchange private emails. I am not sure if everybody is interested in all
these details...

A maybe easier way is to prepare a 32bit chroot environment for your
distribution and create python-ogre and all the packages there. Then you
can simply copy the created libraries and fix the dependencies (the
aforementioned 32bit xserver-libraries and similar).

It would be great if you do try one the two ways, as I want to hunt down
the bug preventing a clean 64bit build >:-)


Regards,
Enrico

[Enrico Zschemisch]

Hi,

why not install 64bit wine through your package management system? Debian
offers this, so Ubuntu should have it, too.

[stevems]

You can install a vm image of 32bit Linux on top of your 64bit. Do all
your compiling on the 32bit vm and then bring it over to the 64bit
side. It should run if you have the IA32-libs package installed on the
64bit side.