[R-pkg-devel] set pkg_config for 3rd party software

[Martin Maechler]

>>>>> 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 using 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 using 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