>>>>> Martin Maechler >>>>> on Thu, 5 Sep 2019 18:36:03 +0200 writes:
>>>>> Dirk Eddelbuettel >>>>> on Thu, 5 Sep 2019 10:14:21 -0500 writes: >> On 5 September 2019 at 16:53, Ralf Stubner wrote: >> | I don't know what is best, but here are three alternatives: >> | >> | * Use PKG_CHECK_MODULES which sets up default variables with _CFLAGS >> | and _LIBS suffix after searching for a library with pkg-config, c.f. >> | https://autotools.io/pkgconfig/pkg_check_modules.html >> | * Call pkg-config by hand in configure.ac (and hence configure). >> | Example: https://github.com/eddelbuettel/rcppredis/blob/master/configure.ac#L47-L60 >> | * Call pkg-config within an "Anticonf" configure script. Example: >> | https://github.com/jeroen/curl/blob/master/configure#L16-L24 >> Make it four alternatives: >> * Call pkg-config from an autoconf configure script. Examples: >> edd@rob:~$ grep -l pkg-config git/*/configure.{ac,in} >> git/libxls/configure.ac >> git/nloptr/configure.ac >> git/rcppmlpack2/configure.ac >> git/rcppredis/configure.ac >> git/rprotobuf/configure.ac >> edd@rob:~$ >> I know all the cool kids these days hate autoconf, but it a) really is just >> careful (and more portable) shell scripting (plus some extra glue). And it >> b) avoids having users on some marginal OSs yell at you when they do not have >> bash (just yesterday a Nix user had to comment on a five year old bug in that >> is no longer valid as we went back to autoconf there too). As an extra bonus >> it c) also works on Slowlaris. >> Best, Dirk > Thank you, Ralf, and Dirk.... that was very useful already ! > However, the real problem I am fighting still is not related to > `pkg-config` and friends at all, but to the fact that my OS has > a version of libmpfr in the main system library and that seems > to be used in *any* case when the final <pkg>.so file is linked > together: > For me (on Fedora 30) > $ R CMD config LDFLAGS > -L/usr/lib64 > $ ls -l /usr/lib64/libmpfr* > lrwxrwxrwx. 1 root root 16 Feb 2 2019 /usr/lib64/libmpfr.so -> libmpfr.so.4.1.6 > lrwxrwxrwx. 1 root root 16 Feb 2 2019 /usr/lib64/libmpfr.so.4 -> libmpfr.so.4.1.6 > -rwxr-xr-x. 1 root root 827872 Feb 2 2019 /usr/lib64/libmpfr.so.4.1.6 > and for that reason, when R CMD INSTALL Rmpfr ... > gets to the final linking, it uses > gcc -shared -L/usr/lib64 -o Rmpfr.so Ops.o .... utils.o -L/usr/local.../mpfr/4.0.2/lib -lmpfr -lgmp > and the early -L/usr/lib64 just "ensures" that my package lib > (Rmpfr.so) is linked against /usr/lib64/libmpfr.so.4.1.6 which > is old and I "hate" rather than against the much better > libmpfr.so.6.0.2 which would be found in /usr/local.../mpfr/4.0.2/lib > Yes, on a machine with root permission I can hack around to get > what I want, but of course I'd really like 'R CMD INSTALL ..' > to do the "right thing" > just from my configure plus src/Makevars{.in} files. > Yes, I tried 'LDFLAGS = ' (to set it to "empty") in > src/Makevars* but that did not help either. > Martin I now finally did what most of us should do before posting here: Carefully consulting the famous WRE "Writing R Extensions" R Manual, notably the section ('1.2.1' currently), named "Using Makevars" : https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars and came to the conclusion that at least for now, I have to revert to using a 'src/Makefile' instead of just Makevars files, the main reason being that R's own <R>/etc/Makevars file is included *after* the package src/Makevars file and so it does not help if I (un)set LDFLAGS in the latter. Thank you for listening - it helped me to get to a more systematic answer (and if you find that my conclusion has been wrong, I'm happy to hear about that). Martin ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel