Re: [Rd] compiling R under cygwin

[Duncan Murdoch]

Denham Robert wrote:
> For various reasons, it suits our workplace to have a cygwin version of
> R.  I am pretty sure that cygwin is still not a supported environment
> for R, but we have managed to compile R-2.5.1 under cygwin without too
> many dramas.  Our procedure is described below.  We still have a few
> problems compiling libraries without manually changing files from .so to
> .dll, but it seems ok.
>   
I would expect other subtle problems as well, because Cygwin is not a 
normal Unix.  I don't know whether any of these differences matter to R, 
but some things to look out for are:

 - you can't unlink a file while it is open
 - filenames are not case sensitive
 - file permissions have strange defaults (everything is executable)
 - I think the executable format still needs to be Windows format
 - There's no such thing as a ptty
 - You'll probably need X11 for graphics, and will lose support for 
Windows metafile output (wmf)
>  
> I was wondering whether this information is likely to be useful to
> others, and if we should spend any time looking in to ways in which the
> configure/build/install code could be modified to allow a standard
> install.
>   
What is the advantage of building this?  I don't think we want to 
support platforms just for the sake of supporting more platforms, but if 
there's a real need for it, that would be different.

Duncan Murdoch
>  
> Notes on building R under cygwin:
>  
> export FFLAGS=-O3
> export CFLAGS=-O3
> export CXXFLAGS=-O3
> export OBJCFLAGS=-O3
> export FCFLAGS=-O3
> export LDFLAGS='-lblas -lg2c -lintl'
>  
> export R_OSTYPE=unix
>  
> ./configure --prefix=/opt/freeware/R/R-2.5.1 \
> --with-tcl-config=/usr/lib/tclConfig.sh \
> --with-tk-config=/usr/lib/tkConfig.sh \
> --with-blas=-lblas \
> --with-lapack=-llapack \
> --enable-R-shlib
>  
> comment out Win32 in src/include/config.h and set Unix to 1, change .so
> to .dll. change .so to .dll and in Makeconf.
> in src/extra/xdr/rpc/types.h comment out defn of malloc.
>  
> Change .so to .dll in Makefile's
>  
> edit Makeconf and set R_OSTYPE to unix
>  
> make -j2
>  
> when blas doesn't link, re-run command with -lblas -lg2c on end and
> change output to .dll
>  
> edit Rstrptime.c and change wcstod to atof.
>  
> in modules:
> when X11 and internet falls over add -lintl to link line. add -lg2c and
> -lblas to lapack
>  
> comment out library/base/R/library.R lines 47-51 to avoid arch check
> which seems to go wrong!
>  
> make -j2
> make install
>  
> edit  /opt/freeware/R/R-2.5.1/lib/R/etc/Makeconf and add '-lintl -lg2c
> -lblas' to the end of ALL_LIBS
> so the module building works. Change .so to .dll also
> (can't see how to to this for the build tho...)
>  
>
> Our cygwin info is:
>  sysname  release  version 
>  "CYGWIN_NT-5.1" "1.5.20s(0.155/4/2)"  "20060527 19:21:22" 
>
>
>  
>  
> Robert Denham
> Environmental Statistician
> Remote Sensing Centre
> Telephone 07 3896 9899 
> www.nrw.qld.gov.au  
>  
> Department of Natural Resources & Water
> QScape Building, 80 Meiers Road, Indooroopilly Qld 4068
>
> 
> The information in this email together with any attachments is
> intended only for the person or entity to which it is addressed
> and may contain confidential and/or privileged material.
> Any form of review, disclosure, modification, distribution
> and/or publication of this email message is prohibited, unless
> as a necessary part of Departmental business.
> If you have received this message in error, you are asked to
> inform the sender as quickly as possible and delete this message
> and any copies of this message from your computer and/or your
> computer system network.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] compiling R under cygwin

[Prof Brian Ripley]

Yes,

> What is the advantage of building this?

was my question too.  If you want a Unix-like version of R on PC hardware 
running Windows why not run a Unix-like OS under a virtual machine?

Quite a lot of the details are wrong: using FLIBS, BLAS_LIBS and LIBS as 
intended will solve most of the problems.  I would use --disable-nls 
--disable-mbcs as you don't need them (and in particular you don't benefit 
from MBCS support on Windows unless you are in a CJK locale).

Note that 2.5.1 is released and there is unlikely to be a 2.5.2, so any 
changes would be made only to R-devel.  It there is a convincing case to 
tailor a build for Cygwin there we can probably do so rather easily, but 
the need for ongoing support would be a worry.

(If platforms are not used and in particular not tested in the alpha/beta 
testing phases then the ability to build on them crumbles away.  We seems 
to be down to regular testers on Linux, Windows, MacOS X, Solaris and 
FreeBSD, with some help on AIX after a patch with none.)

On Tue, 21 Aug 2007, Duncan Murdoch wrote:

> Denham Robert wrote:
>> For various reasons,

I think it is only courteous to mention some good reasons if you want to 
take up people's time.

>> it suits our workplace to have a cygwin version of
>> R.  I am pretty sure that cygwin is still not a supported environment
>> for R, but we have managed to compile R-2.5.1 under cygwin without too
>> many dramas.  Our procedure is described below.  We still have a few
>> problems compiling libraries without manually changing files from .so to
>> .dll, but it seems ok.
>>
> I would expect other subtle problems as well, because Cygwin is not a
> normal Unix.  I don't know whether any of these differences matter to R,
> but some things to look out for are:
>
> - you can't unlink a file while it is open
> - filenames are not case sensitive
> - file permissions have strange defaults (everything is executable)
> - I think the executable format still needs to be Windows format
> - There's no such thing as a ptty
> - You'll probably need X11 for graphics, and will lose support for
> Windows metafile output (wmf)
>>
>> I was wondering whether this information is likely to be useful to
>> others, and if we should spend any time looking in to ways in which the
>> configure/build/install code could be modified to allow a standard
>> install.
>>
> What is the advantage of building this?  I don't think we want to
> support platforms just for the sake of supporting more platforms, but if
> there's a real need for it, that would be different.
>
> Duncan Murdoch
>>
>> Notes on building R under cygwin:
>>
>> export FFLAGS=-O3
>> export CFLAGS=-O3
>> export CXXFLAGS=-O3
>> export OBJCFLAGS=-O3
>> export FCFLAGS=-O3
>> export LDFLAGS='-lblas -lg2c -lintl'
>>
>> export R_OSTYPE=unix
>>
>> ./configure --prefix=/opt/freeware/R/R-2.5.1 \
>> --with-tcl-config=/usr/lib/tclConfig.sh \
>> --with-tk-config=/usr/lib/tkConfig.sh \
>> --with-blas=-lblas \
>> --with-lapack=-llapack \
>> --enable-R-shlib
>>
>> comment out Win32 in src/include/config.h and set Unix to 1, change .so
>> to .dll. change .so to .dll and in Makeconf.
>> in src/extra/xdr/rpc/types.h comment out defn of malloc.
>>
>> Change .so to .dll in Makefile's
>>
>> edit Makeconf and set R_OSTYPE to unix
>>
>> make -j2
>>
>> when blas doesn't link, re-run command with -lblas -lg2c on end and
>> change output to .dll
>>
>> edit Rstrptime.c and change wcstod to atof.
>>
>> in modules:
>> when X11 and internet falls over add -lintl to link line. add -lg2c and
>> -lblas to lapack
>>
>> comment out library/base/R/library.R lines 47-51 to avoid arch check
>> which seems to go wrong!
>>
>> make -j2
>> make install
>>
>> edit  /opt/freeware/R/R-2.5.1/lib/R/etc/Makeconf and add '-lintl -lg2c
>> -lblas' to the end of ALL_LIBS
>> so the module building works. Change .so to .dll also
>> (can't see how to to this for the build tho...)
>>
>>
>> Our cygwin info is:
>>  sysname  release  version
>>  "CYGWIN_NT-5.1" "1.5.20s(0.155/4/2)"  "20060527 19:21:22"
>>
>>
>>
>>
>> Robert Denham
>> Environmental Statistician
>> Remote Sensing Centre
>> Telephone 07 3896 9899
>> www.nrw.qld.gov.au 
>>
>> Department of Natural Resources & Water
>> QScape Building, 80 Meiers Road, Indooroopilly Qld 4068
>>
>> 
>> The information in this email together with any attachments is
>> intended only for the person or entity to which it is addressed
>> and may contain confidential and/or privileged material.
>> Any form of review, disclosure, modification, distribution
>> and/or publication of this email message is prohibited, unless
>> as a necessary part of Departmental business.
>> If you have received this message in error, you are asked to
>> inform the sender as quickly as possible and delete this message
>> and any copies of this message from your computer and/or your
>> com

Re: [Rd] compiling R under cygwin

[M. Edward (Ed) Borasky]

Prof Brian Ripley wrote:
> Yes,
> 
>> What is the advantage of building this?
> 
> was my question too.  If you want a Unix-like version of R on PC hardware 
> running Windows why not run a Unix-like OS under a virtual machine?
> 
> Quite a lot of the details are wrong: using FLIBS, BLAS_LIBS and LIBS as 
> intended will solve most of the problems.  I would use --disable-nls 
> --disable-mbcs as you don't need them (and in particular you don't benefit 
> from MBCS support on Windows unless you are in a CJK locale).
> 
> Note that 2.5.1 is released and there is unlikely to be a 2.5.2, so any 
> changes would be made only to R-devel.  It there is a convincing case to 
> tailor a build for Cygwin there we can probably do so rather easily, but 
> the need for ongoing support would be a worry.
> 
> (If platforms are not used and in particular not tested in the alpha/beta 
> testing phases then the ability to build on them crumbles away.  We seems 
> to be down to regular testers on Linux, Windows, MacOS X, Solaris and 
> FreeBSD, with some help on AIX after a patch with none.)

I too have a workplace where Windows is the "official" IT-supported OS,
and in some cases open-source tools do not have a native Windows port,
thus needing Cygwin, or as you suggest, an embedded VMware Linux
workstation. I run Cygwin and a Gentoo Linux VMware guest on my Windows
machine. Having said that:

1. I consider the Windows version of R to have a *superior* user
interface to the Linux version. The only place where it falls down in my
opinion is the semi-difficult nature of building contributed packages
that require C or C++ or Fortran compilation.

2. I know of few other open source communities that prefer a Cygwin
version to a native Windows version if the native version exists. Most
of them go further -- for example, the Ruby Windows people flat-out
deprecate the Cygwin Ruby port, even though it is slightly faster than
the native one and even though some C-language extensions won't build
except on the Cygwin version!

In short, Cygwin is a crutch IMHO, and an embedded Linux VMware guest
isn't much better. I'm hoping to phase Cygwin out by the end of the
year. I think if you need Linux, you should run Linux. That's going to
require some patience and extreme people skills when you deal with your
IT department, but it can be done. But on Windows boxes, you're much
better off using only tools built for and tested on native Windows.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] compiling R under cygwin

[Gabor Grothendieck]

On 8/21/07, M. Edward (Ed) Borasky <[EMAIL PROTECTED]> wrote:
> Prof Brian Ripley wrote:
> > Yes,
> >
> >> What is the advantage of building this?
> >
> > was my question too.  If you want a Unix-like version of R on PC hardware
> > running Windows why not run a Unix-like OS under a virtual machine?
> >
> > Quite a lot of the details are wrong: using FLIBS, BLAS_LIBS and LIBS as
> > intended will solve most of the problems.  I would use --disable-nls
> > --disable-mbcs as you don't need them (and in particular you don't benefit
> > from MBCS support on Windows unless you are in a CJK locale).
> >
> > Note that 2.5.1 is released and there is unlikely to be a 2.5.2, so any
> > changes would be made only to R-devel.  It there is a convincing case to
> > tailor a build for Cygwin there we can probably do so rather easily, but
> > the need for ongoing support would be a worry.
> >
> > (If platforms are not used and in particular not tested in the alpha/beta
> > testing phases then the ability to build on them crumbles away.  We seems
> > to be down to regular testers on Linux, Windows, MacOS X, Solaris and
> > FreeBSD, with some help on AIX after a patch with none.)
>
> I too have a workplace where Windows is the "official" IT-supported OS,
> and in some cases open-source tools do not have a native Windows port,
> thus needing Cygwin, or as you suggest, an embedded VMware Linux
> workstation. I run Cygwin and a Gentoo Linux VMware guest on my Windows
> machine. Having said that:
>
> 1. I consider the Windows version of R to have a *superior* user
> interface to the Linux version. The only place where it falls down in my
> opinion is the semi-difficult nature of building contributed packages
> that require C or C++ or Fortran compilation.
>
> 2. I know of few other open source communities that prefer a Cygwin
> version to a native Windows version if the native version exists. Most
> of them go further -- for example, the Ruby Windows people flat-out
> deprecate the Cygwin Ruby port, even though it is slightly faster than
> the native one and even though some C-language extensions won't build
> except on the Cygwin version!
>
> In short, Cygwin is a crutch IMHO, and an embedded Linux VMware guest
> isn't much better. I'm hoping to phase Cygwin out by the end of the
> year. I think if you need Linux, you should run Linux. That's going to
> require some patience and extreme people skills when you deal with your
> IT department, but it can be done. But on Windows boxes, you're much
> better off using only tools built for and tested on native Windows.

Besides Cygwin and VMware there is also the coLinux kernel which is
a native Linux kernel that runs on Windows.  I have run R with the AndLinux
distro based on Ubuntu/coLinux/Xming on top of Windows with some success.
It has the advantage that it runs much faster than virtual machine solutions
(such as VMware) and it does not require special versions of R -- you can just
use the normal Ubuntu version of R.  AndLinux is being developed (they are
still working on the installer) but its basically usable already and they claim
there are already 30,000 users.

On the downside you have to start it up after starting up Windows and that
takes some time and the installer is not finished so you have to use batch
files to start it.   There may be some other problems associated with its
immaturity as well.  See:
http://www.andlinux.org/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] compiling R under cygwin

[Duncan Murdoch]

On 8/21/2007 10:57 AM, M. Edward (Ed) Borasky wrote:
> Prof Brian Ripley wrote:
>> Yes,
>> 
>>> What is the advantage of building this?
>> 
>> was my question too.  If you want a Unix-like version of R on PC hardware 
>> running Windows why not run a Unix-like OS under a virtual machine?
>> 
>> Quite a lot of the details are wrong: using FLIBS, BLAS_LIBS and LIBS as 
>> intended will solve most of the problems.  I would use --disable-nls 
>> --disable-mbcs as you don't need them (and in particular you don't benefit 
>> from MBCS support on Windows unless you are in a CJK locale).
>> 
>> Note that 2.5.1 is released and there is unlikely to be a 2.5.2, so any 
>> changes would be made only to R-devel.  It there is a convincing case to 
>> tailor a build for Cygwin there we can probably do so rather easily, but 
>> the need for ongoing support would be a worry.
>> 
>> (If platforms are not used and in particular not tested in the alpha/beta 
>> testing phases then the ability to build on them crumbles away.  We seems 
>> to be down to regular testers on Linux, Windows, MacOS X, Solaris and 
>> FreeBSD, with some help on AIX after a patch with none.)
> 
> I too have a workplace where Windows is the "official" IT-supported OS,
> and in some cases open-source tools do not have a native Windows port,
> thus needing Cygwin, or as you suggest, an embedded VMware Linux
> workstation. I run Cygwin and a Gentoo Linux VMware guest on my Windows
> machine. Having said that:
> 
> 1. I consider the Windows version of R to have a *superior* user
> interface to the Linux version. The only place where it falls down in my
> opinion is the semi-difficult nature of building contributed packages
> that require C or C++ or Fortran compilation.

And note that this is getting easier:  we're down to a single "Rtools" 
download and install.
> 
> 2. I know of few other open source communities that prefer a Cygwin
> version to a native Windows version if the native version exists. Most
> of them go further -- for example, the Ruby Windows people flat-out
> deprecate the Cygwin Ruby port, even though it is slightly faster than
> the native one and even though some C-language extensions won't build
> except on the Cygwin version!
> 
> In short, Cygwin is a crutch IMHO, and an embedded Linux VMware guest
> isn't much better. I'm hoping to phase Cygwin out by the end of the
> year. I think if you need Linux, you should run Linux. That's going to
> require some patience and extreme people skills when you deal with your
> IT department, but it can be done. But on Windows boxes, you're much
> better off using only tools built for and tested on native Windows.

I still use Cygwin, because I like the bash shell.  But I don't build 
anything for Cygwin, I build native executables.  (There are other 
versions of bash available on Windows, but I prefer the devil I know.)

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] buglet (?) in de.restore()

[Ben Bolker]

   If one calls data.entry() with a matrix:

A = matrix(0,2,2)
data.entry(A)

 everything works fine except that it triggers a warning:

Warning message:
the condition has length > 1 and only the first element will be used in:
   if (dim(x) == dim(args[[i]])) rn <- dimnames(args[[i]])[[1]] else rn 
<- NULL

This is triggered by the following lines in de.restore() [in 
src/library/utils/R/de.R]:
>   if( dim(x) == dim(args[[i]]) )
> rn <- dimnames(args[[i]])[[1]]
> else rn <- NULL
   It would seem to make sense to replace the condition with

if (nrow(x) == nrow(args[[i]]))

   (de.restore() is only called if an element of the list passed to 
data.entry
has more than one column)

  On a side note, I'm curious why

> > A = matrix(0,2,2)
> > is.vector(A)
> [1] FALSE
> > is(A,"vector")
> [1] TRUE
  ...

--
sessionInfo()
R version 2.5.1 (2007-06-27)
i486-pc-linux-gnu

locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C

attached base packages:
[1] "stats" "graphics"  "grDevices" "utils" "datasets"  "methods" 
[7] "base"

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] available.packages (PR#9841)

[zivan . karaman]

--=_Part_60506_18925213.1187708869863
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thank you very much for your explanation, it woks correctly indeed.




On 8/19/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
> The documented specification is file:///d:/CRAN (as specified by RFC1738)=
,
> so this is working correctly.
>
> The CHANGES file for 2.2.0 says:
>
> o   file:// URLs are now interpreted by download.file(),
> download.packages() and url() in the same way as Mozilla-based
> browsers.  That is, the expected form is
>
> file:///d:/path/to/file
>
> with *three* slashes.
>
> The point is that this is file:// + host + / + path/to/file, and host is
> missing.  That some versions of IE did not follow the standard is part of
> the confusion here.
>
> Note that ?available.packages does say
>
>  If a repository is
>  local, i.e., the URL starts with '"file:"', then the packages are
>  not downloaded but used directly.  (Both '"file:"' and
>  '"file:///"' are allowed as prefixes to a file path, the latter
>  for an absolute file path.)
>
> but 'file:' does not work with drives on Windows.  That seems clearly to
> rule out your usage.
>
>
> On Fri, 10 Aug 2007, [EMAIL PROTECTED] wrote:
>
> > Full_Name: Zivan Karaman
> > Version: 2.5.1
> > OS: Windows XP SP2
> > Submission from: (NULL) (195.6.68.214)
> >
> >
> > I think that I have encountered a bug in the function "
> available.packages" when
> > using a local repository (file://=85) on Windows.
> >
> > Version information:
> > platform   i386-pc-mingw32
> > arch   i386
> > os mingw32
> > system i386, mingw32
> > status
> > major  2
> > minor  5.1
> > year   2007
> > month  06
> > day27
> > svn rev42083
> > language   R
> > version.string R version 2.5.1 (2007-06-27)
> >
> > I have made a copy of the CRAN "/bin/windows/contrib/2.5" directory in
> the
> > "D:/CRAN" folder on my machine.
> >
> > When I issue the command:
> >
> > available.packages(contrib.url("file://D:/CRAN"))
> >
> > I get the follwoing message:
> > Error in gzfile(file, "r") : unable to open connection
> > In addition: Warning message:
> > cannot open compressed file ':/CRAN/bin/windows/contrib/2.5/PACKAGES'
> in:
> > gzfile(file, "r")
> >
> > Looking at the source code, I've spotted the following lines which seem
> to cause
> > trouble:
> >
> >if (.Platform$OS.type =3D=3D "windows") {
> >if (length(grep("[A-Za-z]:", tmpf)))
> >  tmpf <- substring(tmpf, 2)
> >}
> > Deleting them, the function works OK.
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595

--=_Part_60506_18925213.1187708869863
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

T=
hank you very much for your explanation, it woks correctly indeed.

&=
nbsp;
On 8/19/07, =
Prof Brian Ripley [EMAIL PROTECTED]
tats.ox.ac.uk> wrote:
The documented specification is =
file:///d:/CRAN (as specified by RFC1738),so this is working correctly.
The CHANGES file for 2.2.0 says:o&n=
bsp;  file:// URLs are now interpreted by download.file(), &n=
bsp;  download.packages() and url() in th=
e same way as Mozilla-based   &n=
bsp;browsers.  That is, the expected form is
   &=
nbsp;file:///d:/path/to/file  &nb=
sp; with *three* slashes.The point is =
that this is file:// + host + / + path/to/file, and host ismissing.&nbs=
p; That some versions of IE did not follow the standard is part of
the confusion here.Note that ?available.packages does say If a repository is l=
ocal, i.e., the URL starts with '"file:"', then the packa=
ges are not downloaded but used directly. =
 (Both '"file:"' and
 '"file:///"' are allowed as =
prefixes to a file path, the latter for an abso=
lute file path.)but 'file:' does not work with drives on Wi=
ndows.  That seems clearly torule out your usage.
On Fri, 10 Aug 2007, mailto:[EMAIL PROTECTED]"=
>[EMAIL PROTECTED] wrote:> Full_Name: Zivan Karaman> Version: 2.5.1> OS: Windows XP SP2> Submission from: (N=
ULL) (
http://195.6.68.214";>195.6.68.214)>>> I=
 think that I have encountered a bug in the function "available.packag=
es" when> using a local repository (file://=85) on Windows.
>> Version information:> platform&=
nbsp;  i386-pc-mingw32> arch  =
; i386> os &nbs=
p;   m

Re: [Rd] compiling R under cygwin

[Prof Brian Ripley]

On Tue, 21 Aug 2007, Prof Brian Ripley wrote:

> Yes,
>
>> What is the advantage of building this?
>
> was my question too.  If you want a Unix-like version of R on PC hardware
> running Windows why not run a Unix-like OS under a virtual machine?
>
> Quite a lot of the details are wrong: using FLIBS, BLAS_LIBS and LIBS as
> intended will solve most of the problems.  I would use --disable-nls
> --disable-mbcs as you don't need them (and in particular you don't benefit
> from MBCS support on Windows unless you are in a CJK locale).
>
> Note that 2.5.1 is released and there is unlikely to be a 2.5.2, so any
> changes would be made only to R-devel.  It there is a convincing case to
> tailor a build for Cygwin there we can probably do so rather easily, but
> the need for ongoing support would be a worry.

It was very easy: R-devel now builds out of the box on Cygwin.  I didn't 
have to do most of the things mentioned here: almost all the pieces needed 
were already available inside configure and just needed to be switched on. 
The exercise was useful in that it found a couple of long-standing minor 
errors in the build process.  The resulting executable hung on the fifo() 
test (seemingly an oft-reported Cygwin issue), but otherwise passed 'make 
check'.

I still don't see why one would prefer this to Rterm.exe.

> (I
f platforms are not used and in particular not tested in the alpha/beta
> testing phases then the ability to build on them crumbles away.  We seems
> to be down to regular testers on Linux, Windows, MacOS X, Solaris and
> FreeBSD, with some help on AIX after a patch with none.)
>
> On Tue, 21 Aug 2007, Duncan Murdoch wrote:
>
>> Denham Robert wrote:
>>> For various reasons,
>
> I think it is only courteous to mention some good reasons if you want to
> take up people's time.
>
>>> it suits our workplace to have a cygwin version of
>>> R.  I am pretty sure that cygwin is still not a supported environment
>>> for R, but we have managed to compile R-2.5.1 under cygwin without too
>>> many dramas.  Our procedure is described below.  We still have a few
>>> problems compiling libraries without manually changing files from .so to
>>> .dll, but it seems ok.
>>>
>> I would expect other subtle problems as well, because Cygwin is not a
>> normal Unix.  I don't know whether any of these differences matter to R,
>> but some things to look out for are:
>>
>> - you can't unlink a file while it is open
>> - filenames are not case sensitive
>> - file permissions have strange defaults (everything is executable)
>> - I think the executable format still needs to be Windows format
>> - There's no such thing as a ptty
>> - You'll probably need X11 for graphics, and will lose support for
>> Windows metafile output (wmf)
>>>
>>> I was wondering whether this information is likely to be useful to
>>> others, and if we should spend any time looking in to ways in which the
>>> configure/build/install code could be modified to allow a standard
>>> install.
>>>
>> What is the advantage of building this?  I don't think we want to
>> support platforms just for the sake of supporting more platforms, but if
>> there's a real need for it, that would be different.
>>
>> Duncan Murdoch
>>>
>>> Notes on building R under cygwin:
>>>
>>> export FFLAGS=-O3
>>> export CFLAGS=-O3
>>> export CXXFLAGS=-O3
>>> export OBJCFLAGS=-O3
>>> export FCFLAGS=-O3
>>> export LDFLAGS='-lblas -lg2c -lintl'
>>>
>>> export R_OSTYPE=unix
>>>
>>> ./configure --prefix=/opt/freeware/R/R-2.5.1 \
>>> --with-tcl-config=/usr/lib/tclConfig.sh \
>>> --with-tk-config=/usr/lib/tkConfig.sh \
>>> --with-blas=-lblas \
>>> --with-lapack=-llapack \
>>> --enable-R-shlib
>>>
>>> comment out Win32 in src/include/config.h and set Unix to 1, change .so
>>> to .dll. change .so to .dll and in Makeconf.
>>> in src/extra/xdr/rpc/types.h comment out defn of malloc.
>>>
>>> Change .so to .dll in Makefile's
>>>
>>> edit Makeconf and set R_OSTYPE to unix
>>>
>>> make -j2
>>>
>>> when blas doesn't link, re-run command with -lblas -lg2c on end and
>>> change output to .dll
>>>
>>> edit Rstrptime.c and change wcstod to atof.
>>>
>>> in modules:
>>> when X11 and internet falls over add -lintl to link line. add -lg2c and
>>> -lblas to lapack
>>>
>>> comment out library/base/R/library.R lines 47-51 to avoid arch check
>>> which seems to go wrong!
>>>
>>> make -j2
>>> make install
>>>
>>> edit  /opt/freeware/R/R-2.5.1/lib/R/etc/Makeconf and add '-lintl -lg2c
>>> -lblas' to the end of ALL_LIBS
>>> so the module building works. Change .so to .dll also
>>> (can't see how to to this for the build tho...)
>>>
>>>
>>> Our cygwin info is:
>>>  sysname  release  version
>>>  "CYGWIN_NT-5.1" "1.5.20s(0.155/4/2)"  "20060527 19:21:22"
>>>
>>>
>>>
>>>
>>> Robert Denham
>>> Environmental Statistician
>>> Remote Sensing Centre
>>> Telephone 07 3896 9899
>>> www.nrw.qld.gov.au 
>>>
>>> Department of Natural Resources & Water
>>> QScape Build

Re: [Rd] compiling R under cygwin

[M. Edward (Ed) Borasky]

Gabor Grothendieck wrote:

> Besides Cygwin and VMware there is also the coLinux kernel which is
> a native Linux kernel that runs on Windows.  I have run R with the AndLinux
> distro based on Ubuntu/coLinux/Xming on top of Windows with some success.
> It has the advantage that it runs much faster than virtual machine solutions
> (such as VMware) and it does not require special versions of R -- you can just
> use the normal Ubuntu version of R.  AndLinux is being developed (they are
> still working on the installer) but its basically usable already and they 
> claim
> there are already 30,000 users.
> 
> On the downside you have to start it up after starting up Windows and that
> takes some time and the installer is not finished so you have to use batch
> files to start it.   There may be some other problems associated with its
> immaturity as well.  See:
> http://www.andlinux.org/
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
CoLinux is a non-starter in many corporate shops -- it violates lots of
security policies by hacking into the Windows environment. It's also
quite immature. It may be the greatest thing since sliced bread, but if
the corporate police won't let you use it, it's not worth much.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel