[Rd] Rcmd SHLIB error

[Duncan Murdoch]

On 19/12/2010 3:09 PM, Gabor Grothendieck wrote:
> On Sun, Dec 19, 2010 at 10:31 AM, Duncan Murdoch
> <murdoch.duncan at gmail.com>  wrote:
>> On 19/12/2010 10:04 AM, Gabor Grothendieck wrote:
>>>
>>> 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).
>>
>> No, the slash is supposed to be part of R_ARCH, which isn't a variable you
>> should need to set.  It is set in MkRules, as I mentioned above.
>>
>>> 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.
>>
>> That argument appears to work for me.  If you want to submit a patch so
>> --help displays it, I'll take a look.
>>
>>> 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.
>>>
>>
>> See 1.
>>
>
> For now I have addressed this in my publicly available Windows
> batchfiles so that when using them R_ARCH can have or not have a / and
> they will still work.
>

That's definitely the wrong approach.  You'll just confuse people about 
the meaning of R_ARCH if you misuse it that way.

Duncan Murdoch