R developers,
I am trying to understand how symbols are resolved, so that I can
configure a package that I contributed to, and so that I can provide
guidance to (linux / OSX) users of the package. To be concrete, my
package uses the LAPACK Fortran symbol zsysv. This is not in
libRlapack, but is defined on my system in the library
/usr/lib64/liblapack.so.
* I suspect that the reason the symbol is not in libRlapack is just
one of economy, i.e., no use for the symbol in R routines, rather
than for other nefarious reasons (?? some fundamental incompatibility
with R?)
I guess that most of my package users will have an R built without
special attention to their lapack library, so will start with
something like
[EMAIL PROTECTED]:~> R CMD config LAPACK_LIBS
-L/home/mtmorgan/arch/x86_64/R-devel/lib -lRlapack
My R is built with --enable-R-shlib, so predictably enough
R CMD INSTALL --clean <pkg>
is 'successful' (zsysv_ is marked as unresolved in the <pkg>.so, but
this doesn't stop compiling and linking). Also predictably enough,
loading the package in R indicates 'undefined symbol: zsysv_'. Inside
R, LD_LIBRARY_PATH starts with he R_HOME/lib, and includes /usr/lib64,
so I surmise that the libraries defined at compile / link are the ones
where symbols are searched (rather than all libraries in
LD_LIBRARY_PATH).
To allow the user to provide a specific LAPACK, I added lines to a
configure.in file that allow for a --with-lapack
LAPACK_LIBS=`"${R_HOME}/bin/R" CMD config LAPACK_LIBS`
AC_ARG_WITH([lapack],
AC_HELP_STRING([--with-lapack=LIB_PATH],
[LAPACK library location with complex routines]),
[LAPACK_LIBS=$withval])
added a check to see that zsysv_ is actually available
AC_CHECK_FUNC(zsysv_,,
AC_MSG_ERROR([lapack needs zsysv_ in ${LAPACK_LIBS}]))
and substituted LAPACK_LIBS into a Makevars.in file
AC_SUBST(LAPACK_LIBS)
AC_OUTPUT(src/Makevars)
Makevars.in:
[EMAIL PROTECTED]@
I then install my package with
R CMD INSTALL --clean --configure-args=--with-lapack=-llapack <pkg>
or more generally
R CMD INSTALL --clean \
--configure-args="--with-lapack='-L/usr/lib64 -llapack'" <pkg>
This 'works', in the sense that the package compiles, loads, and
apparently runs as expected. I'm concerned though about how lapack is
being found, and how symbols are actually being resolved.
When I
[EMAIL PROTECTED]:~> ldd <pkg>.so
I see an entry
liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00002b0928a1c000)
and I do NOT see an entry pointing to libRlapack .Am I right in
interpreting this to mean:
* All LAPACK symbols in my package, including those that
coincidentally have a definition in libRlapack, resolve to
/usr/lib64/liblapack.so?
* liblapack.so will be found without any need to specify
LD_LIBRARY_PATH, or other configuration variables? Or is the library
being found because my LD_LIBRARY_PATH already includes /usr/lib64?
If the latter, how can the user 'best' configure their system to
find the required library (I think I'm looking for something between
'get the system administrator to install lapack in a findable place'
and 'set LD_LIBRARY_PATH before starting R').
* Resolving symbols to libraries will occur in a way consistent with
the last two points (as opposed to the implementation details)
across platforms, compilers, and static vs. shared libraries?
Thanks for any reassurance or corrective guidance.
Martin
--
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
