Every time I set up a new machine I find myself needing to circumvent
the obstructions placed by a few package writers who don't understand
enough about (compiled code) libraries.
Their mistakes include hardcoding a library extension (.so or .a)
and/or a set of paths such as
/usr/lib /usr/local/lib /opt/lib ...
Different OSes do have different conventions, especially where
multiple architectures co-exist. (E.g. most but not all x86_64 Linux
use lib64, and Solaris uses lib/amd64 etc.) This means that a library
of the right name but the wrong architecture may be found in, say,
/usr/local/lib.
The correct dynamic library extension can be (at least) .so, .sl,
.dylib or .dll. (On Darwin aka Mac OS X dynamic libraries and shared
objects are not the same thing, and can contain one or more
architectures.) But really only the linker needs to know that, and
autoconf's AC_SEARCH_LIBS and similar are a much more reliable test.
Even if your script finds what looks like a library in a non-standard
place, it does not mean that either or both of the linker or the
run-time loader ('ld.so') can find or use it.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
