which means that core.so is getting built as 64-bit, although the system is 32-bit. System details:
Linux 2.6.32.16-150.fc12.i686.PAE #1 SMP Sat Jul 24 05:25:42 UTC 2010 i686 i686 i386 GNU/Linux
And this is wxPython 2.8.10.1, Python 2.6.5. The building is taken care of by a massive installer shell script that I wrote, but it usually works and we’ve never seen this error before. Is there an obvious explanation for this, or has anyone else encountered a similar problem before and figured out the solution?
which means that core.so is getting built as 64-bit, although the system is 32-bit. System details:
Linux 2.6.32.16-150.fc12.i686.PAE #1 SMP Sat Jul 24 05:25:42 UTC 2010 i686 i686 i386 GNU/Linux
And this is wxPython 2.8.10.1, Python 2.6.5. The building is taken care of by a massive installer shell script that I wrote, but it usually works and we’ve never seen this error before. Is there an obvious explanation for this, or has anyone else encountered a similar problem before and figured out the solution?
We can’t use Unicode right now - it involves too many changes to our code because we use Boost.Python for many things and it won’t handle unicode objects properly. However, I need to update to 2.8.11 anyway and it’s probably time to switch to Python 2.7 as well.
Yes, the update is welcome. I updated to wxPython 2.8.11 Unicode and Python 2.7 and will never look back. But wxPython 2.8.11 Unicode doesn’t break your code. It simply adds unicode support if you are dealing with unicode strings. Just add the line # coding=utf-8 (right after the line #! /usr/bin/env python) and then make the string to be a unicode string, like this: u’Ich lebe in Österreich’, so add an ‘u’ before the string literal. Maybe if you install the unicode version of wxPython, your issues with the misbuilt objects would go away. Try it.
We can’t use Unicode right now - it involves too many changes to our code because we use Boost.Python for many things and it won’t handle unicode objects properly. However, I need to update to 2.8.11 anyway and it’s probably time to switch to Python 2.7 as well.
Is it possible that the system is 64-bit but Python is built as 32-bit? The wx build should default properly to the system type (at least I've never had to force it one way or the other on Linux systems) and the wxPython build takes its compile flags and such from both Python and wxWidgets... So I guess I'm saying that at this point it's hard to say where the screw-up is happening.
···
On 10/17/10 7:14 AM, Nat Echols wrote:
A user reported some problems building wxPython from source on Fedora 12
- when she tries to launch my app, she gets this error:
which means that _core_.so is getting built as 64-bit, although the
system is 32-bit. System details:
Linux 2.6.32.16-150.fc12.i686.PAE #1 SMP Sat Jul 24 05:25:42 UTC 2010
i686 i686 i386 GNU/Linux
And this is wxPython 2.8.10.1, Python 2.6.5. The building is taken care
of by a massive installer shell script that I wrote, but it usually
works and we've never seen this error before. Is there an obvious
explanation for this, or has anyone else encountered a similar problem
before and figured out the solution?