[SciPy-user] OS-X Universal binary?

[Robert Kern]

On Thu, Mar 26, 2009 at 15:46, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> On Fri, Mar 27, 2009 at 2:11 AM, Chris Barker
>> <Chris.Barker at 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
-Wl,-search_paths_first"
 $ 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

 build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so:
       /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
(compatibility version 1.0.0, current version 4.0.0)
       /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
88.3.7)

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.
"""

-- 
Robert Kern

"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