In article <CACgdh2igu5JEeHEO4EVA6=TiqqvosX1z_CuQ=Ti5Axbf=lc...@mail.gmail.com>, Paul Wiseman <poal...@gmail.com> wrote: > I'm currently using the installer with py2app to make a distributable > app that targets 10.5+ (including ppc). To save having more than one > build I use this for all downloads. Although I'm starting to consider > making a second 32/64 distributable. Are there many major drawbacks > for distributing this i386/ppc binary for all versions of OSX up 10.9 > and 10.10?
For a standalone app, not really. The main difference is that, by using the older 10.5 ABI, a few functions in the os module are not available (if they were implemented first in OS X 10.6 or later) and/or they may work a little differently. AFAIK, the most impactful difference, by far, is the OpenSSL version difference you have run into. Up to now, I don't recall any compatibility problems with 10.5 ABI programs running on later versions of OS X or, for the most part, mixing extension modules compiled to later ABIs with a 10.5 Python, although there might be issues with mixing versions of C++ modules (Python and its standard library do not use C++ themselves). But, of course, there's no guarantee that something won't break in a future release of OS X. So far, so good. > That's great news! Thanks for this! I've always found building things > on mac a huge pain and wasn't much looking forward to the prospect of > trying to build a 32/ppc python build on a 64 bit 10.10 machine (would > that even be possible?). It's possible: I do it. But I cheat a bit: I have 10.5 running in a virtual machine on a 10.10 host. In theory, it's possible to build natively on 10.10. The trick is getting a version of Xcode 3 installed on 10.10 since support for building ppc archs was removed in Xcode 4. I also cheat a bit there: I happen to still have copies of Xcode 3.1.4 and 3.2.6 installed on 10.10 because I made sure to preserve them through upgrades from 10.6 days. IIRC, directly installing the necessary components from 3.2.6 on newer systems would require some hacking. Then you have to be really vigilant that the build never strays from the old SDK and tools, which is not something we claim to support at the moment. The VM approach is quite safe and reliable. -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list