Skip to content

cannot install rgeos

3 messages · Martin Ivanov, Roger Bivand

Original
Martin Ivanov
# 
Dear Prof. Pebesma,

sp and proj4 install just fine. I am having trouble with rgeos and rgdal.
I try to install rgdal with:

  install.packages(pkgs="rgdal", 
configure.args=c("LDFLAGS=-L/home-link/epaiv01/system/usr/lib64","PKG_CPPFLAGS=-I/home-link/epaiv01/system/usr/include", 
"PKG_LIBS=-L/home-link/epaiv01/system/usr/lib64", 
"--with-gdal-config=/home-link/epaiv01/system/usr/bin/gdal-config", 
"--with-proj-lib=/home-link/epaiv01/system/usr/lib64", 
"--with-proj-include=/home-link/epaiv01/system/usr/include"), type="source")

it seems to compile ok, but at the testing whether the package can be 
loaded it complains:

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared object 
'/lustre/home/zdv/ep/epaiv01/R/x86_64-unknown-linux-gnu-library/2.15/rgdal/libs/rgdal.so':
   /usr/java/default/jre/../lib/amd64/libstdc++.so.6: version 
`GLIBCXX_3.4.14' not found (required by 
/home-link/epaiv01/system/usr/lib64/libgdal.so.1)
Error: loading failed
Execution halted
ERROR: loading failed
* removing 
?/lustre/home/zdv/ep/epaiv01/R/x86_64-unknown-linux-gnu-library/2.15/rgdal?

Is it possible that the compilation within R uses different compiler 
than the one I loaded in the
bash environment with:
module load compiler/gnu/4.5 ?
It seems to me that it is can be the case. How can I tell R to use 
exactly the gnu/4.5 compiler
and not something else?

Best regards,

Martin
On 08/18/2012 05:11 PM, Edzer Pebesma wrote:

  
    

      
      
    

  


  


    

    

      
      

        


  

        

      Roger Bivand
    

    

      
      #
    

  


  

      
On Sat, 18 Aug 2012, Martin Ivanov wrote:

        

            

      
      
      
    

        
Both require C++ libraries, and require that they are the same versions as 
the GEOS and GDAL binaries, as well as the rgeos and rgdal binaries. It 
looks as though C++ isn't deployed across the cluster consistently, and 
isn't the same as on your local machine. Start by getting rgdal and rgeos 
installed and running correctly locally.

An alternative is to try to build static binary packages, by removing the 
gdal and geos shared objects, so that the rgeos and rgdal configure steps 
revert to static - read the rgdal/configure.ac file for some indications. 
You'll need GDAL only static, with PROJ.4 static-linked; the same for 
GEOS. This is what is done for OSX; Windows package binaries are also 
static, but do not use configure.ac. For rgeos, you may need to add 
-lstdc++ manually. This isn't at all easy.

For GEOS, despite our using the C API consistently, the structure of GEOS 
itself requires linkage to the C++ GEOS ABI, and to libstdc++, so without 
static linkage, care is required. With rgdal, we do use the C++ API/ABI, 
but argably should go for a GSoC next year to move it to the C API, which 
is less problematic (hopefully).

I'm also curious that cluster use is important, given that neither of the 
packages is multithreaded nor parallelizable. Are you going to run 
simulations? Won't it be easier to re-jig your workflow to pre-process and 
post-process data on a single machine?

Roger

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Martin Ivanov
    

    

      
      #
    

  


  

      
Dear R users, Dear Prof. Bivand,

I am happy to inform You that I managed to solve the problem with the 
rgeos and rgdal installation on the Linux cluster in one shot. Actually 
the problem came from the lack of the binutils package. I had compiled 
the system geos and gdal packages without usage of binutils, hence those 
linker errors. After I loaded the
binutils by "module load compiler/binutils/2.19.1", compiled geos and 
gdal, the installation of
rgeos and rgdal in R went flawless.

Dear Prof. Bivand, I need the Linux cluster because I am going to do 
interpolation of monthly data
for 50 years. The interpolation of each single month on my desktop 
computer takes about 10 minutes. So one can expect that the whole 
procedure is going to take a bit more than 4 days on it, which is not 
very convenient.
That is why I am going to make use of the Linux cluster. There I have 
more RAM and CPU power available for my calculations and I hope to be 
able to submit each decade as a separate job, so that the 5 decades run 
in parallel.

Thank You very much for Your attention and responsiveness.

Best regards,