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
