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
2013/12/30 Olivier BARTHELEMY <barthel...@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.dun...@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.dun...@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
>
--
Olivier BARTHELEMY
+33.1.80.97.26.31
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
