Re: [R-pkg-devel] set pkg_config for 3rd party software
Martin, On 6 September 2019 at 07:19, Dirk Eddelbuettel wrote: | So can't you replace / update that package? That's what I do over in the | .deb world, and for Ubuntu it is particularly easy with PPAs. And then there is of course this too: edd@rob:~$ pkg-config --modversion nlopt 2.4.2 edd@rob:~$ pkg-config --modversion quantlib 1.16 edd@rob:~$ so eg in QuantLib (which uses its own quantlib-config from going back to the days before we had pkg-config) I test for minimally-viable versions, and only if pkg-config reveals and insufficient version do I check explicit configure options to supply a library dir and include dir. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
Martin, And not to beat a dead horse, but isn't the root cause the outdated rpm? So can't you replace / update that package? That's what I do over in the .deb world, and for Ubuntu it is particularly easy with PPAs. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
> Ralf Stubner
> on Fri, 6 Sep 2019 11:22:15 +0200 writes:
> On Thu, Sep 5, 2019 at 6:36 PM Martin Maechler
> 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 /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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
On Thu, Sep 5, 2019 at 6:36 PM Martin Maechler
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
> 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.
I see no way to correct this within a package. The only thing that
comes to mind is adding a test in `configure{.ac}` that will fail when
a to old version of libmpfr is actually used for linking. If the test
fails, one can at least give an informative message. Then either an
admin corrects the configuration or the user overwrites LDFLAS in
~/.R/Makevars.
cheerio
ralf
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
> 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@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 .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
/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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
On Thu, Sep 5, 2019 at 12:27 PM Martin Maechler
wrote:
> 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 ?
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
cheerio
ralf
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
On 05/09/2019 12:26, Martin Maechler wrote:
Sameh M Abdulah
on Fri, 30 Aug 2019 18:50:55 + 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
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories
)
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
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
)
Best,
Serguei.
Notably it will contain '-lmpfr -lgmp' among the LDFLAGS in
any case.
Now back to the 'pkg-config' : The compiler *also* needs correct
-I (the path used by ' #include <...> ' statement)
and for linking a correct -L.
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
> Sameh M Abdulah
> on Fri, 30 Aug 2019 18:50:55 + 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.
Notably it will contain '-lmpfr -lgmp' among the LDFLAGS in
any case.
Now back to the 'pkg-config' : The compiler *also* needs correct
-I (the path used by ' #include <...> ' statement)
and for linking a correct -L.
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
