Duncan and Brian, Thanks again for the help with this. As it turns out the suggestion of setting the GFORTRAN_STDIN_UNIT=-1 has the library working for Mac, Linux, and Windows, so it appears to be in a STDIN read somewhere. Of the 1100 read statements in the code, none are from stdin, or unit 5. Oddly enough, without the environment variable set, everything runs fine looping within a script called from command line (-f) which I delve into a bit below. So, we are functional on repo binaries, and standard linux distros, but intel fortran and xlf appear to have issues still... not a big deal, but if anyone is willing to give me suggestions on other things I can use to try to debug this issue, I would love to clear it up.
Sorry for not giving all the background information. I am working/testing on Mac OSX(gfortran 4.2.3, intel fortran 11), Linux (gfortran 4.1.2, intel fortran 11) , WindowsXP (gfortran 4.5), and AIX(xlf v12.1). Right now the environment variable will work I believe since we are just trying to get the standard r-forge distro binaries to work with the package, though I shall keep looking for the STDIN that appears to have been opened. > Sys.setenv(GFORTRAN_STDIN_UNIT=-1) > library.dynam("rswat","EcoHydrology") > .Fortran("junk",3) SWAT Run Successful [1] 0 [[1]] [1] 3 > > Just a bit more information here on this issue. Without the Sys.setenv(GFORTRAN_STDIN_UNIT=-1) function, the .Fortran call runs fine in a loop when called from command line script file (-f) call. When called from interactive session, it runs successfully, then gets stuck in an endless loop of lines 911, 912, 904 in in ../../../../R-2.12.1/src/unix/sys-std.c . There appears to be no STDIO in the routines, and to make sure, I am now closing all the stdio units at the end of the run. DRF28: dan$ cat test.R library.dynam("rswat","EcoHydrology") for (i in 0:5){ .Fortran("junk",i) print(paste("success",i)) } DRF28: dan$ r -q -f test.R > library.dynam("rswat","EcoHydrology") > for (i in 0:5){ + .Fortran("junk",i) + print(paste("success",i)) + } SWAT Run Successful [1] 0 [1] "success 0" SWAT Run Successful [1] 1 [1] "success 1" SWAT Run Successful [1] 2 [1] "success 2" ----SNIP---- On Sat, Mar 26, 2011 at 11:49 PM, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote: > You seem to have missed the force of the warning in 'Writing R Extensions'. > > If you include *any* Fortrann I/O in your package code, you are at risk from > it interfering with C I/O, whether or not that Fortran I/O is called. > > On some platforms with gfortran, merely loading such a package's DSO/DLL > calls the libgfortran initialization functions and they reset the process' > stdin, causing the behaviour you saw. > > You have not told us what compilers etc you are using. On some versions of > gfortran you can avoid this by setting the environment variables > > GFORTRAN_STDOUT_UNIT > GFORTRAN_STDERR_UNIT > > to -1: these tell gfortran not to use C stdout/stderr (and because of what I > can only see is a bug, it was the use of those which resets stdin). > > > On Fri, 25 Mar 2011, Daniel Fuka wrote: > >> Thanks Duncan for helping me along the way. I am working in OSX, >> Linux, and Windows, and gdb is helping me trace it along to what >> appears to be an endless processor intensive loop in sys-std.c . >> Below, I have pasted the output. All files are closed as verified by >> lsof. There is absolutely no stdio other than what I have put in a >> call to R library's subroutine intpr, all other io is routed to files, >> which are all successfully closed. The entire routine successfully >> runs, and spits out the output from intpr. Is there supposed to be >> something returned from the Fortran routine that Rstd_ReadConsole is >> looking for? I have attached the final lines of the fortran >> subroutine, as well as the gdb steps post fortran routine. Any >> additional help is greatly appreciated! > > ... > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel