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.jor...@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
>
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
