I built it several times with a variety of flags and compilers.
Here's what was used for the gcc3 build:
/opt/csw/gcc3/bin/gcc -std=gnu99 -G -L/opt/sfw/lib -L/opt/csw/lib
-L/opt/local/lib -L/usr/apps/cdat32/NetCDF/lib -o foreign.so avl.o
dbfopen.o file-handle.o format.o init.o minitab.o pfm-read.o
Rdbfread.o Rdbfwrite.o R_systat.o SASxport.o sfm-read.o spss.o
stataread.o -L/admin/users/jwlong/R/src/R-2.8.1/lib -lR
On my system, the main R shared library shows a dependency on libavl,
and hence so does foreign.so and the R binary:
% ldd R
libR.so => /opt/local/lib/R/lib/libR.so
libRblas.so => /opt/local/lib/R/lib/libRblas.so
libc.so.1 => /lib/libc.so.1
libg2c.so.0 => /opt/csw/lib/libg2c.so.0
libm.so.2 => /lib/libm.so.2
libintl.so.8 => /opt/csw/lib/libintl.so.8
libreadline.so.4 => /opt/csw/lib/libreadline.so.4
libncurses.so.5 => /opt/csw/lib/libncurses.so.5
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 =>/lib/libsocket.so.1
libdl.so.1 =>/lib/libdl.so.1
libiconv.so.2 => /opt/csw/lib/libiconv.so.2
libm.so.1 => /lib/libm.so.1
libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1
libsec.so.1 => /lib/libsec.so.1
libmp.so.2 =>/lib/libmp.so.2
libmd.so.1 =>/lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libavl.so.1 => /lib/libavl.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
Looking through these various shared libs, it looks like
/lib/libsec.so.1 is the one that pulls in libavl. And libintl is what
pulls in libsec. And R itself pulls in libintl.
Jeff
==
At 11:20 PM + 3/6/09, Prof Brian Ripley wrote:
Can you show us the output you get from building foreign, and
explain how it comes to be linked against libavl? I get (SunStudio
12)
cc -xc99 -G -L/opt/csw/lib -o foreign.so R_systat.o Rdbfread.o
Rdbfwrite.o SASxport.o avl.o dbfopen.o file-handle.o format.o init.o
minitab.o pfm-read.o sfm-read.o spss.o stataread.o
and ldd library/foreign/libs/foreign.so reveals no dependencies (and
the R binary is not linked against libavl either).
I can see that linking against libavl could cause problems, but have
no idea why that might be happening.
On Fri, 6 Mar 2009, Jeff Long wrote:
Like a couple of other posters in the past year, I was seeing R
2.8.1 segfault in the foreign package on my Solaris 10 Intel system:
> library(foreign)
*** caught segfault ***
address fe1d5c70, cause 'invalid permissions'
Traceback:
1: .C("spss_init", PACKAGE = "foreign")
2: fun(...)
This happened whether I built with gcc3, gcc4, or SunStudio 12.
Using pstack I found that the code was crashing in avl_create().
Using truss I found that identically named functions in the Solaris
/lib/libavl.so.1 library were being used instead of the AVL
functions provided in avl.c in the foreign package. To verify, I
replaced all of the "avl_" and "AVL_" patterns in
foreign/src/*.[ch] with "ravl_" and "RAVL_" respectively. Once I
made this change, loading the foreign package caused no further
problems.
An alternative workaround was a hack involving symlinks and
LD_LIBRARY_PATH, but that was not satisfactory. Since the foreign
avl functions are incompatible with the ones provided by the
standard Sun library, this approach has other potential gotchas.
FYI.
Jeff
__
R-devel@r-project.org mailing list
https:// stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http:// www. stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
