[R-SIG-Mac] Installing source package/altering fortran location

[Simon Urbanek]

Mick,

the linked path is governed by the library itself - in particular the ID entry of it. So, for example, R's libraries have:

$ otool -L /Library/Frameworks/R.framework/Resources/lib/libRblas.dylib
/Library/Frameworks/R.framework/Resources/lib/libRblas.dylib:
	/Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

Note the first line - that is the ID line. When you link against that binary, that's what the resulting binary will refer to. I bet the FastR binary doesn't have the correct ID - you can fix it using 

install_name_tool -id <id-entry> <library>

so the above would be

install_name_tool -id /Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libRblas.dylib /Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libRblas.dylib

There a some projects that are clueless about OS X and require DYLD_LIBRARY_PATH because they don't set the id correctly. That is a bug in the library, you should never set DYLD_LIBRARY_PATH because it breaks the search path very badly (it is NOT the same as LD_LIBRARY_PATH on unix which people confuse a lot). A little more sane way is to use DYLD_FALLBACK_LIBRARY_PATH which is more akin to LD_LIBRARY_PATH on Linux, but only as a last resort.

Cheers,
Simon



> On Mar 16, 2016, at 4:57 PM, Mick Jordan <mick.jordan at oracle.com> wrote:
> 
> On 3/16/16 1:25 PM, Simon Urbanek wrote:
>> Mick,
>> 
>> you're using Homebrew's gfortran, so you're pretty much on your own, because that's not what CRAN R was compiled with so it won't work. Since Homebrew messes with /usr/local (unless you tell it not to and install is elsewhere - which is a actually a good idea) it may be easier to just completely move it aside and just install the CRAN complier from
>> http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
>> 
>> The other alternative is to use Homebrew entirely, including R, but then you have to install all packages from sources and/or through Homebrew. You can't mix CRAN and Homebrew because CRAN uses native libraries while Homebrew uses its own (incompatible) world.
>> 
>> 
> Yes, I am beginning to question the sanity of using either HomeBrew or Macports (we had a LIB_ICONV problem yesterday due to a separate Macports install).
> 
> However, in this case, my problem was typo. I forgot the -L on the second library. With that it does link. Not sure why the .R/Makevars override didn't work but that's ok.
> 
> The real problem I am trying to resolve (and why I wanted to look at the GnuR installed library) is why in FastR we can't resolve the libRlapack or libRblas libraries when loading the actuar (and other) packages. This is all fallout from the El Cap decision to neuter DYLD_LIBRARY_PATH which we used to use and still do on Linux. otool -L on the GnuR installed library shows absolute paths for these libs referencing /Library/Frameworks/R.framework, which I assume comes from these options I see from the install: -L/Library/Frameworks/R.framework/Resources/lib -lRlapack, i.e:
> 
> otool -L $R_LIBS_USER/actuar/libs/actuar.so
> /Users/mjj/R_libs_gnur/actuar/libs/actuar.so:
>    actuar.so (compatibility version 0.0.0, current version 0.0.0)
> /Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libRlapack.dylib (compatibility version 3.2.0, current version 3.2.4)
> /Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
>    /usr/local/opt/gcc/lib/gcc/4.9/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
>    /usr/local/opt/gcc/lib/gcc/4.9/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)
>    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
> /Library/Frameworks/R.framework/Versions/3.2/Resources/lib/libR.dylib (compatibility version 3.2.0, current version 3.2.4)
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1256.14.0)
> b
> 
> FastR passes what I consider equivalent options, e.g: -L/Users/mjj/ews/fastr_dev_home/fastr/lib -lRlapack
> 
> However, otool -L on the resulting library shows only a relative path, i.e:
> 
> otool -L ~/tmp/libtmp2/actuar/libs/actuar.so
> /Users/mjj/tmp/libtmp2/actuar/libs/actuar.so:
>    actuar.so (compatibility version 0.0.0, current version 0.0.0)
>    libRlapack.dylib (compatibility version 3.2.0, current version 3.2.4)
>    libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
>    /usr/local/opt/gcc/lib/gcc/4.9/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
>    /usr/local/opt/gcc/lib/gcc/4.9/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)
>    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
> 
> So it seems as if the -L option is not having the effect I expect, which begs the question as to what does produce the absolute path in GnuR? Is it it somehow related to the framework args?
> 
> Mick
>