[R-SIG-Mac] Compiling a portable binary that includes Fortran code
Simon Urbanek
simon.urbanek at r-project.org
Tue Sep 20 20:24:40 CEST 2011
On Sep 20, 2011, at 2:09 PM, Charlie Sharpsteen wrote:
> On Monday, September 19, 2011 7:41:08 PM UTC-7, Simon Urbanek wrote:
> Michael,
> the problem has nothing to do with your package (you should not be touching any flags at all), but rather the Fortran you use.
>
> If you have both static and dynamic fortran runtime, the dynamic one has always precedence. So there are essentially two possible ways forward:
>
> a) use static Fortran runtime. It simply means moving /usr/local/lib/libgfortran.dylib aside.
>
> b) if you use dynamic Fortran runtime, take the one from R. Since you have R 2.13.x it is shipped in /Library/Frameworks/R.framework/Versions/2.13/Resources/lib/ so you can use it along the lines of
> cd /usr/local/lib
> sudo ln -sfn /Library/Frameworks/R.framework/Versions/2.13/Resources/lib/libgfortran.2.dylib .
> sudo ln -sfn libgfortran.2.dylib libgfortran.dylib
> Alternatively you can simply use install_name_tool to point your package to R's runtime.
>
>
> Note that GFortran also has a `-static-libgfortran` flag that will force the compiler to select the static runtime library over the dynamic one. Using this flag should remove any need to move libraries around or muck about with `install_name_tool` (unless your package has other dynamic dependencies).
>
> Hope that helps!
>
Not in this case, because this linking is not done by gfortran so the flag has no effect. The problem with linking mixed code is that you have to use g++ for linking so the Fortran runtime must be linked "by hand". R takes care of this but it means you get your fortran used at configure time which in Michael's case is dynamic linking.
Cheers,
Simon
More information about the R-SIG-Mac
mailing list