similar to: R crashes on calling a Fortran routine (PR#2728)

Hi, I am having problems calling a fortran routine from within R. When the routine is called, R exits with an application error: "The instruction at 0x004a8b7d referenced memory at 0x200000015. The memory could not be written". The R code used to call the routine is: .Fortran("GTEST",a=as.integer(1),b=as.integer(3),c=as.integer(-10),d=as.inte ger(0),e=as.integer(0)) The

Hi, "we can, once we know how to do it, 'drive' R from within FORTRAN" I am not sure I understand what you mean by this ... You can call routines written in Fortran or C from within R - how easy this is depends on the interfaces to those routines. You can call (some) R functionality from C (see for example

Dear R community, I have a question on how R manages memory allocation in .Fortran() calls under Windows. In brief, apparently, it is not possible to allocate large matrices inside a Fortran subroutine unless you pass them as arguments. If you do not act in this way RGUI crashes with a stack overflow error and acting on memory through vsize nsize ppsize and memory.limit does not help at all.

I just joined the list and appologize if this has been answered before but I am trying to interface between R and the Compaq Visual Fortran compiler version 6.6 for Windows. I found the following instructions on the web -- and an example. When I follow these directions exactly. R 2.0.0 crashes. Has anyone had any experience with this? Below are the instructions that I located: Thanks Dan

I have the following FORTRAN code converted to a DLL: ! my_xmean.f90 ! ! FUNCTIONS/SUBROUTINES exported from my_function.dll: ! my_function - subroutine ! subroutine my_xmean(X,N,XMEAN) ! Expose subroutine my_function to users of this DLL ! !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean ! Body of my_function DOUBLE PRECISION X(N) XMEAN=0D0 DO J=1,N

I am trying to call a FORTRAN subroutine from R. is.loaded is turning out to be TRUE. However when I run my .Fortran command I get the following error: Error in .Fortran("VALUEAHROPTIMIZE", as.double(ahrArray), as.double(kwArray), : Fortran symbol name "valueahroptimize" not in load table I have given the FORTRAN declaration below: subroutine VALUEAHROPTIMIZE(AHR,

I am trying to call a FORTRAN subroutine from R. is.loaded is turning out to be TRUE. However when I run my .Fortran command I get the following error: Error in .Fortran("VALUEAHROPTIMIZE", as.double(ahrArray), as.double(kwArray), : Fortran symbol name "valueahroptimize" not in load table I have given the FORTRAN declaration below: subroutine VALUEAHROPTIMIZE(AHR,

2011/10/18 Albert Graef <Dr.Graef at t-online.de>: > On 10/17/2011 04:44 PM, Duncan Sands wrote: >> PS: A more convincing (IMO) argument against dragonegg is that it doesn't >> work on windows.  That's because the gcc plugin architecture doesn't work >> on windows.  Takumi has been thinking about this and has been enable to >> get dragonegg to work on

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on

Here's a solution that took a while to find; I wanted to write it to the list so it'll be available for people in the future. Summary: In external Fortran code, use SUBROUTINEs, don't use FUNCTIONs. A colleague had bizarre things happening in uniroot() (a root finding routine), which she used to call an R function that called a Fortran routine to do some calculations. For example,

Hello, while improving and extending support for dllexport/import I have noticed that the current way these are implemented is problematic and I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, combining both doesn't make sense, but

Hi everybody, me again. I'm trying to write my own VFW-like dll... It doesn't need to do much. 1.) compress a single frame and give it back to the host application 2.) host applications sends the frame 3.) client application receives frame 4.) client application tells the dll to decompress the data So if I try to do this, something is going wrong... Perhaps someone could have a look at my

> > I am trying to use llvm-gcc to link shared libraries on windows/mingw32. > > When I try to link libraries that contain functions declared with > >  __declspec(dllexport) someFunction(); > > > > I get the link error: > > > >  Cannot export _someFunction: symbol not found > dllexport declspec should be put on the function definition, in this >

Hello. I was trying to compile https://github.com/llvm/llvm-project/tree/master/libunwind using: - MSVC - Clang I wasn't able to configure this project for using MSVC (directly or via clang-cl): >cmake -G Ninja -DLLVM_PATH="C:/Users/clang/llvm-project-10.0.1/llvm" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="C:\Users\clang\libunwind_llvm" ../libunwind --

> I am trying to use llvm-gcc to link shared libraries on windows/mingw32. > When I try to link libraries that contain functions declared with >  __declspec(dllexport) someFunction(); > > I get the link error: > >  Cannot export _someFunction: symbol not found dllexport declspec should be put on the function definition, in this example there is nothing to export - dllexport

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

On 01/23/17 01:01 AM, Erik de Castro Lopo wrote: > Dave Yeo wrote: > >> >GCC supports __declspec(dllexport) though it still needs a def file, >> >with no exports. Libtool doesn't currently and as flac uses libtool... > So you're happy with this patch? > > http://lists.xiph.org/pipermail/flac-dev/2017-January/006170.html > No. Lots of errors such

The following patch changes export.h so that the dllimport/dllexport attributes work with mingw/mingw-w64 and others: - changes _declspec keyword to __declspec: the former may not be defined by some toolchains. - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. Attached patch: declspec.diff Regards. -- O.S. -------------- next part --------------

Hi Nico, Thank you for your feedback. I'll try to answer your questions below. > What problems do you expect with another approach? I have a local > prototype that removes dllimport/export as linkage and uses function > attributes and an extension to globals. I decorate dllexported functions with > the Used attribute and it seems to work fine. This allows such functions to >

If building a static library, marking symbols as dllexport causes them to be exported from the final executable. For example, run objdump -x opus_demo.exe on a --disabled-shared build and look for the export table; there should not be one in a normal Win32 .exe file, but when linking static libopus, the exe exports all of the opus_* public functions. Use the libtool-defined DLL_EXPORT flag to