>>>>> 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
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
