Re: [Rd] Rmpi_0.5-4 and OpenMPI questions
Hi Dirk,
Thank for pointing out additional flags needed in order to compile Rmpi
correctly. Those flags can be added in configure.ac once openmpi dir is
detected. BTW -DMPI2 flag was missed in your Rmpi since the detection of
openmpi was not good. It should be
if test -d ${MPI_ROOT}/lib/openmpi; then
echo "Found openmpi dir in ${MPI_ROOT}/lib"
MPI_DEPS="-DMPI2"
fi
I tried to run Rmpi under snow and got the same error messenger. But after
checking makeMPIcluster, I found that n=3 was a wrong argument. After
makeMPIcluster finds that count is missing,
count=mpi.comm.size(0)-1 is used. If you start R alone, this will return
count=0 since there is only one member (master). I do not know why snow
did not use count=mpi.universe.size()-1 to find total nodes available.
Anyway after using
cl=makeMPIcluster(count=3),
I was able to run parApply function.
I tried
R -> library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
Also
mpirun -host hostfile -np 1 R --no-save
library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
Hao
PS: hostfile contains all nodes info so in R mpi.universe.size() returns
right number and will spawn to remote nodes.
Rmp under Debian 3.1 and openmpi 1.2.4 seems OK. I did find some missing
lib under Debian 4.0.
Dirk Eddelbuettel wrote:
>
> Many thanks to Dr Yu for updating Rmpi for R 2.6.0, and for starting to
> make
> the changes to support Open MPI.
>
> I have just built the updated Debian package of Rmpi (i.e. r-cran-rmpi)
> under
> R 2.6.0 but I cannot convince myself yet whether it works or not. Simple
> tests work. E.g. on my Debian testing box, with Rmpi installed directly
> using Open Mpi 1.2.3-2 (from Debian) and using 'r' from littler:
>
> [EMAIL PROTECTED]:~> orterun -np 3 r -e 'library(Rmpi);
> print(mpi.comm.rank(0))'
> [1] 0
> [1] 1
> [1] 2
> [EMAIL PROTECTED]:~>
>
> but I basically cannot get anything more complicated to work yet. R /
> Rmpi
> just seem to hang, in particular snow and and getMPIcluster() just sit
> there:
>
>> cl <- makeSOCKcluster(c("localhost", "localhost"))
>> stopCluster(cl)
>> library(Rmpi)
>> cl <- makeMPIcluster(n=3)
> Error in makeMPIcluster(n = 3) : no nodes available.
>>
>
> I may be overlooking something simple here, in particular the launching of
> apps appears to be different for Open MPI than it was with LAM/MPI (or
> maybe
> I am just confused because I also look at LLNL's slurm for use with Open
> MPI ?)
>
> Has anybody gotten Open MPI and Rmpi to work on simple demos? Similarly,
> is
> anybody using snow with Rmpi and Open MPI yet?
>
> Also, the Open MPI FAQ is pretty clear on their preference for using mpicc
> for compiling/linking to keep control of the compiler and linker options
> and
> switches. Note that e.g. on my Debian system
>
> [EMAIL PROTECTED]:~> mpicc --showme:link
> -pthread -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl
> -lutil -lm -ldl
>
> whereas Rmpi built with just the default from R CMD:
>
> gcc-4.2 -std=gnu99 -shared -o Rmpi.so RegQuery.o Rmpi.o conversion.o
> internal.o -L/usr/lib -lmpi -lpthread -fPIC -L/usr/lib/R/lib -lR
>
> Don't we need libopen-rte and libopen-pal as the MPI FAQ suggests?
>
> Many thanks, Dirk
>
> --
> Three out of two people have difficulties with fractions.
>
--
Department of Statistics & Actuarial Sciences
Fax Phone#:(519)-661-3813
The University of Western Ontario
Office Phone#:(519)-661-3622
London, Ontario N6A 5B7
http://www.stats.uwo.ca/faculty/yu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rmpi_0.5-4 and OpenMPI questions
On 4 October 2007 at 01:11, Hao Yu wrote:
| Hi Dirk,
|
| Thank for pointing out additional flags needed in order to compile Rmpi
| correctly. Those flags can be added in configure.ac once openmpi dir is
| detected. BTW -DMPI2 flag was missed in your Rmpi since the detection of
| openmpi was not good. It should be
|
| if test -d ${MPI_ROOT}/lib/openmpi; then
| echo "Found openmpi dir in ${MPI_ROOT}/lib"
| MPI_DEPS="-DMPI2"
| fi
|
I don't follow. From my build log:
* Installing *source* package 'Rmpi' ...
[...]
checking for gcc option to accept ISO C89... none needed
I am here /usr
Try to find mpi.h ...
Found in /usr/include
Try to find libmpi or libmpich ...
Found libmpi in /usr/lib
Found openmpi dir in /usr/lib <-- found openmpi
[...]
** libs
make[1]: Entering directory `/tmp/buildd/rmpi-0.5-4/src'
gcc-4.2 -std=gnu99 -I/usr/share/R/include -I/usr/share/R/include
-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -I/usr/include -DMPI2 -fPIC
-fpic -g -O2 -c RegQuery.c -o RegQuery.o
[...]
so -DMPI2 is used.
Because I build this in a chroot / pbuilder envinronment, neither LAM nor
MPICH2 are installed and Open MPI is detected.
| I tried to run Rmpi under snow and got the same error messenger. But after
| checking makeMPIcluster, I found that n=3 was a wrong argument. After
| makeMPIcluster finds that count is missing,
Yes, my bad. But it also hangs with argument count=3 (which I had tried, but
my mail was wrong.)
| count=mpi.comm.size(0)-1 is used. If you start R alone, this will return
| count=0 since there is only one member (master). I do not know why snow
| did not use count=mpi.universe.size()-1 to find total nodes available.
How would it know total nodes ? See below re hostfile.
| Anyway after using
| cl=makeMPIcluster(count=3),
| I was able to run parApply function.
|
| I tried
| R -> library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
|
| Also
| mpirun -host hostfile -np 1 R --no-save
| library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
|
| Hao
|
| PS: hostfile contains all nodes info so in R mpi.universe.size() returns
| right number and will spawn to remote nodes.
So we depend on a correct hostfile ? As I understand the Open MPI this is
deprecated:
# This is the default hostfile for Open MPI. Notice that it does not
# contain any hosts (not even localhost). This file should only
# contain hosts if a system administrator wants users to always have
# the same set of default hosts, and is not using a batch scheduler
# (such as SLURM, PBS, etc.).
I am _very_ interested in running Open MPI and Rmpi under slurm (which we
added to Debian as source package slurm-llnl) so it would be nice if this
could rewritten to not require a hostfile as this seems to be how upstream is
going.
| Rmp under Debian 3.1 and openmpi 1.2.4 seems OK. I did find some missing
| lib under Debian 4.0.
Can you be more specifi? I'd be glad to help.
Thanks!
Dirk
|
|
| Dirk Eddelbuettel wrote:
| >
| > Many thanks to Dr Yu for updating Rmpi for R 2.6.0, and for starting to
| > make
| > the changes to support Open MPI.
| >
| > I have just built the updated Debian package of Rmpi (i.e. r-cran-rmpi)
| > under
| > R 2.6.0 but I cannot convince myself yet whether it works or not. Simple
| > tests work. E.g. on my Debian testing box, with Rmpi installed directly
| > using Open Mpi 1.2.3-2 (from Debian) and using 'r' from littler:
| >
| > [EMAIL PROTECTED]:~> orterun -np 3 r -e 'library(Rmpi);
print(mpi.comm.rank(0))'
| > [1] 0
| > [1] 1
| > [1] 2
| > [EMAIL PROTECTED]:~>
| >
| > but I basically cannot get anything more complicated to work yet. R /
| > Rmpi
| > just seem to hang, in particular snow and and getMPIcluster() just sit
| > there:
| >
| >> cl <- makeSOCKcluster(c("localhost", "localhost"))
| >> stopCluster(cl)
| >> library(Rmpi)
| >> cl <- makeMPIcluster(n=3)
| > Error in makeMPIcluster(n = 3) : no nodes available.
| >>
| >
| > I may be overlooking something simple here, in particular the launching of
| > apps appears to be different for Open MPI than it was with LAM/MPI (or
| > maybe
| > I am just confused because I also look at LLNL's slurm for use with Open
| > MPI ?)
| >
| > Has anybody gotten Open MPI and Rmpi to work on simple demos? Similarly,
| > is
| > anybody using snow with Rmpi and Open MPI yet?
| >
| > Also, the Open MPI FAQ is pretty clear on their preference for using mpicc
| > for compiling/linking to keep control of the compiler and linker options
| > and
| > switches. Note that e.g. on my Debian system
| >
| > [EMAIL PROTECTED]:~> mpicc --showme:link
| > -pthread -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl
| > -lutil -lm -ldl
| >
| > whereas Rmpi built with just the default from R CMD:
| >
| > gcc-4.2 -std=gnu99 -shared -o Rmpi.so RegQuery.o Rmpi.o conversion.o
| > internal.o -L/usr/lib -lmpi -lpthread -fPIC -L/u
Re: [Rd] Rmpi_0.5-4 and OpenMPI questions
On Thu, 4 Oct 2007, Dirk Eddelbuettel wrote:
>
> On 4 October 2007 at 01:11, Hao Yu wrote:
> | Hi Dirk,
> |
> | Thank for pointing out additional flags needed in order to compile Rmpi
> | correctly. Those flags can be added in configure.ac once openmpi dir is
> | detected. BTW -DMPI2 flag was missed in your Rmpi since the detection of
> | openmpi was not good. It should be
> |
> | if test -d ${MPI_ROOT}/lib/openmpi; then
> | echo "Found openmpi dir in ${MPI_ROOT}/lib"
> | MPI_DEPS="-DMPI2"
> | fi
> |
>
> I don't follow. From my build log:
>
> * Installing *source* package 'Rmpi' ...
> [...]
> checking for gcc option to accept ISO C89... none needed
> I am here /usr
> Try to find mpi.h ...
> Found in /usr/include
> Try to find libmpi or libmpich ...
> Found libmpi in /usr/lib
> Found openmpi dir in /usr/lib <-- found openmpi
> [...]
> ** libs
> make[1]: Entering directory `/tmp/buildd/rmpi-0.5-4/src'
> gcc-4.2 -std=gnu99 -I/usr/share/R/include -I/usr/share/R/include
> -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -I/usr/include -DMPI2 -fPIC
> -fpic -g -O2 -c RegQuery.c -o RegQuery.o
> [...]
>
> so -DMPI2 is used.
>
> Because I build this in a chroot / pbuilder envinronment, neither LAM nor
> MPICH2 are installed and Open MPI is detected.
>
> | I tried to run Rmpi under snow and got the same error messenger. But after
> | checking makeMPIcluster, I found that n=3 was a wrong argument. After
> | makeMPIcluster finds that count is missing,
>
> Yes, my bad. But it also hangs with argument count=3 (which I had tried, but
> my mail was wrong.)
Any chance the snow workers are picking up another version of Rmpi, eg
a LAM one? Might happen if you have R_SNOW_LIB set and a Rmpi
installed there. Otherwise starting with outfile=something may help.
Let me know what you find out -- I'd like to make the snow
configuration process more bullet-proof.
>
> | count=mpi.comm.size(0)-1 is used. If you start R alone, this will return
> | count=0 since there is only one member (master). I do not know why snow
> | did not use count=mpi.universe.size()-1 to find total nodes available.
>
> How would it know total nodes ? See below re hostfile.
>
> | Anyway after using
> | cl=makeMPIcluster(count=3),
> | I was able to run parApply function.
> |
> | I tried
> | R -> library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
> |
> | Also
> | mpirun -host hostfile -np 1 R --no-save
> | library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
> |
> | Hao
> |
> | PS: hostfile contains all nodes info so in R mpi.universe.size() returns
> | right number and will spawn to remote nodes.
>
> So we depend on a correct hostfile ? As I understand the Open MPI this is
> deprecated:
>
> # This is the default hostfile for Open MPI. Notice that it does not
> # contain any hosts (not even localhost). This file should only
> # contain hosts if a system administrator wants users to always have
> # the same set of default hosts, and is not using a batch scheduler
> # (such as SLURM, PBS, etc.).
>
> I am _very_ interested in running Open MPI and Rmpi under slurm (which we
> added to Debian as source package slurm-llnl) so it would be nice if this
> could rewritten to not require a hostfile as this seems to be how upstream is
> going.
To work better with batch scheduling environments where spawning might
be techncally or politically problematic I have been trying to improve
the RMPISNOW script that can be used with LAM as
mpirun -np 3 RMPISNOW
and then either
cl <- makeCluster() # no argument
or
cl <- makeCluster(2) # mpi rank - 1 (or less I believe)
(the default type for makeCluster becomes MPI in this case). This
seems to work reasonably well in LAM and I think I can get it to work
similarly in OpenMPI -- will try in the next day or so. Both LAM and
OpenMPI provide environment variables so shell scripts can determine
the mpirank, which is useful for getting --slave and output redirect
to the workers. I haven't figured out anything analogous for
MPIC/MPICH2 yet.
Best,
luke
>
> | Rmp under Debian 3.1 and openmpi 1.2.4 seems OK. I did find some missing
> | lib under Debian 4.0.
>
> Can you be more specifi? I'd be glad to help.
>
> Thanks!
>
> Dirk
>
>
> |
> |
> | Dirk Eddelbuettel wrote:
> | >
> | > Many thanks to Dr Yu for updating Rmpi for R 2.6.0, and for starting to
> | > make
> | > the changes to support Open MPI.
> | >
> | > I have just built the updated Debian package of Rmpi (i.e. r-cran-rmpi)
> | > under
> | > R 2.6.0 but I cannot convince myself yet whether it works or not. Simple
> | > tests work. E.g. on my Debian testing box, with Rmpi installed directly
> | > using Open Mpi 1.2.3-2 (from Debian) and using 'r' from littler:
> | >
> | > [EMAIL PROTECTED]:~> orterun -np 3 r -e 'library(Rmpi);
> print(mpi.comm.rank(0))'
> | > [1] 0
> | > [1] 1
> | > [1] 2
> | > [EM
Re: [Rd] Rmpi_0.5-4 and OpenMPI questions
On 4 October 2007 at 06:37, Luke Tierney wrote:
| > Yes, my bad. But it also hangs with argument count=3 (which I had tried, but
| > my mail was wrong.)
|
| Any chance the snow workers are picking up another version of Rmpi, eg
| a LAM one? Might happen if you have R_SNOW_LIB set and a Rmpi
| installed there. Otherwise starting with outfile=something may help.
| Let me know what you find out -- I'd like to make the snow
| configuration process more bullet-proof.
I generally don;t have any environment variables, so not sure. I'll try to
see what I can find.
| > | count=mpi.comm.size(0)-1 is used. If you start R alone, this will return
| > | count=0 since there is only one member (master). I do not know why snow
| > | did not use count=mpi.universe.size()-1 to find total nodes available.
| >
| > How would it know total nodes ? See below re hostfile.
| >
| > | Anyway after using
| > | cl=makeMPIcluster(count=3),
| > | I was able to run parApply function.
| > |
| > | I tried
| > | R -> library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
| > |
| > | Also
| > | mpirun -host hostfile -np 1 R --no-save
| > | library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
| > |
| > | Hao
| > |
| > | PS: hostfile contains all nodes info so in R mpi.universe.size() returns
| > | right number and will spawn to remote nodes.
| >
| > So we depend on a correct hostfile ? As I understand the Open MPI this is
| > deprecated:
| >
| > # This is the default hostfile for Open MPI. Notice that it does not
| > # contain any hosts (not even localhost). This file should only
| > # contain hosts if a system administrator wants users to always have
| > # the same set of default hosts, and is not using a batch scheduler
| > # (such as SLURM, PBS, etc.).
| >
| > I am _very_ interested in running Open MPI and Rmpi under slurm (which we
| > added to Debian as source package slurm-llnl) so it would be nice if this
| > could rewritten to not require a hostfile as this seems to be how upstream
is
| > going.
|
| To work better with batch scheduling environments where spawning might
| be techncally or politically problematic I have been trying to improve
| the RMPISNOW script that can be used with LAM as
|
| mpirun -np 3 RMPISNOW
|
| and then either
|
| cl <- makeCluster() # no argument
|
| or
|
| cl <- makeCluster(2) # mpi rank - 1 (or less I believe)
|
| (the default type for makeCluster becomes MPI in this case). This
| seems to work reasonably well in LAM and I think I can get it to work
| similarly in OpenMPI -- will try in the next day or so. Both LAM and
| OpenMPI provide environment variables so shell scripts can determine
| the mpirank, which is useful for getting --slave and output redirect
| to the workers. I haven't figured out anything analogous for
| MPIC/MPICH2 yet.
Yes, out of a run I also realized that I can't just ask Rmpi to work without
a hostfile -- the info must come from somewhere.
That said, it still fails with a minimal slurm example using the srun. Ie
[EMAIL PROTECTED]:~> cat /tmp/rmpi.r
#!/usr/bin/env r
library(Rmpi)
library(snow)
cl <- makeMPIcluster(count=1)
print("Hello\n")
does not make it through makeMPIcluster either and just hangs if I do:
[EMAIL PROTECTED]:~> srun -N 1 /tmp/rmpi.r
Dirk
--
Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rmpi_0.5-4 and OpenMPI questions
On Thu, 4 Oct 2007, Hao Yu wrote:
Hi Dirk,
Thank for pointing out additional flags needed in order to compile Rmpi
correctly. Those flags can be added in configure.ac once openmpi dir is
detected. BTW -DMPI2 flag was missed in your Rmpi since the detection of
openmpi was not good. It should be
if test -d ${MPI_ROOT}/lib/openmpi; then
echo "Found openmpi dir in ${MPI_ROOT}/lib"
MPI_DEPS="-DMPI2"
fi
I tried to run Rmpi under snow and got the same error messenger. But after
checking makeMPIcluster, I found that n=3 was a wrong argument. After
makeMPIcluster finds that count is missing,
count=mpi.comm.size(0)-1 is used. If you start R alone, this will return
count=0 since there is only one member (master). I do not know why snow
did not use count=mpi.universe.size()-1 to find total nodes available.
The bit of code you are looking at, for handling calls with no count
argument, is for the case where workers have been started by mpirun
with the RMPISNOW script rather than spawing. Using
mpi.universe.size() to guess a reasonable default choice for the
spawning case might be useful -- will look into that.
I have OpenMPI installed on Fedora 7 x84_64. Rmpi 0.5-4 configure
fails for me -- it does not find mpi.h. I can get Rmpi to build if I
manually set these in Makevars:
PKG_CFLAGS = $(ARCHCFLAGS) -I/usr/include/openmpi
PKG_LIBS = -L/usr/lib64/openmpi -L/lib -lmpi -lpthread -fPIC $(ARCHLIB)
When I try to use R -> library(Rmpi) -> library(snow) cl <- makeMPIcluster(2)
or mpirun -np3 R -> library(Rmpi) -> ... I get
Signal:11 info.si_errno:0(Success) si_code:1(SEGV_MAPERR)
Failing at addr:0x1d26ab7
[0] func:/usr/lib64/openmpi/libopal.so.0 [0x2fee3263]
[1] func:/lib64/libc.so.6 [0x367f030630]
[2] func:/usr/lib64/openmpi/libmpi.so.0(ompi_fortran_string_f2c+0x8c)
[0x2f813bcc]
[3] func:/usr/lib64/openmpi/libmpi.so.0(mpi_comm_spawn_f+0x75)
[0x2f816405]
...
*** End of error message ***
Segmentation fault
[EMAIL PROTECTED] ~%
But mpirun -np 3 RMPISNOW does seem to work, more or less. A modified
version of RMPISNOW, hopefully attached, does a better job of getting
sensible arguments to the workers and master, but the master R still
thinks it is non-interactive. I have not figured out a work-around
for that yet -- suggestions welcome.
Best,
luke
Anyway after using
cl=makeMPIcluster(count=3),
I was able to run parApply function.
I tried
R -> library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
Also
mpirun -host hostfile -np 1 R --no-save
library(Rmpi) -> library(snow) -> c1=makeMPIcluster(3)
Hao
PS: hostfile contains all nodes info so in R mpi.universe.size() returns
right number and will spawn to remote nodes.
Rmp under Debian 3.1 and openmpi 1.2.4 seems OK. I did find some missing
lib under Debian 4.0.
Dirk Eddelbuettel wrote:
Many thanks to Dr Yu for updating Rmpi for R 2.6.0, and for starting to
make
the changes to support Open MPI.
I have just built the updated Debian package of Rmpi (i.e. r-cran-rmpi)
under
R 2.6.0 but I cannot convince myself yet whether it works or not. Simple
tests work. E.g. on my Debian testing box, with Rmpi installed directly
using Open Mpi 1.2.3-2 (from Debian) and using 'r' from littler:
[EMAIL PROTECTED]:~> orterun -np 3 r -e 'library(Rmpi); print(mpi.comm.rank(0))'
[1] 0
[1] 1
[1] 2
[EMAIL PROTECTED]:~>
but I basically cannot get anything more complicated to work yet. R /
Rmpi
just seem to hang, in particular snow and and getMPIcluster() just sit
there:
cl <- makeSOCKcluster(c("localhost", "localhost"))
stopCluster(cl)
library(Rmpi)
cl <- makeMPIcluster(n=3)
Error in makeMPIcluster(n = 3) : no nodes available.
I may be overlooking something simple here, in particular the launching of
apps appears to be different for Open MPI than it was with LAM/MPI (or
maybe
I am just confused because I also look at LLNL's slurm for use with Open
MPI ?)
Has anybody gotten Open MPI and Rmpi to work on simple demos? Similarly,
is
anybody using snow with Rmpi and Open MPI yet?
Also, the Open MPI FAQ is pretty clear on their preference for using mpicc
for compiling/linking to keep control of the compiler and linker options
and
switches. Note that e.g. on my Debian system
[EMAIL PROTECTED]:~> mpicc --showme:link
-pthread -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl
-lutil -lm -ldl
whereas Rmpi built with just the default from R CMD:
gcc-4.2 -std=gnu99 -shared -o Rmpi.so RegQuery.o Rmpi.o conversion.o
internal.o -L/usr/lib -lmpi -lpthread -fPIC -L/usr/lib/R/lib -lR
Don't we need libopen-rte and libopen-pal as the MPI FAQ suggests?
Many thanks, Dirk
--
Three out of two people have difficulties with fractions.
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFa
[Rd] bnlearn package compilation failure on MacOSX
Hi all. I've recently uploaded a package (bnlearn) to CRAN. It builds fine on both Linux (32 and 64 bit) and Windows, but fails on MacOSX ix86 because of C90 vs C99 issues: http://www.r-project.org/nosvn/R.check/r-patched-macosx-ix86/bnlearn-00install.html Since I've no MacOSX machine at hand, I would like to ask you: why is C99 not the default for gcc on MacOSX ix86? Is it safe to force gcc to use C99 with either -std=c99 o -std=gnu99? Thanks in advance. -- Marco Scutari Linux Registered User #341807 http://counter.li.org powered by : Debian Sid GNU/Linux (SGI-XFS) Kernel 2.6.21.3 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bnlearn package compilation failure on MacOSX
You've got more serious problems than that: you cannot assume gcc. For example on the SunPro compiler I got cc -I/home/ripley/R/R-devel-SunPro/include -I/home/ripley/R/R-devel-SunPro/inclu de -I/usr/local/include-Kpic -xO5 -xc99 -xlibmil -nofstore -c mutual.infor mation.c -o mutual.information.o "mutual.information.c", line 34: member can not have variably modified type: n "mutual.information.c", line 35: member can not have variably modified type: m "mutual.information.c", line 41: cannot dereference non-pointer type "mutual.information.c", line 52: cannot dereference non-pointer type "mutual.information.c", line 52: cannot dereference non-pointer type "mutual.information.c", line 53: cannot dereference non-pointer type "mutual.information.c", line 53: cannot dereference non-pointer type "mutual.information.c", line 54: cannot dereference non-pointer type "mutual.information.c", line 54: cannot dereference non-pointer type "mutual.information.c", line 60: warning: improper pointer/integer combination: arg #5 "mutual.information.c", line 62: cannot recover from previous errors Note that is in C99 mode, and under Linux. On Thu, 4 Oct 2007, Marco Scutari wrote: > > Hi all. > > I've recently uploaded a package (bnlearn) to CRAN. It builds fine > on both Linux (32 and 64 bit) and Windows, but fails on MacOSX ix86 > because of C90 vs C99 issues: > > http://www.r-project.org/nosvn/R.check/r-patched-macosx-ix86/bnlearn-00install.html > > Since I've no MacOSX machine at hand, I would like to ask you: > why is C99 not the default for gcc on MacOSX ix86? Is it safe to > force gcc to use C99 with either -std=c99 o -std=gnu99? > > Thanks in advance. > > > -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building package with R 2.6.0 on Windows/Cygwin gives error with tar
My setup: Windows XP, R-2.6.0, Cygwin (not the Rtools version) When I tried to build a package, I was given this message: tar: c\:/X/Rpkgs/Drydown_1.41.tar: Cannot open: Input/Output error Even manually typing the following caused the same error: tar chf 'c:/X/Rpkgs/Drydown_1.41.tar' Drydown I looked at the 2.5.1 and 2.6.0 build scripts. After restoring this section to the 2.6.0 build script: ## workaround for paths in Cygwin tar $filepath =~ s+^([A-Za-z]):+/cygdrive/\1+; } then $filepath evaluates to /cygdrive/c/X/Rpkgs/Drydown_1.41.tar and I was able to build packages again. (Posted in case someone else has the same problem and/or finds this useful.) Kevin Wright __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bnlearn package compilation failure on MacOSX
On Thu 04/10/07, Prof Brian Ripley wrote: > You've got more serious problems than that: you cannot assume gcc. > For example on the SunPro compiler I got > [snip] > > Note that is in C99 mode, and under Linux. Hmm. I'm able to reproduce at least some of these errors using gcc in ansi mode: [EMAIL PROTECTED]/bnlearn/src]:gcc-4.2 -std=gnu99 -I/usr/share/R/include -I/usr/share/R/include -ansi -Wall -pedantic -std=c99 -fpic -g -O2 -c mutual.information.c -o mutual.information.o mutual.information.c: In function 'mi': mutual.information.c:34: warning: a member of a structure or union cannot have a variably modified type mutual.information.c:35: warning: a member of a structure or union cannot have a variably modified type I'll work on that. On the other hand I'm still curious: why r-patched-macosx-ix86 uses -std=gnu99 for the ppc arch but not for i386 one? -- Marco Scutari Linux Registered User #341807 http://counter.li.org powered by : Debian Sid GNU/Linux (SGI-XFS) Kernel 2.6.21.3 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bnlearn package compilation failure on MacOSX
On Thu 04/10/07, Simon Urbanek wrote: > It was not deliberate. The current R build (R 2.6.0) was modified > to use -std=gnu99 in the CC section for both architectures instead > of using CFLAGS, that should solve the problem. A work around for > older R is to set PKG_CFLAGS=-std=gnu99 when installing bnlearn. Ok. > However, note that C99 compiler is not required for R so it may > not be available. Since you don't really need any advanced > functionality of C99, it may be a good idea to change it to a more > portable C code. That's what I'm going to do; it's now on the top of my TODO list. >> Is it safe to force gcc to use C99 with either -std=c99 o >> -std=gnu99? >> > > Not in your package as cannot assume gcc in general, but > temporarily for R 2.5.1 on OS X, yes. Thanks for the clarification. -- Marco Scutari Linux Registered User #341807 http://counter.li.org powered by : Debian Sid GNU/Linux (SGI-XFS) Kernel 2.6.21.3 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bnlearn package compilation failure on MacOSX
Marco, On Oct 4, 2007, at 2:05 PM, Marco Scutari wrote: > I've recently uploaded a package (bnlearn) to CRAN. It builds fine > on both Linux (32 and 64 bit) and Windows, but fails on MacOSX ix86 > because of C90 vs C99 issues: > > http://www.r-project.org/nosvn/R.check/r-patched-macosx-ix86/ > bnlearn-00install.html > > Since I've no MacOSX machine at hand, I would like to ask you: why > is C99 not the default for gcc on MacOSX ix86? It was not deliberate. The current R build (R 2.6.0) was modified to use -std=gnu99 in the CC section for both architectures instead of using CFLAGS, that should solve the problem. A work around for older R is to set PKG_CFLAGS=-std=gnu99 when installing bnlearn. However, note that C99 compiler is not required for R so it may not be available. Since you don't really need any advanced functionality of C99, it may be a good idea to change it to a more portable C code. > Is it safe to force gcc to use C99 with either -std=c99 o -std=gnu99? > Not in your package as cannot assume gcc in general, but temporarily for R 2.5.1 on OS X, yes. Thanks, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
