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 hope this is not too offtopic with the initial subject and the
developmenet mailing list


2013/12/18 Duncan Murdoch <murdoch.duncan@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

	[[alternative HTML version deleted]]

