Skip to content

cannot install rgdal after updating to fedora32

14 messages · Veronica Andreo, Erwan LE PENNEC, Ista Zahn +2 more

Original
Veronica Andreo
# 
Hello everyone

I have just updated my system to fedora 32 (which fetched GDAL 3 and PROJ
6) and when updating my R packages, I get the following error for rgdal.
Can someone help me out here? What does it mean that it cannot run C++
compiled programs?  And do I want to crosscompile?

Thanks much in advance

Vero

---

install.packages("rgdal")
Installing package into
?/home/veroandreo/R/x86_64-redhat-linux-gnu-library/3.6?
(as ?lib? is unspecified)
trying URL 'http://cran.rstudio.com/src/contrib/rgdal_1.5-12.tar.gz'
Content type 'application/x-gzip' length 2302403 bytes (2.2 MB)
==================================================
downloaded 2.2 MB

* installing *source* package ?rgdal? ...
** package ?rgdal? successfully unpacked and MD5 sums checked
** using staged installation
configure: R_HOME: /usr/lib64/R
configure: CC: gcc -m64
configure: CXX: g++ -m64 -std=gnu++11
configure: CXX11 is: g++ -m64, CXX11STD is: -std=gnu++11
configure: CXX is: g++ -m64 -std=gnu++11
configure: C++11 support available
configure: rgdal: 1.5-12
checking for /usr/bin/svnversion... yes
configure: svn revision: 1018
checking for gdal-config... /usr/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.0.4
checking GDAL version >= 1.11.4... yes
checking GDAL version <= 2.5 or >= 3.0... yes
checking GDAL: linking with --libs only... yes
checking GDAL: gdal-config data directory readable... yes
checking GDAL: /usr/share/gdal/stateplane.csv readable... yes
configure: pkg-config proj exists, will use it
configure: PROJ version: 6.3.2
configure: PROJ CPP flags: -DPROJ_H_API
configure: PROJ LIBS: -lproj
checking PROJ header API:... yes
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in
`/home/veroandreo/tmp/Rtmpo7AtPr/R.INSTALL12cc66f8f895/rgdal':
configure: error: cannot run C++ compiled programs. <<<<--- here
If you meant to cross compile, use `--host'.
See `config.log' for more details
ERROR: configuration failed for package ?rgdal?
* removing ?/home/veroandreo/R/x86_64-redhat-linux-gnu-library/3.6/rgdal?
* restoring previous
?/home/veroandreo/R/x86_64-redhat-linux-gnu-library/3.6/rgdal?
Warning in install.packages :
  installation of package ?rgdal? had non-zero exit status

---

sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Fedora 32 (Thirty Two)

Matrix products: default
BLAS/LAPACK: /usr/lib64/libopenblas-r0.3.9.so

Random number generation:
 RNG:     Mersenne-Twister
 Normal:  Inversion
 Sample:  Rounding

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.6.3 tools_3.6.3
Veronica Andreo
# 
See the attached config.log file

El s?b., 27 jun. 2020 a las 21:29, Veronica Andreo (<veroandreo at gmail.com>)
escribi?:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://stat.ethz.ch/pipermail/r-sig-geo/attachments/20200627/97f66de5/attachment.html>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: text/x-log
Size: 8207 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-geo/attachments/20200627/97f66de5/attachment.bin>
Roger Bivand
# 
Vero,
On Sat, 27 Jun 2020, Veronica Andreo wrote:

            

      
      
      
    

        
How did you install R itself? If an rpm, then

https://github.com/r-spatial/sf/issues/1369

may be relevant, also if you see errors installing sf. You would need to 
unset LDFLAGS before installing:

https://github.com/r-spatial/sf/issues/1369#issuecomment-614096865

Please report back on this.

Roger

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Sun, 28 Jun 2020, Roger Bivand wrote:

        

            

      
      
      
    

        
LDFLAGS needs unsetting. Revision 1020 on R-Forge

https://r-forge.r-project.org/R/?group_id=884

includes a new configure argument --disable-loadflags to assist in 
unsetting the very specific R rpm LDFLAGS. Please report if this fixes the 
problem.

Roger

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Veronica Andreo
    

    

      
      #
    

  


  

      
Dear Roger,

Thanks for the answer.

R is installed from Fedora repos and no, I do not have any issues with sf.
It installs and loads just fine.

I downloaded the new rgdal tar.gz from R-forge, but I get the same error
that was reported yesterday; config.log file attached. The first error I
see there is in line 98-99 about a -V not recognized and then another one
for -qversion. Are those relevant?

Vero
---
install.packages("~/Downloads/rgdal_1.5-13.tar.gz", repos = NULL, type =
"source")
Installing package into
?/home/veroandreo/R/x86_64-redhat-linux-gnu-library/3.6?
(as ?lib? is unspecified)
* installing *source* package ?rgdal? ...
** using staged installation
configure: R_HOME: /usr/lib64/R
configure: CC: gcc -m64
configure: CXX: g++ -m64 -std=gnu++11
configure: CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
configure: CPPFLAGS: -I/usr/local/include
configure: LDFLAGS: -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
loadflags: yes
configure: LDFLAGS: -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
configure: CXX11 is: g++ -m64, CXX11STD is: -std=gnu++11
configure: CXX is: g++ -m64 -std=gnu++11
configure: C++11 support available
configure: rgdal: 1.5-13
checking for /usr/bin/svnversion... yes
cat: inst/SVN_VERSION: No such file or directory
configure: svn revision:
checking for gdal-config... /usr/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.0.4
checking GDAL version >= 1.11.4... yes
checking GDAL version <= 2.5 or >= 3.0... yes
checking GDAL: linking with --libs only... yes
checking GDAL: gdal-config data directory readable... yes
checking GDAL: /usr/share/gdal/stateplane.csv readable... yes
configure: pkg-config proj exists, will use it
configure: PROJ version: 6.3.2
configure: PROJ CPP flags: -DPROJ_H_API
configure: PROJ LIBS: -lproj
checking PROJ header API:... yes
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in
`/home/veroandreo/tmp/Rtmp9DsGuk/R.INSTALL16352f5a74a/rgdal':
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
ERROR: configuration failed for package ?rgdal?
* removing ?/home/veroandreo/R/x86_64-redhat-linux-gnu-library/3.6/rgdal?
Warning in install.packages :
  installation of package ?/home/veroandreo/Downloads/rgdal_1.5-13.tar.gz?
had non-zero exit status



El dom., 28 jun. 2020 a las 14:44, Roger Bivand (<Roger.Bivand at nhh.no>)
escribi?:

            

      
      
      
    

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://stat.ethz.ch/pipermail/r-sig-geo/attachments/20200628/d2e3eca7/attachment.html>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: text/x-log
Size: 8624 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-geo/attachments/20200628/d2e3eca7/attachment.bin>

  
  


  


      

    

    

      
      

        


  

        

      Erwan LE PENNEC
    

    

      
      #
    

  


  

      
Using the new --disable-loadflags in install.packages:
install.packages("rgdal_1.5-13.tar.gz", repos = NULL, type = "source",
configure.args = "--disable-loadflags")
should solve the issue.

Erwan

On Sun, Jun 28, 2020 at 3:42 PM Veronica Andreo <veroandreo at gmail.com>
wrote:

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Ista Zahn
    

    

      
      #
    

  


  

      
I can reproduce this error using the official Fedora 32 docker image:

docker run -it library/fedora:32
dnf install 'dnf-command(builddep)'
dnf builddep R-rgdal
R
install.packages("rgdal")

* installing *source* package ?rgdal? ...
** package ?rgdal? successfully unpacked and MD5 sums checked
** using staged installation
configure: R_HOME: /usr/lib64/R
configure: CC: gcc -m64
configure: CXX: g++ -m64 -std=gnu++11
configure: CXX11 is: g++ -m64, CXX11STD is: -std=gnu++11
configure: CXX is: g++ -m64 -std=gnu++11
configure: C++11 support available
configure: rgdal: 1.5-12
checking for /usr/bin/svnversion... no
configure: svn revision: 1018
checking for gdal-config... /usr/bin/gdal-config
checking gdal-config usability... yes
configure: GDAL: 3.0.4
checking GDAL version >= 1.11.4... yes
checking GDAL version <= 2.5 or >= 3.0... yes
checking GDAL: linking with --libs only... yes
checking GDAL: gdal-config data directory readable... yes
checking GDAL: /usr/share/gdal/stateplane.csv readable... yes
configure: pkg-config proj exists, will use it
configure: PROJ version: 6.3.2
configure: PROJ CPP flags: -DPROJ_H_API
configure: PROJ LIBS: -lproj
checking PROJ header API:... yes
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in
`/tmp/Rtmp2o3TMz/R.INSTALLf5d2a7cbb3e/rgdal':
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
ERROR: configuration failed for package ?rgdal?
* removing ?/usr/lib64/R/library/rgdal?

The downloaded source packages are in
        ?/tmp/RtmpooFgiH/downloaded_packages?
Updating HTML index of packages in '.Library'
Warning messages:
1: In install.packages("rgdal") :
  installation of package ?rgdal? had non-zero exit status
2: In file.create(f.tg) :
  cannot create file '/usr/share/doc/R/html/packages.html', reason 'No
such file or directory'
3: In make.packages.html(.Library) : cannot update HTML package index

            

      
      
      
    

        
I don't have any insight into what happens here, but it is reproducible.

Best,
Ista

        
On Sun, Jun 28, 2020 at 9:42 AM Veronica Andreo <veroandreo at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Sun, 28 Jun 2020, Ista Zahn wrote:

        

            

      
      
      
    

        
The error is in the RPM propagating its LDFLAGS which are  not needed (or 
cause no havoc) in simple tests for C compiler functionality in 
./configure. For the arguably broken R rpm, use either LDFLAGS="" or the 
svn rev. 1020 configure argument --disable-loadflags. The load flags are 
far more than is sensibly needed to check whether the compile train works. 
I have used RH, RHEL and Fedora since the last century, and have always 
installed R from source. Recently, the TexLive packaging system drew in 
(totally unecessarily) a dependency on the R rpm, which I now have to 
avoid using. My rpm:

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

and compiled from source:

$ R CMD config LDFLAGS
-L/usr/local/lib64

Why the rpm LDFLAGS demolish a simple AC_LANG(C++) (guesswork, now line 
504 in configure.ac) is unknown for me, hence the need for the workaround.

I advise strongly against binary packaging of rgdal for Linux, and was not 
aware that any such packaging had been attempted. Changes in GDAL and PROJ 
happen fast, and Fedora/Centos etc. have been really slow to update.

If anyone understands why the R Fedora rpm imposes such vicious LDFLAGS 
and can explain why they are needed and how to run a cross platform 
configure script without having to special-case platforms, I'd be mildly 
interested to know. sf has also been through similar trouble as mentioned 
earlier in this thread.

Roger

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Bennet Fauber
    

    

      
      #
    

  


  

      
Roger,

This seems to be an outcome of a 'security' policy that
RedHat/Fedora/CentOS implemented.  There are some circumstances where
I think that could be justified, but I do not think compiling R is one
of them.

It was reported several times to RedHat's Bugzilla and basically
ignored by RedHat at least as far back as 2015-12-02.  There are
several reports of slightly different versions of the report, but none
of them got acted upon.  Some details and links to other issues marked
as duplicates (but also seemingly closed without any attention or
action) can be found at

    https://bugzilla.redhat.com/show_bug.cgi?id=1287743

The version of R-rgdal that is in the Fedora archive as a binary is
rgdal_1.4-8 and that .srpm will build, however if it is updated to use
rgdal_1.5-12 it fails the same way that it does with the source build.

        
On Sun, Jun 28, 2020 at 1:17 PM Roger Bivand <Roger.Bivand at nhh.no> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
Bennet,

Thanks for the careful analysis.

        
On Sun, 28 Jun 2020, Bennet Fauber wrote:

        

            

      
      
      
    

        
https://bugzilla.redhat.com/show_bug.cgi?id=1343892 includes more 
information. Many traces in search suggest that a missing 
redhat-rpm-config package is to blame, but it is certainly present on my 
test system.

The Redhat policy positions are specified in:

https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/

but do not seem to resolve the conflict between autoconf and 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld.

I'll raise this on the R fedora list.

Roger

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
In thread 
https://stat.ethz.ch/pipermail/r-sig-fedora/2020-June/000653.html, I?aki 
?car explains that, following the introduction of AC_LANG(C++) into 
configure.ac about 11 June, the Fedora R rpm would also need CXXFLAGS set.

Having added : ${CXXFLAGS=`"${RBIN}" CMD config CXXFLAGS`} to 
configure.ac, I can confirm that the work-around flag is not needed, and 
that (once R-forge revision 1021 completes), install.packages("rgdal", 
repos="http://R-Forge.R-project.org") should work on Fedora R rpm 
platforms. Those affected please check and confirm.

Many thanks to Bennet and I?aki!

Roger

        
On Mon, 29 Jun 2020, Roger Bivand wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Bennet Fauber
    

    

      
      #
    

  


  

      
Roger,

I believe the redhat-rpm-config package is actually the culprit that
introduces the problem.  It's missing in the sense that it gets pulled
in when it is not there.  There is something to that effect in the
Change Log for the Fedora R package, I believe, but it's not very
informative other than to say it is happening.

Sorry, I should have been more clear.

-- bennet

        
On Mon, Jun 29, 2020 at 3:57 AM Roger Bivand <Roger.Bivand at nhh.no> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Bennet Fauber
    

    

      
      #
    

  


  

      
Thanks for the update, Roger!  Very glad you got a response so
quickly, and a fix to match.

I would reiterate I?aki's warning to folks.

    ...note that CPPFLAGS are *not* CXXFLAGS; I say this because it's
a common mistake

CPPFLAGS -> C preprocessor and are use to specify include files
CXXFLAGS -> C++ compilation flags

I have hurt myself several times thinking that CPP must be C Plus
Plus, not C Pre Processor.

        
On Mon, Jun 29, 2020 at 8:03 AM Roger Bivand <Roger.Bivand at nhh.no> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Mon, 29 Jun 2020, Bennet Fauber wrote:

        

            

      
      
      
    

        
I hope it worked in your case.

            

      
      
      
    

        
Not the case here, CPP was for the pre-processor and had been around a 
long time to try to union the positions of R, GDAL and PROJ if possible.

Roger