I looked at all the build steps and didn't find anything suspicious. The
makefile has a lot of extra stuff but this is what essentially builds my
app. I must mention that the crash occurs only if I'm building on R-3.0
. All works well if I build with R-2.15
gcc -shared-libgcc -Wl,-E -Wl,-dn -Wl,--hash-size=100000 -Wl,--stats
-Wl,--demangle -Wl,-Map,udx-R.map udx-RID.o
/scratch_a/release/vbuild/Linux64/UDxFence/udx-R.o
/scratch_a/release/vbuild/Linux64/UDxFence/RInterface.o -Wl,-dn
-lprotobuf-lite -Wl,-dy
-L/scratch_a/release/vbuild/third-party/install/lib64/R/lib -lR
-Wl,-rpath,/scratch_a/release/vbuild/third-party/install/lib64/R/lib
-L/scratch_a/release/vbuild/third-party/install/lib64/R/lib -lRblas
-L/scratch_a/release/vbuild/third-party/install/lib64/R/lib -lRlapack
-L/scratch_a/release/vbuild/third-party/install/lib64/R/library/Rcpp/lib
-lRcpp
-Wl,-rpath,/scratch_a/release/vbuild/third-party/install/lib64/R/library/Rcpp/lib
-L/scratch_a/release/vbuild/third-party/install/lib64/R/library/RInside/lib
-lRInside
-Wl,-rpath,/scratch_a/release/vbuild/third-party/install/lib64/R/library/RInside/lib
-L/scratch_a/release/vbuild/Linux64/pgbuild/src/port
-L/scratch_a/release/vbuild/udx/../third-party/install/spread/lib
-L/scratch_a/release/vbuild/udx/../third-party/install/lib -lpgport_srv
-lz -lbz2 -Wl,-dy -lncurses -Wl,-dn -lcurl -lcrypt -lnsl -lxerces-c
-lnetsnmp -lsicui18n -lsicuuc -lsicudata -lutil -lldap_r -lgssapi_krb5
-lkrb5 -lkrb5support -lk5crypto -lpcre -lresolv -llber -lssl -lcrypto
-lcom_err -lspread -llzo2 -lboost_serialization-gcc-mt
-lboost_thread-gcc-mt -lprotobuf-lite -ljson -lm -lstdc++ -Wl,-dy -lrt
-lc -ldl -lpthread -o udx-R
On 06/19/2013 11:55 AM, Dirk Eddelbuettel wrote:
On 19 June 2013 at 10:52, Pratibha Rana wrote:
| Hi,
|
| I have an application that installs and uses R-3.0. If a machine has an
| installation of R-2.15 in some other location then RInside fails to
| initialize. If I remove R-2.15 installation then my a[pplication works
| fine. Here is the backtrace of the crash.
|
| (gdb) bt
| #0 0x00002abbdf606285 in raise () from /lib64/libc.so.6
| #1 0x00002abbdf607d30 in abort () from /lib64/libc.so.6
| #2 0x0000000000630964 in __gnu_cxx::__verbose_terminate_handler() ()
| #3 0x000000000062eb56 in __cxxabiv1::__terminate(void (*)()) ()
| #4 0x000000000062eb83 in std::terminate() ()
| #5 0x000000000062ec7a in __cxa_throw ()
| #6 0x00002abbdecf1a32 in Rcpp::Environment::find(std::basic_string<char,
| std::char_traits<char>, std::allocator<char> > const&) const ()
| from /opt/vertica/R/library/Rcpp/lib/libRcpp.so
| #7 0x00002abbdef63b40 in RInside::autoloads() () from
| /opt/vertica/R/library/RInside/lib/libRInside.so
| #8 0x00002abbdef6503f in RInside::initialize(int, char const* const*,
| bool) () from /opt/vertica/R/library/RInside/lib/libRInside.so
| #9 0x00002abbdef65350 in RInside::RInside() () from
| /opt/vertica/R/library/RInside/lib/libRInside.so
| #10 0x0000000000493264 in main (argc=5, argv=0x7fffafa67638) at
| /scratch_a/release/vbuild/UDxFence/Udx-R.cpp:398
I think that that may be your local issue. Consider setting LD_LIBRARY_PATH
etc pp. There are not that many steps in the build proces; look at all of
them individually and check.
For what it is worth, I my box I keep two R versions, "release" and "devel"
but completely hide the latter -- and call it via a shell script wrapper.
These days, people also use virtual machine with good success.
Dirk
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
