On 16/01/2012 8:55 AM, David Stevens wrote:
I installed RTools - though I'm unable to use it within R, from the
command prompt the file will compile and create the foo.dll using R CMD
SHLIB foo.f. I simlified to code for fortran IV (?really) compliance
foo.f:
Subroutine foo(x)
real x
x = x + 2.
return
end
R CMD SHLIB foo.f
cygwin warning:
MS-DOS style path detected: d:/PROGRA~1/r/R-214~1.1/etc/i386/Makeconf
Preferred POSIX equivalent is:
/cygdrive/d/PROGRA~1/r/R-214~1.1/etc/i386/Makeconf
CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
gfortran -O3 -mtune=core2 -c foo.f -o foo.o
gcc -shared -s -static-libgcc -o foo.dll tmp.def foo.o
-Ld:/RCompile/CRANpkg/extralibs/local/lib/i386
-Ld:/RCompile/CRANpkg/extralibs/local/lib -lgfortran
-Ld:/PROGRA~1/r/R-214~1.1/bin/i386 -lR
Now the issue is getting it to dyn.load("foo.dll"). I'm greeted with
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object 'd:/Fortran folders/Fortran
Multiresponse/foo.dll':
LoadLibrary failure: %1 is not a valid Win32 application.
Any thoughts?
It worked for me. That is, I created the foo.f file, then ran
R CMD SHLIB foo.f
from the command line, then rgui on the command line. Once in R I ran
dyn.load("foo.dll")
and it worked without a complaint on my system. I would guess the
differences are:
1. I have the stupid "nodosfilewarning" set to keep Cygwin programs quiet:
set CYGWIN=nodosfilewarning
2. I ran rgui from the command line. That means I got it from the same
path where R was found in the R CMD SHLIB call. You might have run a
different version, or might have been in a different directory, trying
to load some other "foo.dll" if you started rgui in some other way.
Duncan Murdoch
David S
On 1/15/2012 5:09 PM, Duncan Murdoch wrote:
> On 12-01-15 5:34 PM, David Stevens wrote:
>> I successfully used .Fortran to load and execute my fortran procedures
>> under WinXP and 32 bit R. Alas, the same isn't true with my next Windows
>> 7/64 machine, R 2.14.1 (64 bit) and the gnu gfortran (64) compiler
>> (mingw64 v. 4.6.1). Though I'm able to compile the routines from the
>> command line using gfortran '...', .Fortran('foo2') results in an error
>> saying the Fortran symbol name "foo2" not in load table.
>>
>> foo.f90:
>>
>> Module foo
>> contains
>> Subroutine foo2(x)
>>
>> real(kind=8),intent(inout) :: x
>> x = x + 2
>>
>> end subroutine foo2
>>
>> end module foo
>>
>> c:\mingw64\bin\gfortran --shared -Wall -pedantic -g -o foo.dll foo.f90
>>
>> ff = "d:/Fortran folders/Fortran Multiresponse/foo.dll"
>> x= dyn.load(ff)
>> .Fortran('foo2',as.double(1))
>>
>> Error in .Fortran("foo", as.double(1)) :
>> Fortran symbol name "foo" not in load table
>>
>> Can someone point me in the direction of a solution?
>
> Some or all of these might help:
>
> 1. Get R to do the compiling for you: it knows the compiler
> arguments that produce compatible code. (Use R CMD shlib for this.)
>
> 2. Use a compiler supplied with the Rtools collection.
>
> 3. Find out what name got exported, and use .C instead of .Fortran to
> call that.
>
> Duncan Murdoch
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
