Skip to content

Problem with compiling shared C/C++ library for loading into R (Linux)

3 messages · Samsiddhi Bhattacharjee, torpedo fisken

#
Dear all,

I am using the .Call interface to call c++ code from R. For that, I am
trying to create a dynamic library (mylib.so)
using "R CMD SHLIB" by linking my own c++ code and an external c++
library (blitz++).

The makefile works fine on my Mac, produces mylib.so and I am able to
call .Call() from R,  but on a linux
server (I think Debian),  I got the following error:

----------
/usr/bin/ld: /somepath/blitz/lib/libblitz.a(globals.o):
relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
/somepath/blitz/lib/libblitz.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
----------

I tried recompiling the blitz++ library with the -fPIC flag, and then
linking using -fPIC, it went thorugh without error
producing a "mylib.so" file.  But when I tried "dyn.load(mylib.so)"
from R, I got the error:

----------
Error in dyn.load("mylib.so") :
 unable to load shared library '/somepath/mylib.so':
 /somepath/mylib.so: undefined symbol: _ZSt4cerr
---------

I will really appreciate any help or advice on this problem.

--Samsiddhi Bhattacharjee
#
I think you're not linking it together when you call R CMD SHLIB, use
something like

R CMD SHLIB mylib.c yourlib1.o yourlib2.o

Otherwise mail again with your Makefile, or all the commands you are using

good luck

2009/1/11 Samsiddhi Bhattacharjee <samsiddhi.bhattacharjee at gmail.com>:
2 days later
#
Thanks. I figured out the problem finally. The first error I
mentioned was solved by compiling
the external library blitz++ using the configure option --with-pic (or
compiler flag -fPIC). It has something to do with position indepent
code and global variables, which I frankly don't understand. Maybe
somebody can explain...

      The second one (undefined symbol: _ZSt4cerr) was because cerr is
a c++ object, and I was doing
"R CMD SHLIB" on the compiled object files, so it was linkiing using
gcc. Changing the linker to g++ (using
cpp source code during linking) works...or as suggested in a previous
post using -lstdc++ with gcc also works.

--Samsiddhi Bhattacharjee
On Sun, Jan 11, 2009 at 7:58 AM, torpedo fisken <torpedofisken at gmail.com> wrote: