From: Arjen Markus on
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

"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

"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

"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
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