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

Martin Maechler m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Fri Sep 6 12:17:39 CEST 2019


>>>>> Ralf Stubner 
>>>>>     on Fri, 6 Sep 2019 11:22:15 +0200 writes:

    > On Thu, Sep 5, 2019 at 6:36 PM Martin Maechler
    > <maechler using stat.math.ethz.ch> wrote:
    >> For me (on Fedora 30)
    >> 
    >> $ R CMD config LDFLAGS
    >> -L/usr/lib64

    > This looks wrong. I would expect that /usr/lib64 is one of the
    > standard directories that are searched anyway. So why put it into the
    > very beginning of the search? BTW, this does not happen on Debian:

    > $ R CMD config LDFLAGS
    > -Wl,-z,relro

Thank you very much, Ralf!
Indeed my conclusion was wrong .. If I use Fedora's own R package,
then I also get something like the above :

 $ /usr/bin/R CMD config LDFLAGS
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

(amazingly long ..)

It's just when I -- as in 99.9% of cases, as an R Core developer --
use my own built version of R, I get what you call "wrong".

... and it's  "of course" from my  ~/.R/config  settings
where added a comment for this explicit LDFLAGS setting, mentioning that
otherwise it would take -L/usr/local/lib64 and that *is*
unfortunately still true:

In current R incl R-devel's  <Rsource>/configure.ac  (lines 157-167)
LDFLAGS *is* set to this :
--------------------------------------------------------------------
: ${LIBnn=$libnn}
## We provide these defaults so that headers and libraries in
## '/usr/local' are found (by the native tools, mostly).
if test -f "/sw/etc/fink.conf"; then
  : ${CPPFLAGS="-I/sw/include -I/usr/local/include"}
  : ${LDFLAGS="-L/sw/lib -L/usr/local/lib"}
else
  : ${CPPFLAGS="-I/usr/local/include"}
  : ${LDFLAGS="-L/usr/local/${LIBnn}"}
fi
AC_SUBST(LIBnn)
--------------------------------------------------------------------

and that setting *did* harm me in the (relatively distant, ~ 7 years?)
past, and so I had replaced it with the  /usr/lib64  setting.

Hmm, maybe this should all have been on the  R-devel  mailing
list instead, and we should start asking if R's  configure.ac
(and hence configure) should be changed ?

Martin



More information about the R-package-devel mailing list