pow__ii
Prof Brian Ripley
Prof Brian Ripley <ripley@stats.ox.ac.uk>
Wed, 20 Jan 1999 18:03:15 +0000 (GMT)
> Date: Wed, 20 Jan 1999 12:04:04 -0500
> From: Paul Gilbert <pgilbert@bank-banque-canada.ca>
> To: Bodo Ahrens <Bodo.Ahrens@univie.ac.at>, R-devel
<R-devel@stat.math.ethz.ch>
> Subject: pow__ii
>
> > R code works but the shared objects built from fortran code do not find
> > the appropriate libs with functions like __pow_ii or __epx at runtime.
>
> I used to have endless trouble with __pow_ii which as I recall could be be
> fixed by the correct incantation of the mix of compiler libraries and
> LD_LIBRARY_PATH. It seemed to be extremely sensitive and never easy to get
> right. The problem is that pow_ii is not used by R itself, and so when your
Wait a minute. With SC4.2 installed on Solaris, __pow_ii is in
/opt/SUNWspro/lib/libF77.so.3, and if you followed the instructions
installing the compilers /opt/SUNWspro/lib/ will be in the library
search path, ahead of the system libraries. And as R does call libF77,
__pow_ii is in a library it has already dlopen-ed, so it should always
be accessible. Try ldd R.binary:
libSM.so.6 => /usr/openwin/lib/libSM.so.6
libICE.so.6 => /usr/openwin/lib/libICE.so.6
libX11.so.4 => /usr/openwin/lib/libX11.so.4
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libz.so => /usr/local/lib/libz.so
libdl.so.1 => /usr/lib/libdl.so.1
libm.so.1 => /opt/SUNWspro/lib/libm.so.1
libF77.so.3 => /opt/SUNWspro/lib/libF77.so.3
libsunmath.so.1 => /opt/SUNWspro/lib/libsunmath.so.1
libc.so.1 => /usr/lib/libc.so.1
libXext.so.0 => /usr/openwin/lib/libXext.so.0
libmp.so.2 => /usr/lib/libmp.so.2
(Solaris 2.6 aka SunOS 5.6).
I have just rebuilt R using the SC4.2 compilers and sent Bodo Ahrens
lots of detailed check information. It works for me on several different
Solaris/compiler combinations.
> fortran code does something like 4**2 (or using variables declared as integer)
> then a call to pow_ii is generated and you need to find the correct library. I
Not on my system: you need n1**n2.
> eventually fixed the problem by changing the fortran code to 4.0D0**2 (or
> 4.0D0**2.0D0 ? and declared variables as double). This generates calls to a
> routine which is used by R itself, and I never had to worry about the
libraries
> again.
>
> This also worked better with Splus, which can also be problematic in this
> regard. I highly recommend this change to anyone distributing fortran code
with
> a package.
Current Solaris versions of S-PLUS even check up LD_LIBRARY_PATH for you.
I have not seen problems with this since about 1995, and have just checked
this out:
toucan% cat test.f
subroutine mypow(n1, n2, n3)
n2 = n1**n3
end
toucan% Splus COMPILE test.f
toucan% nm -g test.o
[Index] Value Size Type Bind Other Shndx Name
[8] | 0| 0|NOTY |GLOB |0 |UNDEF |__pow_ii
[7] | 0| 28|FUNC |GLOB |0 |2 |mypow_
and this dyn.loads into S-PLUS 3.4 without error.
toucan% R SHLIB test.f
ld -G -o test.so test.o -L/usr/local/lib -lblas
[It also works on a machine without libblas installed.]
toucan% nm -g test.so
test.so:
[Index] Value Size Type Bind Other Shndx Name
[21] | 66252| 0|OBJT |GLOB |0 |6 |_DYNAMIC
[23] | 0| 0|OBJT |GLOB |0 |ABS |_PROCEDURE_LINKAGE_TABLE_
[20] | 0| 0|NOTY |GLOB |0 |UNDEF |__pow_ii
[22] | 66332| 0|OBJT |GLOB |0 |7 |_edata
[18] | 66332| 0|OBJT |GLOB |0 |8 |_end
[24] | 716| 0|OBJT |GLOB |0 |5 |_etext
[19] | 688| 28|FUNC |GLOB |0 |5 |mypow_
> dyn.load("./test.so")
> .Fortran("mypow", as.integer(4), integer(1), as.integer(3))
[[1]]
[1] 4
[[2]]
[1] 64
[[3]]
[1] 3
I suspect Paul like me remembers when this was a problem on SunOS4 with static
libraries, but I don't think it is a problem for S-PLUS.
Brian
--
Brian D. Ripley, ripley@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 272860 (secr)
Oxford OX1 3TG, UK Fax: +44 1865 272595
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._