MichaelChirico
commented
4 years ago This only happens if
-
you use --enable-R-shlib (not the default).
-
used make install-libR or similar (not the default, not recommended).
A change will be made in R-devel (3.2.0 to be).
METADATA
- Comment author - Brian Ripley
- Timestamp - 2014-05-18 14:15:49 UTC
Building R-3.0.3 on OS X with various dependencies supplied by fink (the /sw paths), I get linker calls such as:
gcc -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/sw/lib -o mgcv.dylib gdi.o init.o magic.o mat.o matrix.o mgcv.o misc.o qp.o soap.o sparse-smooth.o tprs.o -framework Accelerate -framework Accelerate -L/sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0 -L/sw/lib/gcc4.9/lib -lgfortran -lquadmath -lm -L/sw/build.build/r-base30-3.0.3-4/R-3.0.3/lib -lR -lintl -Wl,-framework -Wl,CoreFoundation
The goal is to link against libR, which was also compiled as part of this build process. But the list of -L flags has the local one (to resolve -lR to that just-built lib) last. This fails because I have an existing libR in /sw/lib (from an already-installed other version of R), so the linker finds the wrong one (-L are checked in order). In general, always want to list local source/build dirs before any flags from external/system dependencies. Even better, just link directly to the libR file (100% foolproof) rather than relying on -L searching for -l at all. This also protects against parallel-build accidents. For example, if the local libR failed to build or had not yet finished in one thread before this linker call happens in another, even if the correct -L is first, the lib won't exist there and the wrong one will be found.
METADATA