In article <CAH6Pt5rZ0hn3BXLn-mEM+nAGyydV0gXtf6EY6T1B3+e=xnn...@mail.gmail.com>, > On Wed, Jun 11, 2014 at 4:58 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > > I know it'a at least theoretically possible to build libs under 10.9 that > > will work on 10.6 -- specifically compatible with the python.org python > > binaries. > > > > But I"m having trouble finding documentation of what flags you need. > > > > MACOSX_DEPLOYMENT_TARGET=10.6 > > > > should be required -- but anything else? > > > > personally, I've solved this by building on the oldest machine I want to > > support, but that's not always possible anymore. > > Have you run into any problems using the deployment target = 10.6? > > I haven't with wheels at least - I'm building on 10.9 and testing on 10.6
It all depends on what you are building. I assume you're talking about non-Python packages here. Many C modules won't be a problem but some will if they use OS-supplied APIs that have changed or been added between the deployment target version of OS X and the build systems's target. If you need to support the full range of systems, your safest best remains to build on deployment target system. Otherwise, until proven otherwise for the particular package, you should be using the SDK for the deployment target version and hope that the build system (Makefile, whatever) for the package builds correctly with an SDK. In many cases it will because Apple cleverly hid much of the SDK and universal arch complexity under the covers in the compiler driver wrappers for cc/gcc/clang. Basically when you use an SDK, the Apple compiler driver automatically prepends the SDK path to all "system" files, those beginning with /System/Library, /Library, and /usr, so that they are picked up from the SDK directory rather than from the running system. But, if the package's build process does something clever, like making its own decisions about where to look for libs or include files that does not take the SDK path into account, you can end up with subtle errors, where the package build is basing decisions on the build system's installed include files (i.e. the 10.9 version) whereas the compiler is actually building with the SDK version (i.e. 10.6) of the file. (Builds of Python itself have run into this problem in the past.) If you want to fully support universal architectures (Intel-32 and Intel-64 for the python.org 64-bit/32-bit installers), you also need to build universal libraries. Adding -arch i386 and -arch x86_64 will usually work but not always (OpenSSL is an example of one where it doesn't). If the package build makes arch dependent decisions at configure time (or the equivalent) or arch-dependent values are in generated include files or something similar, the safest approach is to build each arch separately and then use lipo to combine the separate archs into universal file(s) to be installed. Fortunately, most popular libs either now natively support universal builds or someone has figured out how to do it. The build recipes in MacPorts or homebrew can be of help here. On the most recent versions of OS X, particularly on 10.9, there is better support from the command line tools for building with SDKs by setting the SDKROOT and DEVELOPER_DIR environment variables. See the man page for xcrun (man 1 xcrun) for more details. Also, note that when building C extension modules via Distutils in current Pythons from python.org, the SDK used to build Python is looked for in its original path (for example, /Developer/SDKs/MacOSX10.6.sdk) and, if not found there, the ext module build proceeds without an SDK, using the headers and libs of the installed command line tools. Most of the time that is fine if you are building something to be used solely on the build system's OS level and probably for later systems. -- Ned Deily, n...@acm.org _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
