Fortran DLLs called from Tcl (via Gustav Ivanovic's code / Ffidl)

149 views
Skip to first unread message

nickfort....@gmail.com

unread,
Nov 3, 2014, 5:42:29 AM11/3/14
to
Hi all,

I'm new to Tcl/Tk in general, and am just testing it out to see if it would fulfil my needs for building a GUI for my Fortran code before I jump into learning Tcl/Tk properly. After some research, I came across Gustav Ivanovic's code, which seems like exactly the sort of thing I was looking for: http://wiki.tcl.tk/13265

I particularly like the idea of loading DLLs, since I already load DLLs using MS Excel as a front-end, so required rework on the Fortran side would be minimal.

However, when I try to run Gustav's example (just using the Windows APIs, i.e. with the FtnTcl.dll bits commented out), I get an error:

can't read "x": no such variable
while executing
"llength $x" invoked from within...

I'm using binaries obtained from these locations:
- tclkit-8.5.9-win32.upx.exe from http://code.google.com/p/tclkit/downloads/list
- Ffidl06 from http://elf.org/ffidl/

I tried contacting Gustav at the provided email address, but the email bounced, and I don't know how else to get in touch with him.

I just had to update his code to say "load ffidl06" instead of "load ffidl05", due to the newer version of Ffidl at the link above. However, I realise that Gustav's code was written a decade ago, and things within Tcl and Ffidl are likely to have changed since then, which is probably what's causing the error. It's also entirely possible that there's something basic I'm not doing properly, so please let me know if I can provide any other relevant information.

I would greatly appreciate any help this newsgroup might be able to provide.

Best regards,
NF

Rich

unread,
Nov 3, 2014, 7:04:28 AM11/3/14
to
nickfort....@gmail.com wrote:
Note, I can't comment on your Fortran/DLL loading items, but this
message you received:

> can't read "x": no such variable
> while executing
> "llength $x" invoked from within...

Is given by Tcl when you try to access a variable name that does not
yet exist. Tcl is defined that access to variables that do not exist
generate errors.

So the above would mean that no "set x ..something.." had occurred to
make a variable "x" exist prior to the llength attempting to retreive
the value of "x".


Arjen Markus

unread,
Nov 3, 2014, 7:27:27 AM11/3/14
to
For combining Fortran and Tcl you might also find my Ftcl project on SF useful (http://ftcl.sf.net). While not specifically designed with loading DLLs in mind, it does provide an interface between these two languages. Especially the Wrapfort part might be useful, if you are sending arrays of data back and forth.

Regards,

Arjen

nickfort....@gmail.com

unread,
Nov 3, 2014, 7:43:05 AM11/3/14
to
Thanks for the reply, Rich. Your comment got me thinking along the right lines, and I've found the problem now.

I specifically commented out anything to do with the Fortran DLL in "proc test" in Gustav's code, and am only using the part that declares and calls the Windows DLLs. My idea is to remove uncertainty with the custom Fortran DLLs for now.

However, I've just realised that I commented out "set l 32" in "proc test" as well, because it visually seemed to belong to the Fortran DLL section. All working fine now! Thanks!

nickfort....@gmail.com

unread,
Nov 3, 2014, 8:04:46 AM11/3/14
to
Thanks, Arjen -- I did come across your work in my investigation (as I have done many times in the past when looking for Fortran-related things ;) ), but I felt that loading and using DLLs I already had would be the more appropriate solution for this particular task.

Rich

unread,
Nov 3, 2014, 8:13:17 AM11/3/14
to
nickfort....@gmail.com wrote:
> On Monday, 3 November 2014 12:04:28 UTC, Rich wrote:
> > nickfort....@gmail.com wrote:
> > Note, I can't comment on your Fortran/DLL loading items, but this
> > message you received:
> >
> > > can't read "x": no such variable
> > > while executing
> > > "llength $x" invoked from within...
> >
> > Is given by Tcl when you try to access a variable name that does
> > not yet exist. Tcl is defined that access to variables that do not
> > exist generate errors.
> >
> > So the above would mean that no "set x ..something.." had occurred
> > to make a variable "x" exist prior to the llength attempting to
> > retreive the value of "x".

> Thanks for the reply, Rich. Your comment got me thinking along the
> right lines, and I've found the problem now.

You are welcome. Glad to have helped.

> I specifically commented out anything to do with the Fortran DLL in
> "proc test" in Gustav's code, and am only using the part that
> declares and calls the Windows DLLs. My idea is to remove uncertainty
> with the custom Fortran DLLs for now.

I suspected you might have been simplifying things for your tests, and
accidentailly "oversimplified" as a result.

> However, I've just realised that I commented out "set l 32" in "proc
> test" as well, because it visually seemed to belong to the Fortran
> DLL section. All working fine now! Thanks!

Welcome.

nickfort....@gmail.com

unread,
Nov 3, 2014, 9:35:33 AM11/3/14
to
I'm just putting this here for others in case they come across the same thing in future. Gustav's code is written to work with DLLs made with Compaq Visual Fortran (it would probably work with Intel Fortran as well). I hope this isn't too much of a non-Tcl topic, but it's useful to know that it can be made to work with GNU gfortran as well, with a few modifications (in the Fortran code/compilation):

1. The Fortran code shouldn't be in a module, due to the way that gfortran names DLL functions in modules (the module name and some underscores are prefixed), and the ALIAS attribute isn't supported by gfortran (yet).

2. Related to the ALIAS issue, this directive won't work in gfortran:

!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: 'doublevector' ::doublevector

but it will work as

!GCC$ ATTRIBUTES STDCALL :: doublevector

Now, assuming the Fortran code is in tcl.f90, the DLL should be compiled as follows:

gfortran -c -fno-underscoring tcl.f90 -o tcl.o
gfortran -shared -mrtd -fno-underscoring -"Wl,--kill-at" -static-libgfortran -static-libgcc tcl.o -o FtnTcl.dll

The "static" flags are to make the DLL work on systems where gfortran hasn't been installed separately. Other flags (e.g. optimisation options) should also be added, as required.

I hope that helps someone out there to call gfortran DLLs from Tcl.

Arjen Markus

unread,
Nov 4, 2014, 2:28:44 AM11/4/14
to
Op maandag 3 november 2014 15:35:33 UTC+1 schreef nickfort....@gmail.com:
You might consider adding this information to the Wiki.

I have fallen for the trap of -static-lib... more often than I remember. Not to mention the infernal confusion about STDCALL.

Regards,

Arjen

Arjen Markus

unread,
Nov 4, 2014, 2:29:32 AM11/4/14
to
Op maandag 3 november 2014 14:04:46 UTC+1 schreef nickfort....@gmail.com:

> Thanks, Arjen -- I did come across your work in my investigation (as I have done many times in the past when looking for Fortran-related things ;) ), but I felt that loading and using DLLs I already had would be the more appropriate solution for this particular task.

:) It is a fairly small world.

Regards,

Arjen

nickfort....@gmail.com

unread,
Nov 4, 2014, 2:53:17 PM11/4/14
to
That's a good idea, although I see that someone (you?) has already added a link to this discussion under "See Also" at http://wiki.tcl.tk/13265. Should I add the relevant bits above to the page directly, including exactly what Tcl.f90 should be? If so, should I edit the page, or add a comment? I'm completely unfamiliar with editing Wikis of any kind... Thanks!

NF

Arjen Markus

unread,
Nov 5, 2014, 3:17:04 AM11/5/14
to
Op dinsdag 4 november 2014 20:53:17 UTC+1 schreef nickfort....@gmail.com:

> That's a good idea, although I see that someone (you?) has already added a link to this discussion under "See Also" at http://wiki.tcl.tk/13265. Should I add the relevant bits above to the page directly, including exactly what Tcl.f90 should be? If so, should I edit the page, or add a comment? I'm completely unfamiliar with editing Wikis of any kind... Thanks!
>
> NF

That was "Poor Yorick". I myself prefer to see those bits on the page itself.

I would say, add a comment, we can always revise it later and adding a comment may be simpler than editing the page, since you are unfamiliar with Wiki pages. It is not all that difficult, luckily, but inserting a comment is slightly simpler ;).

Regards,

Arjen

nickfort....@gmail.com

unread,
Nov 6, 2014, 5:07:44 PM11/6/14
to
Done! I've also included how to do it under Linux (which is a tad more complex): http://wiki.tcl.tk/13265

Regards,
NF

nickfort....@gmail.com

unread,
Nov 7, 2014, 3:01:13 PM11/7/14
to
Hmmmm, this is weird. Somehow, since I added the comment, Gustav's original code seems to have become slightly corrupted. Where it said:

if {$tclName == {}} {
set tclName $routineName
}

it now has the "==" missing, so

if {$tclName {}} {
set tclName $routineName
}

I only discovered this because I copied it again into a new file, and tried all of the above again, only to find that it wouldn't work. I had a copy of the file I'd previously saved, and I managed to find the discrepancy. Anyway, could some more knowledgeable than myself please correct it?

Apologies if it was my fault somehow... (Could it be a bug in the wiki software?)

Cheers,
NF

nickfort....@gmail.com

unread,
Nov 8, 2014, 2:02:36 PM11/8/14
to
OK, just found the "edit" button on the Wiki page, and changed it myself. Hope that's OK!

Cheers,
NF
Reply all
Reply to author
Forward
0 new messages