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

[Martin Maechler]

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

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