I'm a little worried this is getting off track.  I'll recap

1. I'm using R 2.14.1 from CRAN - installed last week in d:\program 
files\R\R-2.14.1 using the Windows installer
2. I've just installed Rtools 15.1 this morning in d:\Rtools at Duncan's 
recommendation using the Rtools Windows installer
3. my folder is "d:\fortran folders\fortran multiresponse"
4. my file is "foo.f"
5. from the command line I navigate to my folder where foo.f is located
6. from the command line I type "set CYGWIN=nodosfilewarning"
7. from the command line I then type "R CMD SHLIB foo.f" and get
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
8. I check the directory and find a newly created foo.dll
9. from the command line I type 'rgui' (w/o the quotes) and an R console 
opens with V 14.1 on the masthead
10. In R, I check the path with getwd() and find my path "d:\fortran 
folders\fortran multiresponse"
11. then from the R gui dyn.load("foo.dll")yields

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*.

12. To make sure that the proper file is being found, from the command 
line I delete foo.dll and try again

 > dyn.load("foo.dll")

Error in inDL(x, as.logical(local), as.logical(now), ...) :
   unable to load shared object 'd:/Fortran folders/Fortran 
Multiresponse/foo.dll':
   LoadLibrary failure: *The specified module could not be found*.

13. I then recreate foo.dll as above and try to load

Errorin 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*.
nd.

14. So, I try to build the dll from R

system("R CMD SHLIB foo.f")

x86_64-w64-mingw32-gcc -shared -s -static-libgcc -o foo.dll tmp.def 
foo.o -Ld:/RCompile/CRANpkg/extralibs64/local/lib/x64 
-Ld:/RCompile/CRANpkg/extralibs64/local/lib -lgfortran 
-LD:/PROGRA~1/R/R-214~1.1/bin/x64 -lR
d:/rtools/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
i386 architecture of input file `foo.o' is incompatible with i386:x86-64 
output
foo.o:foo.f:(.text+0x44): undefined reference to `__gfortran_st_write'
foo.o:foo.f:(.text+0x58): undefined reference to `__gfortran_transfer_real'
foo.o:foo.f:(.text+0x60): undefined reference to `__gfortran_st_write_done'
collect2: ld returned 1 exit status

15. No good, so I check the path
PATH=...;d:\program 
files\r\r-2.14.1\bin;D:\Rtools\bin;D:\Rtools\perl\bin;D:\Rtools\MinGW64\bin;D:\Program
 
files\R\R-2.14.1\bin\x64;

16. Going back to compiling from the command line, it appears to me that 
the Rtools compiler (I assume that's what's used with the R CMD SHLIB 
command) is delivering an incompatible dll.

Shall I delete everything, reinstall, and try again?

BTW, I've successfully used .Fortran on previous versions of  R and 
plain vanilla gfortran (from gcc) on an older winxp32 machine using 
fairly sophisticated fortran 95 code, with modules, structures, etc, so 
I'm not a complete babe-in-the-woods (though apparently I'm back to 
being that). That said there is much I don't know especially about 
differences between 32- and 64-bit code that comes from the compilers 
and interfaces between R and shared libraries

Any and all help is appreciated!

David

On 1/16/2012 7:37 AM, Duncan Murdoch wrote:
> 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
>>
>

-- 
David K Stevens, P.E., Ph.D., Professor
Civil and Environmental Engineering
Utah Water Research Laboratory
8200 Old Main Hill
Logan, UT  84322-8200
435 797 3229 - voice
435 797 1363 - fax
david.stev...@usu.edu




        [[alternative HTML version deleted]]

______________________________________________
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.

Reply via email to