R devel - Dec 2006 - dyn.load and function calls without 'PACKAGE' argument

I'm writing a package that interfaces to the FAME database, via a
library of compiled C routines accessible through a Linux .so file.  My
.onLoad() function loads the .so like this:

dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)

and after that I also load my own fame.so via

library.dynam("fame", package = "fame")

The code in fame.so uses functions found in libjchli.so, making the
'local = F' argument in dyn.load() necessary.  But since Fame symbols
are found in libjchli.so, which is NOT part of my package, I can't, for
example, do this:

.C("cfmfin", status = integer(1), PACKAGE = "fame")

since the PACKAGE argument tells R to look only in fame.so for symbols.
Instead, I have to do it without specifying 'PACKAGE', i.e., 

.C("cfmfin", status = integer(1))

This works, but 'R CMD check' complains: 

"Foreign function calls without 'PACKAGE' argument:"

followed by a list of the functions called from libjchli.so.

Is there a way to make R CMD check happy here?

Jeff

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



jhallman at frb.gov wrote:
> I'm writing a package that interfaces to the FAME database, via a
> library of compiled C routines accessible through a Linux .so file.  My
> .onLoad() function loads the .so like this:
> 
> dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
> 
> and after that I also load my own fame.so via
> 
> library.dynam("fame", package = "fame")
> 
> The code in fame.so uses functions found in libjchli.so, making the
> 'local = F' argument in dyn.load() necessary. 
Well, that is one approach.
A more  regular and in most senses "better" approach is to
have your fame.so link against libjchli.so when creating
the fame.so DLL/SO.  Then you don't have to pollute the
global symbol table for the process with libjchli.so
and you can use the PACKAGE argument.

That said, the PACKAGE argument is not necessary if you use
a NAMESPACE file for the package.
Load the fame.so with useDynLib() in the NAMESPACE file
and not library.dynam()

And if you explicitly list the routines you want to use
in the useDynLib() call, you can refer to them as
  .Call(foo, ...)

with no quotes, no PACKAGE and you will be able to handle
multiple versions and provide aliases for the routine names.

> But since Fame symbols
> are found in libjchli.so, which is NOT part of my package, I can't, for
> example, do this:
> 
> .C("cfmfin", status = integer(1), PACKAGE = "fame")
> 
> since the PACKAGE argument tells R to look only in fame.so for symbols.
> Instead, I have to do it without specifying 'PACKAGE', i.e., 
> 
> .C("cfmfin", status = integer(1))
> 
> This works, but 'R CMD check' complains: 
> 
> "Foreign function calls without 'PACKAGE' argument:"
> 
> followed by a list of the functions called from libjchli.so.
> 
> Is there a way to make R CMD check happy here?
> 
> Jeff
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
- --
Duncan Temple Lang                    duncan at wald.ucdavis.edu
Department of Statistics              work:  (530) 752-4782
4210 Mathematical Sciences Building   fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis,
CA 95616,
USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFeZ3E9p/Jzwa2QP4RAoJ5AJsFZAFVuvmoEWhKFWxmncbHTLtpgwCfT84w
eN2RaXPav1/8erL08urKxT0=NksI
-----END PGP SIGNATURE-----

Jeff

You might look at the package padi (and also dsepadi) in the dseplus 
bundle in the devel area of CRAN. This provides an R to Fame link, and I 
have tried to do it in a generic way that can potentially interface to 
other time series data bases. It also handles endian issues, if your 
servers do not have the same architecture as the clients. Padi does not 
link the Fame stuff directly into R. Instead, it links a client side rpc 
program that talks to a server side that is linked to the Fame hli. This 
means the client is independent of the server side database, which has 
some advantages. Compiling is handled by a Makefile in the src directory 
and the location of run time code is handled by environment variables. 
It is a bit more complicated than this, because of the server and client 
modes. You may actually want something simpler, but the packages builds 
without errors (at least the client mode part of it). I have left it in 
the devel area mainly because the documentation is incomplete.

The package is very stable. I have been using it for fifteen years 
(first on Splus and now in R). It has a few shortcomings, but they are 
not things I need much. There are lots of improvements I could suggest.

Paul Gilbert

jhallman at frb.gov wrote:
> I'm writing a package that interfaces to the FAME database, via a
> library of compiled C routines accessible through a Linux .so file.  My
> .onLoad() function loads the .so like this:
> 
> dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
> 
> and after that I also load my own fame.so via
> 
> library.dynam("fame", package = "fame")
> 
> The code in fame.so uses functions found in libjchli.so, making the
> 'local = F' argument in dyn.load() necessary.  But since Fame
symbols
> are found in libjchli.so, which is NOT part of my package, I can't, for
> example, do this:
> 
> .C("cfmfin", status = integer(1), PACKAGE = "fame")
> 
> since the PACKAGE argument tells R to look only in fame.so for symbols.
> Instead, I have to do it without specifying 'PACKAGE', i.e., 
> 
> .C("cfmfin", status = integer(1))
> 
> This works, but 'R CMD check' complains: 
> 
> "Foreign function calls without 'PACKAGE' argument:"
> 
> followed by a list of the functions called from libjchli.so.
> 
> Is there a way to make R CMD check happy here?
> 
> Jeff
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
===================================================================================
La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential inform...{{dropped}}