Bug 15790 - Using -L and -lR in own build finds wrong library
Summary: Using -L and -lR in own build finds wrong library
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: Installation (show other bugs)
Version: R 3.0.3
Hardware: All All
: P5 normal
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2014-05-03 18:19 UTC by Daniel Macks
Modified: 2014-05-18 14:15 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Macks 2014-05-03 18:19:10 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.
Comment 1 Brian Ripley 2014-05-18 14:15:49 UTC
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).