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 _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
