[SciPy-user] OS-X Universal binary?
Thu Mar 26 15:54:08 CDT 2009
On Thu, Mar 26, 2009 at 15:46, Zachary Pincus <email@example.com> wrote:
>> On Fri, Mar 27, 2009 at 2:11 AM, Chris Barker
>> <Chris.Barker@noaa.gov> wrote:
>>> OK -- it turns out that the Universal binary has more than just the
>>> Universal issue. The extensions depend on libgfortran, too
>> Hm, right - that by itself is expected. I guess we never thought about
>> it because every developer has gfortran. But surely, it cannot work as
>> we do currently.
>> That's actually a non trivial problem, unless libgfortran can easily
>> be statically linked. Hm...
> In the past, (I think) I've forced static linkage by hiding
> libgfortran.dylib and *just* having libgfortran.a where the linker can
> find it. (On OS X there's no other reliable way to force static
> linkage of anything, so much does the linker prefer dylibs!) This
> worked for me when I needed to distribute bits of scipy that I'd
> parted out for other purposes, and built as 2-way (32bit i386/PPC) fat
> binaries. But that was with a previous version of gfortran from the R
> tools site.
Actually, there is. Use -Wl,-search_paths_first to tell the linker to
look at your -L flags before the standard locations. From a snippet of
email I (apparently) have to trot out every few months or so:
And, if you copy the libgfortran.a file to somewhere else, say ~/staticlibs/,
you can force the linker to use it instead of the .dylib such that your users
don't need to install gfortran.
$ export LDFLAGS="-undefined dynamic_lookup -bundle -arch i386 -arch ppc
$ python setup.py config_fc --fcompiler=gnu95 --arch="-arch i386 -arch ppc"
build_ext -L ~/staticlibs/ build
$ file build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so
build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so: Mach-O universal binary
with 2 architectures
build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so (for architecture i386):
Mach-O bundle i386
build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so (for architecture ppc):
Mach-O bundle ppc
$ otool -L build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so
(compatibility version 1.0.0, current version 4.0.0)
/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
The pointer to /usr/local/lib/libgcc_s.1.dylib is innocuous. That's just the
first place it will look for that library at runtime. There's one in /usr/lib
that appears to be picked up and used just fine.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the SciPy-user