Rcmd SHLIB error

On Sun, Dec 19, 2010 at 9:07 AM, Duncan Murdoch
<murdoch.duncan at gmail.com>  wrote:

On 19/12/2010 7:01 AM, Gabor Grothendieck wrote:

On Sun, Dec 19, 2010 at 6:39 AM, Duncan Murdoch
<murdoch.duncan at gmail.com>    wrote:

On 19/12/2010 6:06 AM, Gabor Grothendieck wrote:

On Sat, Dec 18, 2010 at 8:23 PM, Dominick Samperi<djsamperi at gmail.com>
  wrote:

On Sat, Dec 18, 2010 at 5:24 PM, Gabor Grothendieck
<ggrothendieck at gmail.com>      wrote:

I am getting this error message when I try to run Rcmd SHLIB myprog.c.
  There appears to be a missing / between etc and i386 in the path.  I
am on Windows Vista and am using R version 2.12.1 Patched (2010-12-16
r53864) and just downloaded Rtools 2.12 today.   Is this a bug in R?
How can I resolve this?

This is due to new behavior in CYGWIN (the basis for Rtools). The
new CYGWIN does not like non-standard paths that have C: in them.
Some CYGWIN programs will not work when fed file names using
this syntax, but normally this is just a warning. The warning can be
suppressed by using the Control Panel to set CYGWIN=nodosfilewarning.
Another solution is to use POSIX equivalent paths of the form
/cydrive/c/PROG..., but this would require more extensive changes
to build scripts, etc.

There is another change that causes Rtools tar to choke in some
circumstances under Windows because it tries to change ownership
of the files extracted when it shouldn't. These error
messags can be suppressed by using the Control Panel to set
TAR_OPTIONS=--no-same-owner.

I am still wondering what to do about this?  I have created a
directory called C:\PROGRA~1\R\R-212~1.X\etci386 and have copied
Makeconf into it.  That lets me use Rcmd SHLIB but its quite an ugly
workaround and there must be some better resolution than that.  Also I
am wondering if this same problem will crop up elsewhere.

You could try running within Cygwin, as I do, on the theory that what
works
for me might work for you.  I do use the "nodosfilewarning" setting as
Dominick mentioned.

However, I will say that my Windows build system is much less reliable
than
it used to be.  I don't know the cause:  I started 64 bit builds on
Windows
7 at around the same time as I upgraded Cygwin, so it could be any of
those
causes.  I'm tending to believe it's a Cygwin problem or a Cygwin-Win7
incompatibility, but I haven't had time to work out a reliable system.
  (Symptoms I see are that very few overnight builds are succeeding;
almost
all the ones you see on CRAN/bin/windows/base have required manual
restarts
after they've failed partway through.)

Unfortunately, I am not going to have the time to diagnose or fix this in
the next couple of months.  If you have spare time, you might want to try
older versions of the Rtools (perhaps mixing new compilers with old
Rtools/bin and Cygwin DLLs).

Duncan Murdoch

Where in the sources is the C:\PROGRA~1\R\R-212~1.X\etci386 [sic] path
set?

I don't know.  Possibilities include src/gnuwin32/fixed/Makefile line 31
(where a bad R_ARCH would do it).  Do you have R_ARCH set as an environment
variable or on the command line when you call make? I think the latter would
override the setting in MkRules, I'm not sure about the former.

Thanks.  I now have a better workaround.  The batch file shown below
works but if /i386 is changed to i386 then it fails because it looks
for a directory called etci386:

   setlocal
   set R_ARCH=/i386
   "C:\Program Files\R\R-2.12.x\bin\i386\Rcmd.exe" SHLIB myprog.c
   endlocal

1. It seems the / is missing between etc and $(R_ARCH) on lines 31 and
38 of that Makefile (or if etci386 is intended then the actual
structure of R that is installed is wrong).

2. page 8 of R-admin manual says that there is an --arch argument with
values i386, 32, x64, 64 but neither "Rcmd --help" nor "Rcmd SHLIB
--help" document an argument for setting the architecture.

3. on page 12 of the R-ext manual it refers to
R_HOME/etcR_ARCH/Makeconf so the documentation and how the Makefile
works seems inconsistent with the actual R directory structure which
is etc/i386 and not etci386.