Skip to content

forcing the use of the c++ linker with c++ and fortran sources

4 messages · Steve Guerrero, Duncan Murdoch, Brian Ripley

Original
Steve Guerrero
# 
I'm trying to build a package which has both gfortran and c++ code.

In my installation of R, the R CMD INSTALL process compiles each c++ and 
gfortran code with the correct compiler, but performs the link step with 
"gfortran" and this creates undefined symbols at load time.

How does one override/force the use of a different command in the link 
step?  Is there an appropriate entry in Makevars that will do the trick?

Thanks,
-sg
Duncan Murdoch
#
On 09/01/2009 4:04 PM, Steve Guerrero wrote:
You should offer more details:  what platform are you working on? What 
version of R? Do you have a simple example that people could try, and 
see the errors?

Duncan Murdoch
Steve Guerrero
# 
Sorry I was a little stingy with details.

I'm building a very simple package on linux with R 2.7.1
no configure script or homemade makefiles.
my src directory has two files:
src/foo.cpp
src/bar.f90

I run "R CMD install myproject " which runs fine, no errors, and 
produces a shared library

i.e.:
gfortran -fdefault-real-8 -ffixed-form -fpic -g -O2 -c  GLMnet.f90 -o 
bar.f90
g++ (all the right flags) -fpic  -g -O2 -c foo.cpp -o foo.o

and the link step:

gfortran -shared -L/usr/local/lib64 -o myproject.so baro foo.o 
-L/apps/R/R-2.7.1/x86_64-linux-2.6/lib64/R/lib -lR


The build goes fine, the problem is when I load the library I get this 
error:
library(myproject)
Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared library myproject.so
   undefined symbol: __gxx_personality_v0
Error: package/namespace load failed for 'myproject'

If I manually run the link step with g++ instead of gfortran, the 
library loads fine, everything works.

I need to tell the R build process to not link with gfortran but to link 
with g++ in my mixed c++ and fortran scenario.  A little digging into 
the R SHLIB build script suggests that I probably can't override it 
without cooking up my Makefiles

Here's an excerpt from the R SHLIB script:

makeargs="SHLIB=\"${shlib}\""
if ${with_f9x}; then
     makeargs="SHLIB_LDFLAGS='\$(SHLIB_FCLDFLAGS)' ${makeargs}"
     makeargs="SHLIB_LD='\$(SHLIB_FCLD)' ${makeargs}"
else
   if ${with_cxx}; then
     makeargs="SHLIB_LDFLAGS='\$(SHLIB_CXXLDFLAGS)' ${makeargs}"
     makeargs="SHLIB_LD='\$(SHLIB_CXXLD)' ${makeargs}"
   fi
   if ${with_f77}; then
     if ${with_objc}; then
       shlib_libadd="\$(OBJC_LIBS) ${shlib_libadd}"
     fi
     if test -z "${shlib_libadd}"; then
       makeargs="${makeargs} SHLIB_LIBADD='\$(FLIBS)'"
     else
       makeargs="${makeargs} SHLIB_LIBADD='\$(FLIBS) ${shlib_libadd}'"
     fi
   else
     if ${with_objc}; then
       makeargs="${makeargs} SHLIB_LIBADD='\$(OBJC_LIBS)'"
     fi
   fi
fi

This logic seems to suggest that if there are fortran95 sources, the LD 
command will be SHLIB_FCLD...with no apparent way to override it.

Am I mistaken?

Thanks,
-sg
Duncan Murdoch wrote:
Brian Ripley
# 
You are correct: there is no reason to assume that the F90 compiler 
can link C++ nor that the C++ compiler can link F90, and in general 
they cannot.  Quite a few systems have a different vendor's F9x 
compiler (including say g95 vs gcc3 and SunPro F9x vs gcc4).

Even in a pure gcc4 scenario, each of F9x and C++ needs additional 
libaries and R does not know what they are (it only does for F77). 
So if linking by g++ works for you, it is fortuitous and not portable.

I suspect adding -lstdc++ will work for you, which you can do via 
PKG_LIBS in a Makevars file.

Bottom line: you are asking to do something known not to be portable. 
You can use a Makefile to have complete freedom, but please don't 
distribute such a package without a configure script to check out all 
the assumptions.
On Fri, 9 Jan 2009, Steve Guerrero wrote:

            

      
      
      
    

        
Still no details of compilers etc.