[SciPy-user] OS-X Universal binary?

David Cournapeau cournape@gmail....
Thu Mar 26 16:03:10 CDT 2009


On Fri, Mar 27, 2009 at 5:54 AM, Robert Kern <robert.kern@gmail.com> wrote:
> On Thu, Mar 26, 2009 at 15:46, Zachary Pincus <zachary.pincus@yale.edu> 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

When I tried something similar, I got the same errors as in the following email:

http://gcc.gnu.org/ml/fortran/2008-12/msg00237.html

There is not much documentation on this, but I wonder why gfortran
would grow a --static-libgfortran if the result was exactly the same
as linking statically libgfortran.a ? You never encounter problems
when statically linking the fortran runtime ?

cheers,

David


More information about the SciPy-user mailing list