C++ ABI 1002/102 incompatibility with wxPython on OS X

Brendan_Simon_eTRIX · March 1, 2011, 9:34pm

It turns out that previous builds of my application DO work on
PowerPC OS X 10.4, it’s only recent builds

that fail with the ABI compatibility error.

The app bundle is built with python.org 2.5.4 using pythonw

(/Library/Frameworks/Python.framework/Versions/2.5/bin/pythonw). It
contains a libwx_macud-2.8.0.dylib file which I think is the
culprit. I interrogated this file (strings and grep) and noted an
ABI difference.

An app that works on PowerPC and Intel 10.4.11.

`

  $ cat ./MyApp.app/Contents/Frameworks/libwx_macud-2.8.0.dylib |

strings | grep ABI

  2.8 (debug,Unicode,compiler with C++ ABI 102,wx

containers,compatible with 2.6)

  2.8 (debug,Unicode,compiler with C++ ABI 1002,wx

containers,compatible with 2.6)

`    An app that does NOT work on PowerPC 10.4.11 but does work on

Intel 10.4.11.

`

  $ cat ./MyApp.app/Contents/Frameworks/libwx_macud-2.8.0.dylib |

strings | grep ABI

  2.8 (debug,Unicode,compiler with C++ ABI 1002,wx

containers,compatible with 2.6)

  2.8 (debug,Unicode,compiler with C++ ABI 1002,wx

containers,compatible with 2.6)

`

The latter has TWO identical lines with ABI 1002.  i.e. it does NOT

have the ABI 102 for some reason.

A search of my filesystem reveals that none of the wx libraries

appear to have ABI 102 in the wx libraries.

`$ find /usr -name "libwx_macud-2.8.0.dylib" -ls

  141212        8 lrwxr-xr-x    1 root     wheel          27 15 Aug

2009 /usr/lib/libwx_macud-2.8.0.dylib →
libwx_macud-2.8.0.5.0.dylib

  227169828        8 lrwxr-xr-x    1 root     wheel          27  5

Aug 2010
/usr/local/lib/wxPython-unicode-2.8.11.0/lib/libwx_macud-2.8.0.dylib
→ libwx_macud-2.8.0.7.0.dylib

  2411353        8 lrwxr-xr-x    1 root     wheel          27 18

Jun 2008
/usr/local/lib/wxPython-unicode-2.8.4.0/lib/libwx_macud-2.8.0.dylib
→ libwx_macud-2.8.0.1.1.dylib

  2412261        8 lrwxr-xr-x    1 root     wheel          27 18

Jun 2008
/usr/local/lib/wxPython-unicode-2.8.4.2/lib/libwx_macud-2.8.0.dylib
→ libwx_macud-2.8.0.1.1.dylib`

`      $ find /usr -name "libwx_macud-2.8.0.dylib" | xargs strings |

grep ABI

  2.8 (debug,Unicode,compiler with C++ ABI 1002,wx

containers,compatible with 2.6)

  2.8 (debug,Unicode,compiler with C++ ABI 1002,wx

containers,compatible with 2.6)

  2.8 (debug,Unicode,compiler with C++ ABI 1002,wx

containers,compatible with 2.6)

  2.8 (debug,Unicode,compiler with C++ ABI 1002,wx

containers,compatible with 2.6)

`

I'm not sure what has changed to cause this.

OS X updates
```
    Code changes that use various interpreters, specified as:
```
python, pythonw,
/Library/Frameworks/Python.framework/Versions/2.5/bin/pythonw,
etc.
Installs of new pythons (e.g. python 2.7, python 3.x)
Installs of newer wxPython ?? ANSI versus Unicode versions ??

Any ideas as to why my wx library no longer has the ABI 102
compatibility ??

I’m thinking it is most likely a wxPython build or install problem.

Thanks, Brendan.

···

On 8/02/11 10:55 PM, Brendan Simon (eTRIX) wrote:

  On 1/25/11 1:20 AM, Brendan Simon (eTRIX) > wrote:


    I have a wxPython app that is built with py2app. A user recently
reported the following error when trying to run the app.
Fatal Error: Mismatch between the program and library build versions
detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI
102,wx containers,compatible with 2.6).
Abort trap
logout

As others have informed me, the C++ ABI changed from gcc-3.3 to gcc-3.4
(and beyond).

Brendan_Simon_eTRIX · March 1, 2011, 9:42pm

The other possibility is that the builds that do work may have been
built on another Mac running 10.5, not my current Mac running 10.6.
Will have dig up the old Mac and see if that makes a difference.

···

On 2/03/11 8:34 AM, Brendan Simon (eTRIX) wrote:

On 8/02/11 10:55 PM, Brendan Simon (eTRIX) wrote:
    On 1/25/11 1:20 AM, Brendan Simon (eTRIX) > > wrote:
    I have a wxPython app that is built with py2app. A user recently
reported the following error when trying to run the app.
Fatal Error: Mismatch between the program and library build versions
detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI
102,wx containers,compatible with 2.6).
Abort trap
logout
As others have informed me, the C++ ABI changed from gcc-3.3 to gcc-3.4
(and beyond).
  It turns out that previous builds of my application DO work on
PowerPC OS X 10.4, it’s only recent builds
  that fail with the ABI compatibility error.



  The app bundle is built with python.org 2.5.4 using pythonw
(/Library/Frameworks/Python.framework/Versions/2.5/bin/pythonw).
It contains a libwx_macud-2.8.0.dylib file which I think is the
culprit. I interrogated this file (strings and grep) and noted an
ABI difference.
  An app that works on PowerPC and Intel 10.4.11.

  `

    $ cat ./MyApp.app/Contents/Frameworks/libwx_macud-2.8.0.dylib |
strings | grep ABI
    2.8 (debug,Unicode,compiler with C++ ABI 102,wx
containers,compatible with 2.6)
    2.8 (debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6)
  `      An app that does NOT work on PowerPC 10.4.11 but does work on
Intel 10.4.11.
  `

    $ cat ./MyApp.app/Contents/Frameworks/libwx_macud-2.8.0.dylib |
strings | grep ABI
    2.8 (debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6)
    2.8 (debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6)
  `

  The latter has TWO identical lines with ABI 1002.  i.e. it does
NOT have the ABI 102 for some reason.
  A search of my filesystem reveals that none of the wx libraries
appear to have ABI 102 in the wx libraries.
  `$ find /usr -name "libwx_macud-2.8.0.dylib" -ls

    141212        8 lrwxr-xr-x    1 root     wheel          27 15
Aug 2009 /usr/lib/libwx_macud-2.8.0.dylib →
libwx_macud-2.8.0.5.0.dylib
    227169828        8 lrwxr-xr-x    1 root     wheel          27  5
Aug 2010
/usr/local/lib/wxPython-unicode-2.8.11.0/lib/libwx_macud-2.8.0.dylib
→ libwx_macud-2.8.0.7.0.dylib
    2411353        8 lrwxr-xr-x    1 root     wheel          27 18
Jun 2008
/usr/local/lib/wxPython-unicode-2.8.4.0/lib/libwx_macud-2.8.0.dylib
→ libwx_macud-2.8.0.1.1.dylib
    2412261        8 lrwxr-xr-x    1 root     wheel          27 18
Jun 2008
/usr/local/lib/wxPython-unicode-2.8.4.2/lib/libwx_macud-2.8.0.dylib
→ libwx_macud-2.8.0.1.1.dylib`
  `        $ find /usr -name "libwx_macud-2.8.0.dylib" | xargs strings |
grep ABI
    2.8 (debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6)
    2.8 (debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6)
    2.8 (debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6)
    2.8 (debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6)
  `

  I'm not sure what has changed to cause this.
OS X updates
      Code changes that use various interpreters, specified as:
python, pythonw,
/Library/Frameworks/Python.framework/Versions/2.5/bin/pythonw,
etc.
Installs of new pythons (e.g. python 2.7, python 3.x)
      Installs of newer wxPython ??  ANSI versus Unicode versions
??
Any ideas as to why my wx library no longer has the ABI 102
compatibility ??
  I'm thinking it is most likely a wxPython build or install
problem.

Chris_Barker1 · March 1, 2011, 9:58pm

This is presumably the PPC and Intel parts of the lib.

IIRC, at one point (about two years ago), Robin did some machinations to build the PPC version of the binary with a different compiler version than the Intel version. I needed to go through the same machinations to build an extension that was linked against wxPython.

I think that was required to get a build that would work on 10.3.9 PPC and recent Intel machines. Apparently, it's required for 10.4, too. I, unfortunately, don't have a 10.4 machine to test on anymore, so it' a bit hard for me to help. HOwever, looking at my ugly build script, it looks like I'm essentially doing:

1) build a regular old extension
2) using lipo to remove the PPc part
3) setting ENV varibles to use gcc3.3:
     # this builds the ppc version correctly
     export CXX="g++-3.3 -arch ppc -DMAC_OS_X_VERSION_MAX_ALLOWED=1040"
     export CC="gcc-3.3 -arch ppc -DMAC_OS_X_VERSION_MAX_ALLOWED=1040"
     export MACOSX_DEPLOYMENT_TARGET=10.3
4) pull the ppc part out of that build, and add it inot the original one.

when I look at the dylib delivered with that app, I get:

$ cat libwx_macud-2.8.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)

when I look at the one in /usr/lib, which I presume was supplied by apple, I get:

2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)

(this is with OS-X 10.6).

When I look at the one in :

/usr/local/lib/wxPython-unicode-2.8.11.0/lib/
(which I got from a wxPython binary), I get:

$ cat libwx_macud-2.8.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)

Which is what you want.

I suspect that you're now using Apple's wx, by accident, or are you using a newer wxPython than 2.8.11 ?

-Chris

···

On 3/1/11 1:34 PM, Brendan Simon (eTRIX) wrote:

An app that works on PowerPC and Intel 10.4.11.

$ cat ./MyApp.app/Contents/Frameworks/libwx_macud-2.8.0.dylib | strings
> grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Chris_Barker1 · March 1, 2011, 10:02pm

One more note:

I just took a look at an app bundle I recently built with wx -- it has the right ABI versions. This is with:

Python 2.6.6 (from Python.org)
wxPython 2.8.11.0 (from wxpython.org)

So it can be done.

-Chris

···

On 3/1/11 1:58 PM, Christopher Barker wrote:

When I look at the one in :

/usr/local/lib/wxPython-unicode-2.8.11.0/lib/
(which I got from a wxPython binary), I get:

$ cat libwx_macud-2.8.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Robin · March 2, 2011, 6:19pm

An app that works on PowerPC and Intel 10.4.11.

$ cat ./MyApp.app/Contents/Frameworks/libwx_macud-2.8.0.dylib | strings
> grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

This is presumably the PPC and Intel parts of the lib.

IIRC, at one point (about two years ago), Robin did some machinations to
build the PPC version of the binary with a different compiler version
than the Intel version. I needed to go through the same machinations to
build an extension that was linked against wxPython.

The PPC builds are done with gcc 3.x and the Intel builds are done with gcc 4.0, and then they are merged together with the lipo tool. It had to be done like this in order to continue to support PPC on OSX 10.3, but still be able to support some of the more advanced features on newer versions of OSX. Kevin O. helped to figure out how to do this and put together the build scripts.

FYI, the wxPython release builds for 2.8.x and older (see below for 2.9) are done on an OSX 10.4 system.

I think that was required to get a build that would work on 10.3.9 PPC
and recent Intel machines. Apparently, it's required for 10.4, too. I,
unfortunately, don't have a 10.4 machine to test on anymore, so it' a
bit hard for me to help. HOwever, looking at my ugly build script, it
looks like I'm essentially doing:

1) build a regular old extension
2) using lipo to remove the PPc part
3) setting ENV varibles to use gcc3.3:
# this builds the ppc version correctly
export CXX="g++-3.3 -arch ppc -DMAC_OS_X_VERSION_MAX_ALLOWED=1040"
export CC="gcc-3.3 -arch ppc -DMAC_OS_X_VERSION_MAX_ALLOWED=1040"
export MACOSX_DEPLOYMENT_TARGET=10.3
4) pull the ppc part out of that build, and add it inot the original one.

It could probably be done a bit more simply than this. For example you should be able to limit each build to just the architecture you need so you are not tossing out half of the build on each pass. IIRC I had to hack distutils a little to make that work, but the code is available in wxPython's config.py or setup.py for borrowing if you need it.

BTW, since wx has dropped support for OSX 10.3 in the 2.9 release series I have also stopped doing the convoluted builds and lippoing in wxPython releases for 2.9. Now it pretty much does "normal" builds letting distutils and the Python used for the build decide what architectures to build for, etc. I do however still control which compiler is used.

So, starting with 2.9 the 32-bit Carbon builds are built on an OSX 10.4 system using gcc 4.0, contain ppc and i386 binaries, and are compatible with OSX 10.4 and newer. The 32/64-bit Cocoa builds are done with gcc 4.2 on a OSX 10.6 system and contain ppc, i382, and x86_64 architectures. They should be compatible with OSX 10.5 and 10.6 but there was a bug in the build for 2.9.1.1 that broke compatibility on 10.5.

···

On 3/1/11 1:58 PM, Christopher Barker wrote:

On 3/1/11 1:34 PM, Brendan Simon (eTRIX) wrote:

--
Robin Dunn
Software Craftsman

Chris_Barker1 · March 2, 2011, 9:22pm

It could probably be done a bit more simply than this. For example you
should be able to limit each build to just the architecture you need so
you are not tossing out half of the build on each pass. IIRC I had to
hack distutils a little to make that work, but the code is available in
wxPython's config.py or setup.py for borrowing if you need it.

I'm pretty sure you sent me a script that does this more elegantly a couple years ago, but we had to change something, and this is how I got it to work. If it ain't broke, don't fix it!

So, starting with 2.9 the 32-bit Carbon builds are built on an OSX 10.4
system using gcc 4.0, contain ppc and i386 binaries, and are compatible
with OSX 10.4 and newer. The 32/64-bit Cocoa builds are done with gcc
4.2 on a OSX 10.6 system and contain ppc, i382, and x86_64
architectures. They should be compatible with OSX 10.5 and 10.6 but
there was a bug in the build for 2.9.1.1 that broke compatibility on 10.5.

Thanks -- I'll keep that in mind -- we're updating the app this spring, and we we'll probably move it to a newer python and wx version then.

To the OP: it looks a lot like to me that you somehow got Apple's wx libs linked it. I suspect if you re-install everything, it will fix itself.

-Chris

···

On 3/2/11 10:19 AM, Robin Dunn wrote:

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Brendan_Simon · March 3, 2011, 9:21am

From what I can see, py2app just copies the libwx_macud-2.8.0.dylib file
to the dist directory and strips it.

copying
/usr/local/lib/wxPython-unicode-2.8.11.0/lib/libwx_macud-2.8.0.dylib ->
/Users/brendan/MyApp/src/dist/SureAnalysis.app/Contents/Frameworks
stripping libwx_macud-2.8.0.dylib

I checked inside the installer package of all the wxPython-2.8 os x
installers (ansi and unicode, 2.5-2.7) that are on the wxPython download
page, and none of them seem to have the "ABI 102", only "ABI 1002". I
extracted the pax files and did my strings/grep trick (I presume that is
sufficient).

I would have thought if they were all built on a 10.4 box that they
would likely have the "ABI 102" when compiled with gcc-3.x.

If the installers don't have the required architectures/ABI, then surely
py2app has no hope of including them. But the installers must have had
them at some stage because I have app bundles that do have "ABI 102" wx
libraries. I'm fairly positive that I haven't built wxPython from
sources !!

Also, is it possible to have
wxPython2.8-osx-unicode-2.8.11.0-universal-py2.7,
wxPython2.8-osx-unicode-2.8.11.0-universal2.6 and
wxPython2.8-osx-unicode-2.8.11.0-universal2.5 installed at the same time ??

e.g. if I had different applications that used different versions of python.

Thanks, Brendan.

···

On 3/03/11 8:22 AM, Christopher Barker wrote:

On 3/2/11 10:19 AM, Robin Dunn wrote:

It could probably be done a bit more simply than this. For example you
should be able to limit each build to just the architecture you need so
you are not tossing out half of the build on each pass. IIRC I had to
hack distutils a little to make that work, but the code is available in
wxPython's config.py or setup.py for borrowing if you need it.

I'm pretty sure you sent me a script that does this more elegantly a
couple years ago, but we had to change something, and this is how I got
it to work. If it ain't broke, don't fix it!

So, starting with 2.9 the 32-bit Carbon builds are built on an OSX 10.4
system using gcc 4.0, contain ppc and i386 binaries, and are compatible
with OSX 10.4 and newer. The 32/64-bit Cocoa builds are done with gcc
4.2 on a OSX 10.6 system and contain ppc, i382, and x86_64
architectures. They should be compatible with OSX 10.5 and 10.6 but
there was a bug in the build for 2.9.1.1 that broke compatibility on
10.5.

Thanks -- I'll keep that in mind -- we're updating the app this spring,
and we we'll probably move it to a newer python and wx version then.

To the OP: it looks a lot like to me that you somehow got Apple's wx
libs linked it. I suspect if you re-install everything, it will fix itself.

Chris_Barker1 · March 3, 2011, 8:14pm

From what I can see, py2app just copies the libwx_macud-2.8.0.dylib file
to the dist directory and strips it.

yup

copying
/usr/local/lib/wxPython-unicode-2.8.11.0/lib/libwx_macud-2.8.0.dylib ->
/Users/brendan/MyApp/src/dist/SureAnalysis.app/Contents/Frameworks
stripping libwx_macud-2.8.0.dylib

yup - that should be doing it.

I checked inside the installer package of all the wxPython-2.8 os x
installers (ansi and unicode, 2.5-2.7) that are on the wxPython download
page, and none of them seem to have the "ABI 102", only "ABI 1002". I
extracted the pax files and did my strings/grep trick (I presume that is
sufficient).

Weird -- I've got ABI 102 in my version of wxPython-unicode-2.8.11.0 that I got from the wxPython site.

However, I just dowloaded: wxPython2.8-osx-unicode-2.8.11.0-universal-py2.7.dmg

and get:

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)

So I tried a 2.6 version:

wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg

and also got two ABI 1002 lines.

However, a file with the same name that I downloaded Aug 31, 2010, has:

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)

Robin -- did something get messed up with recent builds?

Brendon -- let me know if you want me to send you my copy that works!

Also, is it possible to have
wxPython2.8-osx-unicode-2.8.11.0-universal-py2.7,
wxPython2.8-osx-unicode-2.8.11.0-universal2.6 and
wxPython2.8-osx-unicode-2.8.11.0-universal2.5 installed at the same time ??

I think so. there is a:

/usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.6

on my system, so presumably there would be a dir for 2.5 and 2.7 if I had those installed. If that doesn't work, I'd call it a bug.

-Chris

···

On 3/3/11 1:21 AM, Brendan Simon wrote:

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Robin · March 3, 2011, 8:43pm

I don't remember exactly why I had to do this, (and don't actually remember doing it, but I did[1]) but the build scripts are testing for Python 2.7 and are using gcc-4.0 for both the PPC and the i386 builds if the build is for Python 2.7. Perhaps it had something to do with changes in how Python was built? Anyway because of that it looks like if you want to use OSX 10.3 then you'll need to stick with Python 2.6 and the wxPython built for Python 2.6.

[1] wxTrac has been migrated to GitHub Issues - wxWidgets

···

On 3/3/11 12:14 PM, Christopher Barker wrote:

On 3/3/11 1:21 AM, Brendan Simon wrote:

I checked inside the installer package of all the wxPython-2.8 os x
installers (ansi and unicode, 2.5-2.7) that are on the wxPython download
page, and none of them seem to have the "ABI 102", only "ABI 1002". I
extracted the pax files and did my strings/grep trick (I presume that is
sufficient).

Weird -- I've got ABI 102 in my version of wxPython-unicode-2.8.11.0
that I got from the wxPython site.

However, I just dowloaded:
wxPython2.8-osx-unicode-2.8.11.0-universal-py2.7.dmg

and get:

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

So I tried a 2.6 version:

wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg

and also got two ABI 1002 lines.

However, a file with the same name that I downloaded Aug 31, 2010, has:

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

Robin -- did something get messed up with recent builds?

--
Robin Dunn
Software Craftsman

Chris_Barker1 · March 3, 2011, 10:44pm

Robin,

Maybe I wasn't clear -- I did suspect that things may have changed for 2.7. However, as you see above, the dmg for 2.6 downloaded today had only ABI 1002 builds, whereas the dmg I downloaded last August had 102 and 1002.

This is really weird, but consistent with the OP's findings.

Did the dmg of wxPython2.8.11 for python 2.6 get re-built? It seems to have changed.

-Chris

···

On 3/3/11 12:43 PM, Robin Dunn wrote:

On 3/3/11 12:14 PM, Christopher Barker wrote:

So I tried a 2.6 version:

wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg

and also got two ABI 1002 lines.

However, a file with the same name that I downloaded Aug 31, 2010, has:

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

Robin -- did something get messed up with recent builds?

I don't remember exactly why I had to do this, (and don't actually
remember doing it, but I did[1]) but the build scripts are testing for
Python 2.7 and are using gcc-4.0 for both the PPC and the i386 builds if
the build is for Python 2.7. Perhaps it had something to do with changes
in how Python was built? Anyway because of that it looks like if you
want to use OSX 10.3 then you'll need to stick with Python 2.6 and the
wxPython built for Python 2.6.

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Brendan · March 4, 2011, 4:02am

I downloaded wxPyton 2.8.10.1 (17-May-2009) and 2.8.9.2 (20-Feb-2009)
from Sourceforge and they seem to have the same problem.
I presume they should be ok if any recent build changes have caused
the issue I am seeing with 2.8.11.
Perhaps they have all been automatically rebuilt on SF somehow ??
Or maybe the one I did have, and Chris has, was an aberration ??

I am not interested in my apps running on OS X 10.3, only 10.4
onwards From Robins comments it seems that gcc-4 is ok with 10.4,
but I don't think that is the case, at least it doesn't appear to be
on PPC, unless it is some other issue.

Cheers, Brendan.

···

On Mar 4, 9:44 am, Christopher Barker <Chris.Bar...@noaa.gov> wrote:

On 3/3/11 12:43 PM, Robin Dunn wrote:

> On 3/3/11 12:14 PM, Christopher Barker wrote:
>> So I tried a 2.6 version:

>> wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg

>> and also got two ABI 1002 lines.

>> However, a file with the same name that I downloaded Aug 31, 2010, has:

>> $ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
>> 2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
>> with 2.6)
>> 2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
>> with 2.6)

>> Robin -- did something get messed up with recent builds?

> I don't remember exactly why I had to do this, (and don't actually
> remember doing it, but I did[1]) but the build scripts are testing for
> Python 2.7 and are using gcc-4.0 for both the PPC and the i386 builds if
> the build is for Python 2.7. Perhaps it had something to do with changes
> in how Python was built? Anyway because of that it looks like if you
> want to use OSX 10.3 then you'll need to stick with Python 2.6 and the
> wxPython built for Python 2.6.

Robin,

Maybe I wasn't clear -- I did suspect that things may have changed for
2.7. However, as you see above, the dmg for 2.6 downloaded today had
only ABI 1002 builds, whereas the dmg I downloaded last August had 102
and 1002.

This is really weird, but consistent with the OP's findings.

Did the dmg of wxPython2.8.11 for python 2.6 get re-built? It seems to
have changed.

Robin · March 4, 2011, 5:00pm

So I tried a 2.6 version:

wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg

and also got two ABI 1002 lines.

However, a file with the same name that I downloaded Aug 31, 2010, has:

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

Robin -- did something get messed up with recent builds?

I don't remember exactly why I had to do this, (and don't actually
remember doing it, but I did[1]) but the build scripts are testing for
Python 2.7 and are using gcc-4.0 for both the PPC and the i386 builds if
the build is for Python 2.7. Perhaps it had something to do with changes
in how Python was built? Anyway because of that it looks like if you
want to use OSX 10.3 then you'll need to stick with Python 2.6 and the
wxPython built for Python 2.6.

Robin,

Maybe I wasn't clear -- I did suspect that things may have changed for
2.7. However, as you see above, the dmg for 2.6 downloaded today had
only ABI 1002 builds, whereas the dmg I downloaded last August had 102
and 1002.

Ah, sorry. Somehow my eyes substituted a '7' for the '6's in your comment when I read it...

This is really weird, but consistent with the OP's findings.

Did the dmg of wxPython2.8.11 for python 2.6 get re-built? It seems to
have changed.

Did you totally clean out prior installs before testing that install? There is some overlap of the files installed between wxPython's for the different Python versions, and it's possible that the installers don't overwrite files that they think are newer than what is being installed. I just downloaded a new copy of wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg and looked at the contents without installing, and I got this:

dazzler:robind ~/Desktop/usr/local/lib/wxPython-unicode-2.8.11.0/lib
> cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)

···

On 3/3/11 2:44 PM, Christopher Barker wrote:

On 3/3/11 12:43 PM, Robin Dunn wrote:

On 3/3/11 12:14 PM, Christopher Barker wrote:

--
Robin Dunn
Software Craftsman

Robin · March 4, 2011, 5:01pm

I am not interested in my apps running on OS X 10.3, only 10.4
onwards From Robins comments it seems that gcc-4 is ok with 10.4,

Yes, it should be.

but I don't think that is the case, at least it doesn't appear to be
on PPC, unless it is some other issue.

Try fully cleaning out prior installs and try it again. The build for Python 2.6 should certainly work. I'm a little less certain about the build for Python 2.7.

···

On 3/3/11 8:02 PM, Brendan wrote:

--
Robin Dunn
Software Craftsman

Chris_Barker1 · March 4, 2011, 5:16pm

Did you totally clean out prior installs before testing that install?

Actually, I didn't install, I unpacked the mpkg, and I sure thought I had cleared it out first.

wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg and looked at the
contents without installing, and I got this:

dazzler:robind ~/Desktop/usr/local/lib/wxPython-unicode-2.8.11.0/lib

cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI

2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

Very weird, as I did the same thing, and didn't get that. MAybe the file system did something wierd with the cache?

I'll try again and be really careful that I'm doing what I think I'm doing!

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6)

BINGO!

I don't know what the heck I did wrong last time, but this is right now.

Brendan, I think Robin right -- clean out eveything and re-install:

wxPython2.8-osx-unicode-universal-py2.6.pkg

And I think you'll be all set.

-Chris

···

On 3/4/11 9:00 AM, Robin Dunn wrote:

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Brendan_Simon_eTRIX · March 5, 2011, 4:29am

OK. There is definitely some weirdness (i.e. stuff I don't quite
understand) going on. In summary if you "cat" the file then you get
"ABI 102" and "ABI 1002", but if you don't "cat" the file (i.e. access
it directly) then you only get the "ABI 1002".

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

$ strings libwx_macud-2.8.0.7.0.dylib | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

Weird huh. Gotta love our "special" Macs !! A little unix knowledge on
a Mac is dangerous thing

OK. So I reinstalled
wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg and things are
looking better.

It seems that the various wxPython installers do overwrite some shared
files and that is what is causing the problem. The following files are
some that are affected.

$ (cd /usr/local/lib/wxPython-unicode-2.8.11.0/lib/ ; ls -l libwx*)
-rwxr-xr-x 1 root wheel 22513268 21 May 2010 libwx_macud-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 27 5 Mar 15:16 libwx_macud-2.8.0.dylib
-> libwx_macud-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 23 5 Mar 15:16 libwx_macud-2.8.dylib
-> libwx_macud-2.8.0.dylib
-rwxr-xr-x 1 root wheel 555220 21 May 2010
libwx_macud_gizmos-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 34 5 Mar 15:16
libwx_macud_gizmos-2.8.0.dylib -> libwx_macud_gizmos-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 30 5 Mar 15:16
libwx_macud_gizmos-2.8.dylib -> libwx_macud_gizmos-2.8.0.dylib
-rwxr-xr-x 1 root wheel 126400 21 May 2010
libwx_macud_gizmos_xrc-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 38 5 Mar 15:16
libwx_macud_gizmos_xrc-2.8.0.dylib -> libwx_macud_gizmos_xrc-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 34 5 Mar 15:16
libwx_macud_gizmos_xrc-2.8.dylib -> libwx_macud_gizmos_xrc-2.8.0.dylib
-rwxr-xr-x 1 root wheel 178404 21 May 2010
libwx_macud_gl-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 30 5 Mar 15:16
libwx_macud_gl-2.8.0.dylib -> libwx_macud_gl-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 26 5 Mar 15:16
libwx_macud_gl-2.8.dylib -> libwx_macud_gl-2.8.0.dylib
-rwxr-xr-x 1 root wheel 2473272 21 May 2010
libwx_macud_stc-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 31 5 Mar 15:16
libwx_macud_stc-2.8.0.dylib -> libwx_macud_stc-2.8.0.7.0.dylib
lrwxr-xr-x 1 root wheel 27 5 Mar 15:16
libwx_macud_stc-2.8.dylib -> libwx_macud_stc-2.8.0.dylib

i.e. the following installers do have file conflicts when installing.
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.5.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.6.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.7.dmg

with -py2.7 being more problematic for my situation.

Cheers, Brendan.

···

On 5/03/11 4:16 AM, Christopher Barker wrote:

On 3/4/11 9:00 AM, Robin Dunn wrote:

Did you totally clean out prior installs before testing that install?

Actually, I didn't install, I unpacked the mpkg, and I sure thought I
had cleared it out first.

wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg and looked at the
contents without installing, and I got this:

dazzler:robind ~/Desktop/usr/local/lib/wxPython-unicode-2.8.11.0/lib

cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI

2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

Very weird, as I did the same thing, and didn't get that. MAybe the file
system did something wierd with the cache?

I'll try again and be really careful that I'm doing what I think I'm doing!

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

BINGO!

I don't know what the heck I did wrong last time, but this is right now.

Brendan, I think Robin right -- clean out eveything and re-install:

wxPython2.8-osx-unicode-universal-py2.6.pkg

And I think you'll be all set.

Brendan_Simon_eTRIX · March 7, 2011, 11:41am

I have a project that uses python-2.5 and must run on 10.4 on both Intel
and PPC. I was planning on updating to python-2.7 but I don't think I
can now as it doesn't look like it works on PPC (though Robin suggested
that it should).

I also have some new projects which I intend to use python-2.7.

So is there a way to develop wxPython apps with different versions of
python (2.5 & 2.7) on the same host (Intel OS X 10.6) ??

Is there something smart that could be done with py2app perhaps to copy
appropriate files from appropriate directories ??

Or am I just going to have to wait for a new release of wxPython that
addresses these issues ??

Thanks, Brendan.

···

On 5/03/11 3:29 PM, Brendan Simon (eTRIX) wrote:

On 5/03/11 4:16 AM, Christopher Barker wrote:

On 3/4/11 9:00 AM, Robin Dunn wrote:
Brendan, I think Robin right -- clean out eveything and re-install:
wxPython2.8-osx-unicode-universal-py2.6.pkg

It seems that the various wxPython installers do overwrite some shared
files and that is what is causing the problem. The following files are
some that are affected.

i.e. the following installers do have file conflicts when installing.
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.5.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.6.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.7.dmg

with -py2.7 being more problematic for my situation.

Chris_Barker1 · March 7, 2011, 6:11pm

OK. There is definitely some weirdness (i.e. stuff I don't quite
understand) going on. In summary if you "cat" the file then you get
"ABI 102" and "ABI 1002", but if you don't "cat" the file (i.e. access
it directly) then you only get the "ABI 1002".

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

$ strings libwx_macud-2.8.0.7.0.dylib | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

In this case, you are only getting the Intel part -- I wonder if that is because the file system splits them out somehow, but if there is an endianess weirdness (though single byte characters shouldn't be effected by that). Interesting though -- I've seen a number of "useless uses of cat" threads about shell use, but this is one that turns out to be useful!

It seems that the various wxPython installers do overwrite some shared
files and that is what is causing the problem. The following files are
some that are affected.

...

i.e. the following installers do have file conflicts when installing.
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.5.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.6.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.7.dmg

with -py2.7 being more problematic for my situation.

Robin, given that py2.7 is being built in a different way, perhaps each py version should put stuff in different directory (or a different name). It would be redundant in some cases, but more robust in the face of these issues

-Chris

···

On 3/4/11 8:29 PM, Brendan Simon (eTRIX) wrote:

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Robin · March 7, 2011, 7:11pm

OK. There is definitely some weirdness (i.e. stuff I don't quite
understand) going on. In summary if you "cat" the file then you get
"ABI 102" and "ABI 1002", but if you don't "cat" the file (i.e. access
it directly) then you only get the "ABI 1002".

$ cat libwx_macud-2.8.0.7.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

$ strings libwx_macud-2.8.0.7.0.dylib | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)

In this case, you are only getting the Intel part -- I wonder if that is
because the file system splits them out somehow, but if there is an
endianess weirdness (though single byte characters shouldn't be effected
by that). Interesting though -- I've seen a number of "useless uses of
cat" threads about shell use, but this is one that turns out to be useful!

I expect that strings is looking at the file and is only using the arch that matches the current runtime environment. When it is fed a stream of bytes from cat instead then it doesn't know where they are coming from and so it has to process the whole stream.

It seems that the various wxPython installers do overwrite some shared
files and that is what is causing the problem. The following files are
some that are affected.

...

i.e. the following installers do have file conflicts when installing.
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.5.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.6.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.7.dmg

with -py2.7 being more problematic for my situation.

Robin, given that py2.7 is being built in a different way, perhaps each
py version should put stuff in different directory (or a different
name). It would be redundant in some cases, but more robust in the face
of these issues

Yep, that makes sense.

···

On 3/7/11 10:11 AM, Christopher Barker wrote:

On 3/4/11 8:29 PM, Brendan Simon (eTRIX) wrote:

--
Robin Dunn
Software Craftsman

Robin · March 7, 2011, 7:12pm

If you use Python 2.5 and Python 2.6 then you should be okay having the same version of wxPython installed for both of them. If you'd rather go with 2.5 and 2.7 then you'll probably need to do a bit of magic. Two ideas come to mind:

1. After installing the wxPython build for one of the Python's move the wx shared libraries to a different location and then use install_name_tool to change the path names for where to find those libraries in the wxPython *.so files. You will probably also need to change them in the wx *.dylib files too. You may run into troubles with install_name_tool only changing the paths for one of the architectures in the fat binaries, so you may need to split them apart with lipo first, change the names in each of the binaries, and then use lipo to put them back together again.

2. Using a different version number of wxPython for each version of Python should also work.

···

On 3/7/11 3:41 AM, Brendan Simon (eTRIX) wrote:

On 5/03/11 3:29 PM, Brendan Simon (eTRIX) wrote:

On 5/03/11 4:16 AM, Christopher Barker wrote:

On 3/4/11 9:00 AM, Robin Dunn wrote:
Brendan, I think Robin right -- clean out eveything and re-install:
wxPython2.8-osx-unicode-universal-py2.6.pkg

It seems that the various wxPython installers do overwrite some shared
files and that is what is causing the problem. The following files are
some that are affected.

i.e. the following installers do have file conflicts when installing.
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.5.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.6.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.7.dmg

with -py2.7 being more problematic for my situation.

I have a project that uses python-2.5 and must run on 10.4 on both Intel
and PPC. I was planning on updating to python-2.7 but I don't think I
can now as it doesn't look like it works on PPC (though Robin suggested
that it should).

I also have some new projects which I intend to use python-2.7.

So is there a way to develop wxPython apps with different versions of
python (2.5& 2.7) on the same host (Intel OS X 10.6) ??

Is there something smart that could be done with py2app perhaps to copy
appropriate files from appropriate directories ??

Or am I just going to have to wait for a new release of wxPython that
addresses these issues ??

--
Robin Dunn
Software Craftsman

Brendan_Simon_eTRIX · March 7, 2011, 9:19pm

IMHO, they do need to be in totally separate directories to retain the integrity of each build. The only time they should overwrite common files is if the files are guaranteed to be identical (a very big ask) or if they are some kind of configuration file that will be backward and forward compatible (doable but still risky). If there must be a some files in a common place then it is probably better to have symlinks to the files stored in the individual directories, but I still think that approach is error prone.

py2app would need to pull the appropriate wx libraries from the appropriate install directory. I don't think that would be a big problem.

Cheers, Brendan.

···

On 8/03/2011 5:11 AM, Christopher Barker wrote:

On 3/4/11 8:29 PM, Brendan Simon (eTRIX) wrote:

It seems that the various wxPython installers do overwrite some shared
files and that is what is causing the problem. The following files are
some that are affected.

i.e. the following installers do have file conflicts when installing.
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.5.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.6.dmg
wxPython2.8-osx-unicode-2.8.11.0-universal-py.2.7.dmg

with -py2.7 being more problematic for my situation.

Robin, given that py2.7 is being built in a different way, perhaps each py version should put stuff in different directory (or a different name). It would be redundant in some cases, but more robust in the face of these issues