[Rd] Symlinks when building R on windows

[Duncan Murdoch]

On 14-01-02 6:09 AM, Olivier BARTHELEMY wrote:
> With some additional debug messages in the code, it would seem that when
> solve.R calls .Internal(La_solve(..)), mod_do_lapack() is called, but
> PRIMVAL(op) should be 100 for La_solve. Instead, it is 0 and thus
> La_qr_cmplx is called

That's very strange.  The PRIMVAL comes from the big R_FunTab table in 
names.c, and it is coded correctly. During initialization it is copied 
into the La_solve
object that you're seeing in the function call.
So it looks as though either the table or that object has somehow become 
corrupted.  Debugging that is a little tricky, but should be doable. 
First, work out whether R_FunTab is corrupted or not.  If it is, then 
set a hardware breakpoint to see when it happened.  If not, then you 
have to wait until the La_solve primitive is created, then set a 
hardware breakpoint on it.  Good luck.

Duncan Murdoch


>
> 2013/12/30 Olivier BARTHELEMY <barthelemy at geovariances.com>
>
>> I tried relaunching the build for x64 this time, in a new folder, and
>> still get the same problem, so it mustn't be something that didn't get
>> deleted.
>> According to my first diagnostics with messages in the source, it's
>> strange. In solve.R, i can see that it will call ".Internal(La_solve(a, b,
>> tol))". But i never see a message i added right at the start of La_solve()
>> of Lapack.c. I also diagnosed that the "'a' must be a complex matrix" error
>> comes from La_qr_cmplx(). It's as if .Internal() called the wrong function
>> of Lapack.c. I'll try to look more tomorrow, but am not sure how to debug
>> .Internal()..
>>
>>
>> 2013/12/30 Duncan Murdoch <murdoch.duncan at gmail.com>
>>
>>> On 13-12-30 4:47 AM, Olivier BARTHELEMY wrote:
>>>
>>>> Ok, i used the procedure in the manual. I think i am almost at the end of
>>>> the build process. I am stuck however at the build of grDevices module.
>>>> While byte-compiling it, i get the following error :
>>>> Error in solve.default(rgb) : 'a' must be a complex matrix
>>>> The line of that syntax errror can be found back in make.rgb of
>>>> src/library/grDevices/R/convertColor.R
>>>> I doubt this file has a syntax error. The only possible cause i can think
>>>> of is if the previous rbind that creates rgb returns NULL, but i can't
>>>> find
>>>> what would cause that.
>>>> Any hints on where i could look for the problem?
>>>>
>>>
>>> I've never seen that error, so can't offer much help.  Did you delete
>>> everything from your previous unsuccessful build attempts?
>>>
>>> Do note that it is not a syntax error, it's an evaluation error.  It
>>> would likely have happened during the construction of the colorspaces list,
>>> which calls make.rgb later in that same file.  You could insert print() or
>>> message() statements to localize the error, but it's not an error that
>>> should have happened in a valid build.
>>>
>>> Duncan Murdoch
>>>
>>>
>>>
>>>> I hope this is not too offtopic with the initial subject and the
>>>> developmenet mailing list
>>>>
>>>>
>>>> 2013/12/18 Duncan Murdoch <murdoch.duncan at gmail.com>
>>>>
>>>>   On 13-12-18 5:24 AM, Olivier BARTHELEMY wrote:
>>>>>
>>>>>   I think this is more suited for the devel mailing list than the help
>>>>>> one.
>>>>>>
>>>>>> I'm trying to build R on windows, With Rtools installed, and
>>>>>> configure/make
>>>>>> in R-3.0.2 sources folder from a cygwin console.
>>>>>>
>>>>>>
>>>>> This doesn't sound like a good idea.  The Rtools are set up for native
>>>>> Windows builds.  If you run configure yourself, you'll be targeting a
>>>>> Cygwin build -- but that's something we don't support.
>>>>>
>>>>> What you should do is follow the instructions for native Windows builds
>>>>> that are given in chapter 3 of the Installation and Administration
>>>>> manual.
>>>>>    In particular, *do not* run configure.
>>>>>
>>>>> If you do choose to create a Cygwin build, please make sure it passes
>>>>> the
>>>>> tests before you use it.  I haven't seen one that does.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>>>
>>>>>
>>>>>    I am stuck at the moment, because the build process tries create
>>>>> symlinks,
>>>>>
>>>>>> and gcc build fails because the opened files containe the metadata of
>>>>>> the
>>>>>> not working symlink, and not the linked file.
>>>>>> The first problematic files is src/extra/xz/alone_decoder.c, pointing
>>>>>> to
>>>>>> common/alone_decoder.c, but i guess the following buildt files would
>>>>>> have
>>>>>> the same problem.
>>>>>> My configure didn't even detect the symlink cmd off cygwin while
>>>>>> performing
>>>>>> the tests, and i even launched configure with --disable-symlinks, but
>>>>>> their
>>>>>> creationis attmpted anyways.
>>>>>> Is there any quick way to workaround that? And since it's .c or.h
>>>>>> files we
>>>>>> are symlinking here, couldn't we simply do 'eponym' C or h files that
>>>>>> do a
>>>>>> C #include to the relative path, which would be more portable than
>>>>>> symlinks?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Olivier BARTHELEMY
>> +33.1.80.97.26.31
>>
>
>
>