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
