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

Serguei Sokol @ergue|@@oko| @end|ng |rom gm@||@com
Thu Sep 5 14:46:17 CEST 2019

On 05/09/2019 12:26, Martin Maechler wrote:
>>>>>> Sameh M Abdulah
>>>>>>      on Fri, 30 Aug 2019 18:50:55 +0000 writes:
>      > Hi,
>      > I recently asked some questions about my R package which were well responded by Dirk.
>      > I have another question related to pkg_config path,
>      > I am using this command to add the installation path to the PKG_CONFIG_PATH   so that all cmake commands can get the required libraries from this path,
>      > Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':'))
>      > Is there a simple way to set this path without explicitly calling this line before installing my package? OR is there any other path that I can use so that all software CMake commands can easily find the required libraries?
>      > --Sameh
> Not an answer, but a  #METOO   with a hopefull very related
> question, also on using 'pkg-config' (Note: "-", not "_" here)
> for package configuration.
> I'm maintainer of CRAN package Rmpfr (for arbitrary precise arithmetic..),
>      https://cran.r-project.org/package=Rmpfr
> development & source on R-forge
>       http://rmpfr.r-forge.r-project.org/
> and  https://r-forge.r-project.org/scm/viewvc.php/pkg/?root=rmpfr
> which "down there"  is principally an interface to the GNU MPFR
> C library (which also needs the GNU  GMP C library).
> I do have a  Rmpfr/configure.ac from which to produce
> Rmpfr/configure which then ensures that both libraries (MPFR and GMP)
> are found and are "working".
> The 'configure' script then (supposedly, but not on Windows?) takes
> either src/Makevars.in  (non-Windows)
> or     src/Makevars.win (Windows)
> to produce  src/Makevars
> which then is used during compilation of the C sources of my
> package.
I have a small marginal remark about this.
Makevars.win is not windows equivalent of Makevars.in but of plain 
Makevars (see
On windows, you can use configure.win which in turn can use 
Makevars.win.in to produce Makevars.win. The latter will be used by make 
on that platform (see 


> Notably it will contain   '-lmpfr -lgmp'  among the LDFLAGS in
> any case.
> Now back to the 'pkg-config' : The compiler *also* needs correct
> -I<path>  (the path used  by ' #include <...> ' statement)
> and for linking a correct  -L<path>.
> Now, my main OS,  Linux Fedora (as all other decent Linux distributions)
> does provide MPFR and GMP libraries (and include headers) as OS
> packages, installed in  /usr/lib/ (actually /lib64 nowadays)
> and /usr/include respectively.
> However, for some reasons I don't know the *version* of the MPFR
> library that the OS provides is outdate (to my taste), and I'd
> really want a newer version of MPFR,  which I easily install in
> a version of /usr/local/..... *and* I also make sure that
>      pkg-config --libs mpfr
> and pkg-config --cflags mpfr
> list the corresponding LDFLAGS  and CFLAGS
> (the first giving
>    -L/usr/local.../mpfr/4.0.1/lib -lmpfr -lgmp
>   the 2nd
>    -I/usr/local.../mpfr/4.0.1/include
> )
> Now what is the officially / best way to have either 'configure'
> or  Makevars.{in,win}  use the 'pkg-config' information
> *dynamically*, i.e.,
> if I update my MPFR from 4.0.1 to 4.0.2  the newer 4.0.2 is found ?
> My current setup would not even work on some platforms to really
> end up using my local version of MPFR instead of the system-wide
> OS default (using /lib64 and /usr/include/ and then
> which even with quite new Fedora 30 is still MPFR 3.1.6 .. much
> too old for some of the things I want).
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

More information about the R-package-devel mailing list