ISO C BINDING Strangeness

[afcalderncsu_edu]

Hi all,

I do not really know how to describe this, so I am including my source and project files inside a zip.

Essentially I wrote a function in C that I want to use in Fortran. The function always returns zero. I have a variable set to the output of the of the funtion. The first time I print it, I get a zero. Any other time I print it I get random numbers that are always 4 off.

I was expecting:
0
0
0

But instead I get:

0
4258784
4258788

with the last two numbers always random and yet 4 apart.

Any Ideas?

Thanks,

Adan Calderon

[mecej4]

>Any ideas?
Too many cooks in one kitchen.

Here is the problem:

> clib.vcxproj: StdCall
and
> FUNCTION csample (argc, argv, groups) BIND(C, NAME='csample@32')

Do not mix Fortran 200x C interoperability with your own specifications of calling conventions, unless this is really necessary (it rarely is).

Specify the default calling convention in your clib.vcxproj, and change the function declaration to

FUNCTION csample (argc, argv, groups) BIND(C, NAME='csample')

[afcalderncsu_edu]

Thank you mecej4.

That solved my sample problem but,

The reason I created these projects and solution was to test something out.

I am haveing a very similar error trying to get a fortran project to talk to mysql.


When I issues out the command:

dumpbin /exports libmysql.lib
.
.
_mysql_server_init@12
.
.
I got a lot of symbols with the "@" character and a number at the end as a suffix.
As far as I know libmysql.lib is nothing more but a collection of symbols that are tied into a dll.
So if one links against it, one needs to have libmysql.dll

No matter what combinations of calling conventions I used in visual studio 2010,
I could not link to the library unless I used the NAME='name@n'
I did omit the underscore prefix.

Any advice on how to proceed? I have stripped down the solution/project and I am attaching it as a zip.

Thanks again,

Adan Calderon

[Steven_L_Intel1]

The @n suffix indicates a STDCALL interface procedure. In Intel Fortran, you cannot use BIND(C) to declare interfaces to such procedures - you must use the !DEC$ ATTRIBUTES directives, such as:

!DEC$ ATTRIBUTES STDCALL, REFERENCE, DECORATE, ALIAS:"mysql_server_init" :: mysql_server_init

If you try to "correct" link errors by explicitly including the @n suffix in an alias, you will corrupt the stack due to inconsistent calling conventions.

[mecej4]

Since MySQL is more likely to be called from C than Fortran, there may be a C-callable DLL for MySQL, and a corresponding import library. If so, it would be easier to call that from Intel Fortran using ISO-C-bindings than to use DEC$ directives to call the STDCALL library/DLL combination that you have at present -- these may have been created for the convenience of PowerStation/Digital/Compaq Fortran users; check the file dates.

[afcalderncsu_edu]

Thanks for the clarifications Steve. I really wish I could use ISO C Binding and STDCALL, but I guess I can not. Is this something inherent to Intel Visual Fortran or would it be the case with all compilers? I am hoping that when I am done with my code, it will also compile in Linux and hopefully with ifort.

I would rather not use the DEC directives.

I download the source for MySQL 5.5.19 as well as their C connector API package. Both source trees use cmake and hence, I was a little let down. I believe prior versions of the MySQL source tree came with visual studio projects. I sort of feel like it's messy with all the custom build steps added by cmake.

In either case, I had no luck getting them to compile using the cdecl calling convention as 32 bit programs.

I then downloaded Oracle's pre-compiled 64-Bit zip package. The dll and lib files that came inside the zip file seem to work and link correctly. A dumpbin of them shows no @n suffix.

I have changed my project's target platform to x64 and I have removed all @n entries I had explicitly typed onto the "name=" sections. I hope I will have more success with this approach.

On a side note, my user logon name on this forum is afcalder@ncsu.edu and yet the @ symbol seems to be removed from the posts.

Thanks,

Adan Caldern

[TimP]

Not so long ago, gfortran was making an effort to include a stdcall option under ISO C binding. I didn't entirely understand the motivation or the extent to which it was likely to be supported. Bear in mind that stdcall was already discouraged by Microsoft by the time ISO C binding entered the Fortran standard.
I agree that X64 ought to be a preferable path going forward.
These forums have been a major spamming target, so a full display of an email address here is likely to give you trouble.