Prof Brian Ripley
2009-Feb-03 08:05 UTC
[Rd] Packages should not only search for libraries with particular extensions and paths
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, ripley at 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
Apparently Analagous Threads
- Fwd: Re: Package cwhmisc and problems
- R 2.3.1 and R2.3.0 crash with system() and shell() commands (PR#9208)
- [PATCH] lib: Prefer tirpc for XDR, and rationlise how we search for alternatives.
- R_tryEval not properly documented in 'Writing R Extensions' (PR#9525)
- Java and help.start() search engine