R CMD check, NAMESPACE, import: bad error?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

R CMD check, NAMESPACE, import: bad error?

Seth Falcon-2
I'm seeing errors with R CMD check that I don't understand when
checking a package that uses a NAMESPACE file with an import
directive.  The imported package is listed in the DESCRIPTION file in
the Imports field.

DESCRIPTION contains:

   Imports: arules

NAMESPACE contains:

   import(arules)

The package builds without warnings and installs and loads just fine.
But check has this to say:

$ R CMD check DNAhelperseth_1.0.tar.gz
[snip]
* using Version 2.3.0 Under development (unstable) (2006-01-15 r37092)
* checking for file 'DNAhelperseth/DESCRIPTION' ... OK
[snip]
* checking R files for library.dynam ... OK
* checking S3 generic/method consistency ... WARNING
Error: package/namespace load failed for 'DNAhelperseth'
Call sequence:
2: stop(gettextf("package/namespace load failed for '%s'", libraryPkgName(package)),        call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
Execution halted
See section 'Generic functions and methods' of the 'Writing R Extensions'
manual.
* checking replacement functions ... WARNING
Error: package/namespace load failed for 'DNAhelperseth'
Call sequence:
2: stop(gettextf("package/namespace load failed for '%s'", libraryPkgName(package)),        call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
Execution halted
In R, the argument of a replacement function which corresponds to the right
hand side must be named 'value'.
* checking foreign function calls ... WARNING
Error: package/namespace load failed for 'DNAhelperseth'
Call sequence:
2: stop(gettextf("package/namespace load failed for '%s'", libraryPkgName(package)),        call. = FALSE, domain = NA)
1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
Execution halted
See section 'System and foreign language interfaces' of the 'Writing R
Extensions' manual.
* checking Rd files ... OK
* checking for missing documentation entries ... ERROR
Error: package/namespace load failed for 'DNAhelperseth'

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check, NAMESPACE, import: bad error?

Berwin A Turlach
G'day Seth,

>>>>> "SF" == Seth Falcon <[hidden email]> writes:

    SF> I'm seeing errors with R CMD check that I don't understand
    SF> when checking a package that uses a NAMESPACE file with an
    SF> import directive.
I came sometime ago across a similar problem and it took me some time
to figure it out.  In my case it was that a .Fortran() call didn't
have a "package=" argument.  My advise would be to check all .C() and
.Fortran() calls in your package and add the "package=" argument if it
is missing.

I also guess that if you temporarily remove the NAMESPACE file, the
following step in the checking process:

      * checking foreign function calls ... WARNING
      Error: package/namespace load failed for 'DNAhelperseth'
      Call sequence:
      2: stop(gettextf("package/namespace load failed for '%s'", libraryPkgName(package)),        call. = FALSE, domain = NA)
      1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
      Execution halted
      See section 'System and foreign language interfaces' of the 'Writing R
      Extensions' manual.

will tell you which call the culprit is.  

Cheers,

        Berwin

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check, NAMESPACE, import: bad error?

Prof Brian Ripley
We do recommend you try INSTALLing and loading the package before R CMD
check.  The most common problem I have found is that the DSO/DLL cannot be
loaded, and there loading will give a more extensive error message.

On Fri, 20 Jan 2006, Berwin A Turlach wrote:

> G'day Seth,
>
>>>>>> "SF" == Seth Falcon <[hidden email]> writes:
>
>    SF> I'm seeing errors with R CMD check that I don't understand
>    SF> when checking a package that uses a NAMESPACE file with an
>    SF> import directive.
> I came sometime ago across a similar problem and it took me some time
> to figure it out.  In my case it was that a .Fortran() call didn't
> have a "package=" argument.  My advise would be to check all .C() and
> .Fortran() calls in your package and add the "package=" argument if it
> is missing.

(It had better be PACKAGE= !)

> I also guess that if you temporarily remove the NAMESPACE file, the
> following step in the checking process:
>
>      * checking foreign function calls ... WARNING
>      Error: package/namespace load failed for 'DNAhelperseth'
>      Call sequence:
>      2: stop(gettextf("package/namespace load failed for '%s'", libraryPkgName(package)),        call. = FALSE, domain = NA)
>      1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose = FALSE)
>      Execution halted
>      See section 'System and foreign language interfaces' of the 'Writing R
>      Extensions' manual.
>
> will tell you which call the culprit is.
>
> Cheers,
>
>        Berwin
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

--
Brian D. Ripley,                  [hidden email]
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, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check, NAMESPACE, import: bad error?

Seth Falcon-2
On 19 Jan 2006, [hidden email] wrote:

> We do recommend you try INSTALLing and loading the package before R
> CMD check.  The most common problem I have found is that the DSO/DLL
> cannot be loaded, and there loading will give a more extensive error
> message.

Yes, the package INSTALLs and loads just fine.

Actually, one sees the same error message for a package without a
DSO/DLL...

But DSO/DLL loading does seem to be related.  I'm only seeing the
issue when the package that is imported contains a DSO/DLL.

I've created two versions of a very simple 'hello world' package.  The
first imports RUnit and passes check.  The second imports Biobase
and does not pass check.


http://bioconductor.fhcrc.org/developers/examples/

Perhaps someone can see if they see the same thing and/or point out an
error in my package setup.


R.version
               _                                                            
platform       powerpc-apple-darwin8.4.0                                    
arch           powerpc                                                      
os             darwin8.4.0                                                  
system         powerpc, darwin8.4.0                                          
status         Under development (unstable)                                  
major          2                                                            
minor          3.0                                                          
year           2006                                                          
month          01                                                            
day            15                                                            
svn rev        37092                                                        
language       R                                                            
version.string Version 2.3.0 Under development (unstable) (2006-01-15 r37092)

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check, NAMESPACE, import: bad error?

Berwin A Turlach
In reply to this post by Prof Brian Ripley
G'day Brian,

>>>>> "BDR" == Prof Brian Ripley <[hidden email]> writes:

    BDR> We do recommend you try INSTALLing and loading the package
    BDR> before R CMD check.
I have to rely on my memory, but if I remember correctly, installing
and loading the package worked.  It was only when it came to "R CMD
check" that the combination of having a NAMESPACE and no "PACKAGE="
argument in a .Fortran() call made "R CMD check" complain.  (With much
the same complaints that Seth reported).

But now I am utterly confused because I wanted to test if my memory is
correct.  So I went back to the package (called SCSS) with which I
experienced these problems (according to the dates of the files I was
putting that package together around 12 October 2005, which was just
after the release of R 2.2.0 and I believe I was using that version).

After removing the "PACKAGE=" arguments from the .Fortran() calls, the
package installs and loads fine.  But to my utter amazement, "R CMD
check" now works without a problem.  I tried this command with R
2.1.1, R 2.2.0, R 2.2.1 and R 2.3.0 (i.e. R-devel).

What surprised me most, was that all these versions said

* checking foreign function calls ... OK

I thought that this check is supposed to catch missing "PACKAGE="
arguments in .C(), .Fortran() &c calls???

The only explanation I have, is that my Debian linux system was some
time ago upgraded to gcc 4.0.3 and gfortran.  Indeed, running "R CMD
check" with R 2.3.0 produces a 00install.out file in the SCSS.Rcheck
directory that says:

* Installing *source* package 'SCSS' ...
** libs
make[2]: Entering directory `/home/berwin/lang/R/Develop/SCSS/src'
gfortran   -fpic  -g -O2 -c evsp.f -o evsp.o
gfortran   -fpic  -g -O2 -c evsp1d.f -o evsp1d.o
gfortran   -fpic  -g -O2 -c repar.f -o repar.o
gcc -shared -L/usr/local/lib -o SCSS.so evsp.o evsp1d.o repar.o  -lgfortran -lm -lgcc_s

whereas R 2.1.1, R 2.2.0 and R 2.2.1 issue the following lines during
"R CMD check":

* Installing *source* package 'SCSS' ...
** libs
make[2]: Entering directory `/home/berwin/lang/R/Develop/SCSS/src'
g77   -fPIC  -g -O2 -c evsp.f -o evsp.o
g77   -fPIC  -g -O2 -c evsp1d.f -o evsp1d.o
g77   -fPIC  -g -O2 -c repar.f -o repar.o
gcc -shared -L/usr/local/lib -o SCSS.so evsp.o evsp1d.o repar.o  -L/usr/lib/gcc/i486-linux-gnu/3.4.5 -lg2c -lm -lgcc_s

since those versions of R where compiled and installed while I was
using gcc 3.4 on my machine.  

But on my machine I have now:

[bossiaea:Develop]$ file `which gcc`
/usr/bin/gcc: symbolic link to `gcc-4.0'

I redirected the link to point to gcc-3.4, but I still could not
reproduce the problems that I experienced last October (and which Seth
experienced right now).  Perhaps the problem only occurs with a very
specific version of the gcc compiler??

    >> [...]  My advise would be to check all .C() and .Fortran()
    >> calls in your package and add the "package=" argument if it is
    >> missing.
    BDR> (It had better be PACKAGE= !)
Of course, my bad.

Cheers,

        Berwin

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check, NAMESPACE, import: bad error?

Prof Brian Ripley
On Sun, 22 Jan 2006, Berwin A Turlach wrote:

> G'day Brian,
>
>>>>>> "BDR" == Prof Brian Ripley <[hidden email]> writes:
>
>    BDR> We do recommend you try INSTALLing and loading the package
>    BDR> before R CMD check.
> I have to rely on my memory, but if I remember correctly, installing
> and loading the package worked.  It was only when it came to "R CMD
> check" that the combination of having a NAMESPACE and no "PACKAGE="
> argument in a .Fortran() call made "R CMD check" complain.  (With much
> the same complaints that Seth reported).

I perhaps should have said that loading the R_DEFAULT_PACKAGES=NULL is
sometimes also useful.

> But now I am utterly confused because I wanted to test if my memory is
> correct.  So I went back to the package (called SCSS) with which I
> experienced these problems (according to the dates of the files I was
> putting that package together around 12 October 2005, which was just
> after the release of R 2.2.0 and I believe I was using that version).
>
> After removing the "PACKAGE=" arguments from the .Fortran() calls, the
> package installs and loads fine.  But to my utter amazement, "R CMD
> check" now works without a problem.  I tried this command with R
> 2.1.1, R 2.2.0, R 2.2.1 and R 2.3.0 (i.e. R-devel).
>
> What surprised me most, was that all these versions said
>
> * checking foreign function calls ... OK
>
> I thought that this check is supposed to catch missing "PACKAGE="
> arguments in .C(), .Fortran() &c calls???

Not quite: `needed and missing'.  If R is able to work out the
package from the NAMESPACE info, it is not reported.  That changed in
2.2.0:

     o checkFF() used by R CMD check has since R 2.0.0 not reported
  missing PACKAGE arguments when testing installed packages with
  namespaces.  It now

  - treats installed and source packages in the same way.

  - reports missing arguments unless they are in a function in
   the namespace with a useDynLib declaration (as the
   appropriate DLL for such calls can be searched for).

There is a further change in pre-2.3.0.


> The only explanation I have, is that my Debian linux system was some
> time ago upgraded to gcc 4.0.3 and gfortran.  Indeed, running "R CMD
> check" with R 2.3.0 produces a 00install.out file in the SCSS.Rcheck
> directory that says:
>
> * Installing *source* package 'SCSS' ...
> ** libs
> make[2]: Entering directory `/home/berwin/lang/R/Develop/SCSS/src'
> gfortran   -fpic  -g -O2 -c evsp.f -o evsp.o
> gfortran   -fpic  -g -O2 -c evsp1d.f -o evsp1d.o
> gfortran   -fpic  -g -O2 -c repar.f -o repar.o
> gcc -shared -L/usr/local/lib -o SCSS.so evsp.o evsp1d.o repar.o  -lgfortran -lm -lgcc_s
>
> whereas R 2.1.1, R 2.2.0 and R 2.2.1 issue the following lines during
> "R CMD check":
>
> * Installing *source* package 'SCSS' ...
> ** libs
> make[2]: Entering directory `/home/berwin/lang/R/Develop/SCSS/src'
> g77   -fPIC  -g -O2 -c evsp.f -o evsp.o
> g77   -fPIC  -g -O2 -c evsp1d.f -o evsp1d.o
> g77   -fPIC  -g -O2 -c repar.f -o repar.o
> gcc -shared -L/usr/local/lib -o SCSS.so evsp.o evsp1d.o repar.o  -L/usr/lib/gcc/i486-linux-gnu/3.4.5 -lg2c -lm -lgcc_s
>
> since those versions of R where compiled and installed while I was
> using gcc 3.4 on my machine.
>
> But on my machine I have now:
>
> [bossiaea:Develop]$ file `which gcc`
> /usr/bin/gcc: symbolic link to `gcc-4.0'
>
> I redirected the link to point to gcc-3.4, but I still could not
> reproduce the problems that I experienced last October (and which Seth
> experienced right now).  Perhaps the problem only occurs with a very
> specific version of the gcc compiler??
>
>    >> [...]  My advise would be to check all .C() and .Fortran()
>    >> calls in your package and add the "package=" argument if it is
>    >> missing.
>    BDR> (It had better be PACKAGE= !)
> Of course, my bad.
>
> Cheers,
>
>        Berwin
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

--
Brian D. Ripley,                  [hidden email]
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, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel