Re: [Rd] Rtools -- compiling C dll for 64-bit
On 03/07/2014, 7:53 PM, Dalthorp, Daniel wrote:> I've seen that many people have had trouble using Rtools for a 64-bit > compile of C functions. For some, a quick change in path statement seems to > corrects the problem; for others, apparently not. For me? I've been working > at path statements and install/uninstall/reinstall of all sorts of things > for four hours now with no success. The 32-bit dll loads fine, but I need a > 64-bit version. > > Is there an option to tell the compiler with Rtools to use 64-bit? Or a way > to kill off the 32-bit version on my machine so I don't need to worry about > it? > > Any guidance would be greatly appreciated! Your post is far too vague. Where have you seen all these problems? What are you doing? Of course the tools in Rtools have options to select the architecture, but users normally don't need to set those manually. If you're building R, use "MULTI=64" on the make command. If you're calling compilers directly, use the appropriate command line option or prefix for that compiler. These are all listed in the MkRules file in src/gnuwin32/MkRules.dist in the R sources, or in the help pages for the commands. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] blas test problem
later I tried plain-vanilla, well.. redhats' and derivatives default packages and they all fail: > ## PR#4582 %*% with NAs > stopifnot(is.na(NA %*% 0), is.na(0 %*% NA)) > ## depended on the BLAS in use. > > > ## found from fallback test in slam 0.1-15 > ## most likely indicates an inaedquate BLAS. > x <- matrix(c(1, 0, NA, 1), 2, 2) > y <- matrix(c(1, 0, 0, 2, 1, 0), 3, 2) > (z <- tcrossprod(x, y)) [,1] [,2] [,3] [1,] NA NA0 [2,]210 > stopifnot(identical(z, x %*% t(y))) Error: identical(z, x %*% t(y)) is not TRUE Execution halted I've tried scientificLinux, Centos, Oracle all versions of R => 3.0 these linux distribution provide hardware are AMD various CPU based platform On 30/06/14 10:45, peter dalgaard wrote: It is not clear what you mean: The quoted page lists particular AMD BLAS versions that fail R's regression test. Other builds of R would run the regression test during building and you can run them yourself if you get the source code (for good measure, use the current version, not one from a 2011 web posting, i.e., fetch say https://svn.r-project.org/R/branches/R-3-1-branch/tests/reg-BLAS.R). E.g., for me Peters-iMac:R pd$ ../BUILD/bin/R --vanilla < tests/reg-BLAS.R ... normal output, no errors ... There is some risk that binary builds of R on one machine will fail on another. If this happens, it could be quite serious, so developers would want to know. However "most...seem to fail" is not enough to act upon. What exactly did you do, on which computing platform, and what happened that makes you believe that it had failed? -pd On 27 Jun 2014, at 13:38 , lejeczek wrote: dear developers I myself am not a prog-devel, I found this http://devgurus.amd.com/message/1255852#1255852 Most R compilations/installations I use seem to fail this test, is this a problem and if yes then how serious is it? regards __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools -- compiling C dll for 64-bit
On 04/07/2014 9:47 AM, Dalthorp, Daniel wrote:
Thank-you for the prompt and helpful response. It sounds like all I
need is a very simple fix, but it eludes me.
I am trying to call a custom C function from R to speed a calculation.
I'm on Windows 7 with R 3.0.2 and the latest Rtools. I run R CMD SHLIB
cfunc.c from the DOS command line and a.dll is created. In R,
dyn.load("cfunc.dll") works fine with 32-bit R but fails with 64-bit
("LoadLibrary failure: %1 is not a valid Win32 application", where
"%1" refers to cfunc.dll).
The first part of my PATH reads:
c:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;C:\Program Files\R\R-3.0.2\bin\x64
If you run R CMD SHLIB you should by default get the same architecture
as the version of R that you used. For example, if I have 64 bit R
first on my path I see this:
$ R CMD SHLIB test.c
gcc -m64 -I"F:/R/svn/r-devel/R64/include" -DNDEBUG -O2 -Wall
-std=gnu9
9 -mtune=core2 -c test.c -o test.o
gcc -m64 -shared -s -static-libgcc -o test.dll tmp.def test.o
-LF:/R/svn/r-devel
/R64/bin/x64 -lR
That's a 64 bit build. If I have 32 bit R first, I see this:
$ R CMD SHLIB test.c
gcc -I"F:/R/svn/r-devel/R/include" -DNDEBUG -O3 -Wall
-std=gnu99 -mtu
ne=core2 -c test.c -o test.o
gcc -shared -s -static-libgcc -o test.dll tmp.def test.o
-LF:/R/svn/r-devel/R/bi
n/i386 -lR
That's a 32 bit build. From the look of your PATH, you should have 64
bit R first, but you say you're getting 32 bit DLLs, which doesn't make
any sense. I'll assume you've got a typo in your message somewhere, but
you probably want to check what
R --version
prints to be sure.
Duncan Murdoch
-Dan
On Fri, Jul 4, 2014 at 3:21 AM, Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
On 03/07/2014, 7:53 PM, Dalthorp, Daniel wrote:> I've seen that many
people have had trouble using Rtools for a 64-bit
> compile of C functions. For some, a quick change in path statement
seems to
> corrects the problem; for others, apparently not. For me? I've been
working
> at path statements and install/uninstall/reinstall of all sorts
of things
> for four hours now with no success. The 32-bit dll loads fine, but I
need a
> 64-bit version.
>
> Is there an option to tell the compiler with Rtools to use
64-bit? Or
a way
> to kill off the 32-bit version on my machine so I don't need to
worry
about
> it?
>
> Any guidance would be greatly appreciated!
Your post is far too vague. Where have you seen all these problems?
What are you doing?
Of course the tools in Rtools have options to select the architecture,
but users normally don't need to set those manually. If you're
building
R, use "MULTI=64" on the make command.
If you're calling compilers directly, use the appropriate command line
option or prefix for that compiler. These are all listed in the
MkRules
file in src/gnuwin32/MkRules.dist in the R sources, or in the help
pages
for the commands.
Duncan Murdoch
--
Dan Dalthorp, PhD
Statistician
USGS Forest and Rangeland Ecosystem Science Center
Forest Sciences Lab, Rm 189
3200 SW Jefferson Way
Corvallis, OR 97331
ph: 541-750-0953
ddalth...@usgs.gov
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DESCRIPTION.in file causes R CMD check to fail?
hi. i'm building a package using autotools. to propagate the package
version number from configure.ac to DESCRIPTION, i'm using a
DESCRIPTION.in file. both of these files are "shar"'d below.
i need to distribute the DESCRIPTION.in file, as ./configure will need
it. but, "R CMD check" wants to look at DESCRIPTION, so i've let that
also come into the package tarball.
however, when i run "R CMD check" with DESCRIPTION.in in the tree, it
fails:
bash greg-minshalls-mbp: {3359} R CMD check image2k_0.1.tar.gz
* using log directory ‘/Users/minshall/src/mine/image2k/buildit/image2k.Rcheck’
* using R version 3.0.3 (2014-03-06)
* using platform: x86_64-apple-darwin13.1.0 (64-bit)
* using session charset: UTF-8
Error in if (desc["Priority"] == "base") { :
missing value where TRUE/FALSE needed
Execution halted
(whereas if i remove DESCRIPTION.in and recreate the tar file,
everything is good.)
are there any thoughts on what might be the problem?
cheers, Greg Minshall
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# DESCRIPTION
# DESCRIPTION.in
#
echo x - DESCRIPTION
sed 's/^X//' >DESCRIPTION << 'END-of-DESCRIPTION'
XPackage: image2k
XType: Package
XTitle: interface between pixmap and Imlib2 and/or MagickWand
XVersion: 0.1
XDate: 2014-06-24
XAuthor: Greg Minshall
XMaintainer: Greg Minshall
XDescription: image2k creates pixmaps from any image file that is
X supported by the Imlib2 and/or MagickWand libraries (assuming one or
X both of these libraries are available on your machine). similarly,
X given a pixmap, image2k can write that to an image file using either
X Imlib2 and/or MagickWand. (MagickWand is an optional library from
X ImageMagick.)
XLicense: MIT + file LICENSE
XDepends: pixmap
END-of-DESCRIPTION
echo x - DESCRIPTION.in
sed 's/^X//' >DESCRIPTION.in << 'END-of-DESCRIPTION.in'
XPackage: image2k
XType: Package
XTitle: interface between pixmap and Imlib2 and/or MagickWand
XVersion: @VERSION@
XDate: 2014-06-24
XAuthor: Greg Minshall
XMaintainer: Greg Minshall
XDescription: image2k creates pixmaps from any image file that is
X supported by the Imlib2 and/or MagickWand libraries (assuming one or
X both of these libraries are available on your machine). similarly,
X given a pixmap, image2k can write that to an image file using either
X Imlib2 and/or MagickWand. (MagickWand is an optional library from
X ImageMagick.)
XLicense: MIT + file LICENSE
XDepends: pixmap
END-of-DESCRIPTION.in
exit
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DESCRIPTION.in file causes R CMD check to fail?
On 04/07/2014 3:27 PM, Greg Minshall wrote:
hi. i'm building a package using autotools. to propagate the package
version number from configure.ac to DESCRIPTION, i'm using a
DESCRIPTION.in file. both of these files are "shar"'d below.
i need to distribute the DESCRIPTION.in file, as ./configure will need
it. but, "R CMD check" wants to look at DESCRIPTION, so i've let that
also come into the package tarball.
I don't understand why configure needs access to DESCRIPTION.in. What is
it reading there?
The XML package has both DESCRIPTION and DESCRIPTION.in; it might be
helpful for you to see what it does.
Duncan Murdoch
however, when i run "R CMD check" with DESCRIPTION.in in the tree, it
fails:
bash greg-minshalls-mbp: {3359} R CMD check image2k_0.1.tar.gz
* using log directory ‘/Users/minshall/src/mine/image2k/buildit/image2k.Rcheck’
* using R version 3.0.3 (2014-03-06)
* using platform: x86_64-apple-darwin13.1.0 (64-bit)
* using session charset: UTF-8
Error in if (desc["Priority"] == "base") { :
missing value where TRUE/FALSE needed
Execution halted
(whereas if i remove DESCRIPTION.in and recreate the tar file,
everything is good.)
are there any thoughts on what might be the problem?
cheers, Greg Minshall
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# DESCRIPTION
# DESCRIPTION.in
#
echo x - DESCRIPTION
sed 's/^X//' >DESCRIPTION << 'END-of-DESCRIPTION'
XPackage: image2k
XType: Package
XTitle: interface between pixmap and Imlib2 and/or MagickWand
XVersion: 0.1
XDate: 2014-06-24
XAuthor: Greg Minshall
XMaintainer: Greg Minshall
XDescription: image2k creates pixmaps from any image file that is
X supported by the Imlib2 and/or MagickWand libraries (assuming one or
X both of these libraries are available on your machine). similarly,
X given a pixmap, image2k can write that to an image file using either
X Imlib2 and/or MagickWand. (MagickWand is an optional library from
X ImageMagick.)
XLicense: MIT + file LICENSE
XDepends: pixmap
END-of-DESCRIPTION
echo x - DESCRIPTION.in
sed 's/^X//' >DESCRIPTION.in << 'END-of-DESCRIPTION.in'
XPackage: image2k
XType: Package
XTitle: interface between pixmap and Imlib2 and/or MagickWand
XVersion: @VERSION@
XDate: 2014-06-24
XAuthor: Greg Minshall
XMaintainer: Greg Minshall
XDescription: image2k creates pixmaps from any image file that is
X supported by the Imlib2 and/or MagickWand libraries (assuming one or
X both of these libraries are available on your machine). similarly,
X given a pixmap, image2k can write that to an image file using either
X Imlib2 and/or MagickWand. (MagickWand is an optional library from
X ImageMagick.)
XLicense: MIT + file LICENSE
XDepends: pixmap
END-of-DESCRIPTION.in
exit
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DESCRIPTION.in file causes R CMD check to fail?
hi, Duncan,
thanks for the reply, and the pointer to the XML package.
> I don't understand why configure needs access to DESCRIPTION.in. What
> is it reading there?
actually, ./configure is setting the version number in DESCRIPTION,
using DESCRIPTION.in as a template. in configure.ac, i have:
AC_INIT([image2k],[0.1])
which says that i'm building the "image2k" package, with version 0.1.
my DESCRIPTION.in file has a line
Version: @VERSION@
back in configure.ac, i tell autoconf to do substitutions in
DESCRIPTION.in to create DESCRIPTION (among other files):
AC_CONFIG_FILES([
DESCRIPTION
Makefile
src/Makefile
])
so, ./configure will copy DESCRIPTION.in to DESCRIPTION, but will
substitute its idea of the version. (i'm always a big fan of second
normal form.)
i looked at XML's package. thanks, i'm new to the autotools world, so
it's good to be able to look at other examples, especially when used
with R (at which i'm also not so proficient, ignorance squared).
it *looks* like my problem probably comes from some code in
./src/library/tools/R/check.R
from ./src/library/tools/R/check.R:
## Package sources from the R distribution are special. They
## have a 'DESCRIPTION.in' file (instead of 'DESCRIPTION'),
## with Version and License fields containing '@VERSION@' for
## substitution by configure. Earlier bundles had packages
## containing DESCRIPTIION.in, hence the extra check for
## Makefile.in.
is_base_pkg <- is_rec_pkg <- FALSE
if (file.exists(f <- file.path(pkgdir, "DESCRIPTION.in")) &&
file.exists(file.path(pkgdir, "Makefile.in"))) {
desc <- try(read.dcf(f))
if (inherits(desc, "try-error") || !length(desc)) {
resultLog(Log, "EXISTS but not correct format")
do_exit(1L)
}
desc <- desc[1L, ]
if (desc["Priority"] == "base") {
messageLog(Log, "looks like ", sQuote(pkgname0),
" is a base package")
messageLog(Log, "skipping installation test")
is_base_pkg <- TRUE
pkgname <- desc["Package"] # should be same as pkgname0
}
}
(i'm looking at R-3.1.0.) XML doesn't run into this because although it
has a DESCRIPTION.in, it does *not* have Makefile.in, so the suspect
code isn't run.
it seems like maybe something like the below patch might fix my
problem. (but, it also seems like adding a "Priority: other" should,
and indeed does, fix my problem.)
sorry if this was overly wordy.
cheers, Greg
--- orig-check.R2014-03-29 01:15:03.0 +0200
+++ new-check.R 2014-07-05 08:22:01.0 +0300
@@ -4270,7 +4270,7 @@
do_exit(1L)
}
desc <- desc[1L, ]
-if (desc["Priority"] == "base") {
+if ((!is.na(desc["Priority"]) && desc["Priority"] == "base")) {
messageLog(Log, "looks like ", sQuote(pkgname0),
" is a base package")
messageLog(Log, "skipping installation test")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
