An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20131218/51448518/attachment.pl>
Symlinks when building R on windows
5 messages · Olivier BARTHELEMY, Duncan Murdoch
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?
11 days later
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20131230/c3f4d29b/attachment.pl>
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?
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20131230/d470c914/attachment.pl>