From: Arjen Markus on 18 Nov 2009 10:07 On 18 nov, 03:22, Clark <c...(a)uswest.net> wrote: > I've run across some f95 code that appears useful for one of my problems. It > compiles and executes just fine using gfortran on a windows box. > > I'd really like to access the routines directly from Excel using VBA which > means (at least to me) that I'd like to compile the f95 to a Windows dll. > > Since I'm many years out of touch with the Fortran world, would someone be > kind enough to point me towards the shortest path to compiling the Windows > dll without having to spend an arm and/or leg on a compiler? > > -- > --- > there should be a "sig" here What compiler are you using? The latest version of gfortran should be able to produce DLLs without a problem (problems that may arise on Windows have to do with the calling conventions - __declspec() and __stdcall - but I think these have been solved). In that case compiling and linking with -shared or a similar flag (memory does not serve me right now) will produce the DLL you want. Regards, Arjen
From: e p chandler on 18 Nov 2009 12:10 "Clark" <ch2(a)uswest.net> wrote in message news:Xns9CC6C53C04466ch2uswestnet(a)94.75.244.46... > I've run across some f95 code that appears useful for one of my problems. > It > compiles and executes just fine using gfortran on a windows box. > > I'd really like to access the routines directly from Excel using VBA which > means (at least to me) that I'd like to compile the f95 to a Windows dll. > > Since I'm many years out of touch with the Fortran world, would someone be > kind enough to point me towards the shortest path to compiling the Windows > dll without having to spend an arm and/or leg on a compiler? > > -- > --- > there should be a "sig" here
From: e p chandler on 18 Nov 2009 12:23 "Clark" <ch2(a)uswest.net> wrote in message news:Xns9CC6C53C04466ch2uswestnet(a)94.75.244.46... > I've run across some f95 code that appears useful for one of my problems. > It > compiles and executes just fine using gfortran on a windows box. > > I'd really like to access the routines directly from Excel using VBA which > means (at least to me) that I'd like to compile the f95 to a Windows dll. > > Since I'm many years out of touch with the Fortran world, would someone be > kind enough to point me towards the shortest path to compiling the Windows > dll without having to spend an arm and/or leg on a compiler? gfortran OR g95 work just fine in this situation. You have to deal with 3 main issues: 1. calling convention - cdecl vs stdcall. Also both sides use call by name. 2. arguments must match in position, type and number. Strings have a hidden argument for the length. 3. name mangling. names must match including case, underscoring, avoid @n suffix. a web search on this newsgroup using my last name, vb and dll should help you.
From: e p chandler on 18 Nov 2009 16:32 "Clark" <ch2(a)uswest.net> wrote in message news:Xns9CC77C536ED06ch2uswestnet(a)94.75.244.46... > "e p chandler" <epc8(a)juno.com> wrote in > news:he1aiu$ce6$1(a)news.eternal-september.org: > >> >> "Clark" <ch2(a)uswest.net> wrote in message >> news:Xns9CC6C53C04466ch2uswestnet(a)94.75.244.46... >>> I've run across some f95 code that appears useful for one of my >>> problems. It >>> compiles and executes just fine using gfortran on a windows box. >>> >>> I'd really like to access the routines directly from Excel using VBA >>> which means (at least to me) that I'd like to compile the f95 to a >>> Windows dll. >>> >>> Since I'm many years out of touch with the Fortran world, would someone >>> be kind enough to point me towards the shortest path to compiling the >>> Windows dll without having to spend an arm and/or leg on a compiler? >> >> gfortran OR g95 work just fine in this situation. You have to deal with >> 3 main issues: >> >> 1. calling convention - cdecl vs stdcall. Also both sides use call by >> name. >> >> 2. arguments must match in position, type and number. Strings have a >> hidden argument for the length. >> >> 3. name mangling. names must match including case, underscoring, avoid >> @n suffix. >> >> a web search on this newsgroup using my last name, vb and dll should >> help you. >> >> > Thanks for the pointers. I'm familiar with calling dlls from VBA so > hopefully > I won't screw that part up too bad. I'm more concerned with exposing the > subroutines and finding the darn switch to tell the compiler that it's a > dll > rather than an exe. > > I'll search the newsgroup. Thanks again for the suggestions. Here are the files I use to create a sample function for Excel/VBA: test.f95: function isub2(i,j) isub2=i-j end test.def: EXPORTS isub2=isub2_ make.bat: g95 -s -shared -mrtd -o test.dll test.def test.f95 In VBA, insert a module and add under general / declarations: Declare Function isub2 Lib "test.dll" (i As Long, j As Long) As Long On the worksheet add: =isub2(cell_ref1,cell_ref2) Put both the .xls and the .dll in "My Documents" or "Documents". Enable macros. ---------------------------- You do not need to worry about exporting function names. In the .def file, the EXPORTS removes the trailing underscore from the symbol. g95 does not add @n. The command line for gfortran would be the same as g95. -s strip symbols -shared make a dll -mrtd use stdcall convention -o output file Note that the most recent versons of gfortran (4.5) allow attributes to be specified in about the same way as did MS-Fortran (FPS4), DVF, CVF and IVF except that the MS or DEC has been replaced by gcc.
From: Tobias Burnus on 19 Nov 2009 03:49 On 11/18/2009 10:32 PM, e p chandler wrote: >>> 1. calling convention - cdecl vs stdcall. Also both sides use call by >>> name. >>> >>> 2. arguments must match in position, type and number. Strings have a >>> hidden argument for the length. Consider using the C binding - then you do not get an additional hidden argument. >>> 3. name mangling. names must match including case, underscoring, avoid >>> @n suffix. Well, the mangling depends on the calling convention. The 32-bit Windows ABI has @n suffix for STDCALL - thus the question is rather one of the calling convention or not. Usually, the decoration happens automatically (though -mrtd, cf. below, does not add it). > The command line for gfortran would be the same as g95. > > -s strip symbols > -shared make a dll > -mrtd use stdcall convention I would avoid "-mrtd" if possible as it might change too many conventions to STDCALL even those which should remain CDECL - but if you do not have the choice (e.g. g95 or gfortran < 4.5) one still might need to use them. > Note that the most recent versons of gfortran (4.5) allow attributes to > be specified in about the same way as did MS-Fortran (FPS4), DVF, CVF > and IVF except that the MS or DEC has been replaced by gcc. Well, the syntax and the supported features are slightly different, but for STDCALL that should not matter. For BIND(C) in gfortran see: http://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html (Should mostly apply to all recent Fortran compilers.) [More details can be found in your favorite Fortran 2003 book.] For using the mentioned attributes STDCALL, EXPORT, IMPORT in gfortran 4.5 see http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html Tobias
|
Pages: 1 Prev: Random number generators Next: Convert CDF to ASCII format |