Undefined symbol: __ms_vsnprintf when linking with C code

[alex256]

Hello. I'm trying to link my FPC program with C code and I get a linker message:

Undefined symbol: __ms_vsnprintf

I compiled my C code with MinGW-w64. To link it, I used the following directives:

Code: Pascal  [Select][+][-]

1.    
2.     {$linklib libkernel32}
3.     {$linklib libmsvcr100}
4.     {$linklib libmsvcrt}
5.     {$linklib libcrtdll}
6.     {$linklib libgcc}
7.  

I wonder why can this thing happen and how to fix it.

[Thaddy]

http://mingw-users.narkive.com/lxdyxcXN/missing-symbol-ms-vsnprintf-when-linking-with-cross-compiled-library

According to this it was fixed some time ago:
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CALc40c_-sXP0EK_+7fmCwXrPcDs3Dm1TM67g6bHRgc8HeR+nfA@mail.gmail.com/

How old is your mingw (especially the inc's)?

[alex256]

I used the latest version of MinGW-w64 (6.3.0).

[Thaddy]

This seems not an FPC or Lazarus issue, but a mingw issue. Better ask there. It is a known issue if I google on it.

[alex256]

Thanks.

[alex256]

It may sound strange but I linked it for Win32 compiling my C code with MinGW and linking with libs from 32-bit version of MinGW-w64!
Still wonder how to link it for Win64.

[Thaddy]

The anwser is probably that the mingw64 includes are not correct. Try uninstalling mingw64 and re-install it with the correct headers from the install window.
mingw64 is a bit misleading name. But this is not a mingw forum. I use it, but my core development (for fpc purposes) is on cygwin64, so I can't help any further.
Maybe try cygwin64?

[alex256]

I tried to use cygwin64's libs and compile my C code in cygwin64. It linked fine, but the program crashes when I run it.

Used the following directives:

Code: Pascal  [Select][+][-]

1. {$linklib c}
2. {$linklib libgcc}
3. {$linklib libcygwin}
4. {$linklib libkernel32}
5.  

[Thaddy]

If this is your first 64 bit version of your code, review the code for 64 bit/32 bit sizeint issues.
The FPC side of the code will warn you with a "not portable" warning. The C side can also be made to emit such warnings.
The fact that it now links is proof that the linker can at least resolve all entries.

It is probably just a Native pointer or Native Integer size issue. Or a calling convention issue.

[DonAlfredo]

And use

Code: Pascal  [Select][+][-]

1. {$PACKRECORDS C}

!!

[Thaddy]

Indeed. {$packrecords C}  is essential. It may even be enough.
Otherwise check for my suggestions.

[alex256]

And use

Code: Pascal  [Select][+][-]

1. {$PACKRECORDS C}

!!

I used it.

The crash is in the C function which takes no parameters. I call it in the unit initialization. Assembler window says that the crash is in the freopen_r function (I call freopen from that C function).

[alex256]

It is probably just a Native pointer or Native Integer size issue. Or a calling convention issue.

Both from FPC and C sides functions are called as cdecl.

[Thaddy]

For the MS libraries that is most likely wrong on win64. Should be winapi or stdcall. win64 does not know cdecl. It knows only one calling convention. winapi selects the correct one on ms compilers based on a macro, cdecl too, but not on gnu. Note third party code can still be using cdecl, though.
MS provided code is ONLY cdecl if the headers for those libraries expressly say so.

[alex256]

I changes cdecl to stdcall in both FPC and C sides, but still have the same crash.