About Free Pascal and MinGW (or cygwin)

[MarkMLl]

I wonder whether I could throw in something belatedly: I expect to be fact-checked by Marco and if he says I'm wrong I'll delete this posting in case it causes further confusion.

Years and years ago, either FPC or Lazarus used some of the Cygwin functionality on Windows.

That is, as far as I know, thoroughly obsolete and any web pages that refer to it should be treated as suspect.

MarkMLl

[marcov]

Years and years ago, either FPC or Lazarus used some of the Cygwin functionality on Windows.

First cygwin, and then later mingw.  But that bit was the GDB debugger linked into the textmode IDE. There were some minor sideways related but reusable things like unit signals (ugh). It was never somewhere really deep in FPC itself.

Nowadays, on platforms that multitask, that has changed to working via pipes. Only single task systems like Dos still link GDB in.

As for standalone mingw/cygwin use, most of the binaries delivered with Windows releases are mingw, though in nearly all cases pretty old (and by that I mean near 20 years, because they are MSYS less versions). Only make is a bit newer due to parallel building becoming more important in the last decade(s).

Some are obsoleted or near obsoleted by "newer" FPC development like internal assembler (pre FPC 2.0), internal linker (2.2.0) and fpcres (3.2.2 is pretty capable, 3.2.4 will be even better, and when that version is out, it depends on the will to jump into the deep and make it default)

[marcov]

That is not about DLL, but static libraries.

You sure? TS is talking about trying to generate a dll, but uses linklib

And that is wrong for nearly everything not ancient (and by that I mean 20 if not 25 years +).

He references a thread that talks about static linking, but is himself talking about DLLs in the post that makes the reference which is not consistent.

I suspect he wants to link a library that he has in DLL form statically.  But that is quite an advanced topic.

[MarkMLl]

First cygwin, and then later mingw.  But that bit was the GDB debugger linked into the textmode IDE. There were some minor sideways related but reusable things like unit signals (ugh). It was never somewhere really deep in FPC itself.

OK, TFT. So there's a risk that OP's been led astray by something he's found in a mailing list archive etc.

MarkMLl

[PascalDragon]

i get "import library not found" when replacing .dll generated by minGW with VS2022 one

FPC's internal linker does not support static or import libraries as generated by Visual Studio's linker. If you need them then you need to make sure the external linker using -Xe.

[440bx]

FPC's internal linker does not support static or import libraries as generated by Visual Studio's linker. If you need them then you need to make sure the external linker using -Xe.

Please clarify for me:

Is it possible to use an MS C produced obj or lib using the external linker ?

if the answer is yes, could you please elaborate and/or provide a simple example ?

Thank you.

[PascalDragon]

FPC's internal linker does not support static or import libraries as generated by Visual Studio's linker. If you need them then you need to make sure the external linker using -Xe.

Please clarify for me:

Is it possible to use an MS C produced obj or lib using the external linker ?

if the answer is yes, could you please elaborate and/or provide a simple example ?

Simply use {$link ...} or {$linklib ...} like with any object file or library and pass -Xe when compiling, so that ld is used (which correctly supports the formats used by the Microsoft linker). Though for object files you can also use the internal linker as those are simply COFF object files. However static libraries have a slight difference in the header between the MSVC and GCC formats.

[440bx]

For some reason I was under the impression that MS had departed enough from standard COFF object files to make them incompatible with them.  My misunderstanding.

Thank you for the clarification.  This is really good to know.

[rforcen]

in visual studio exported funcs MUST include prefix "__declspec(dllexport)  "

Code: C  [Select][+][-]

1. extern "C" {
2.     __declspec(dllexport) int foo(int a, int b) { return a+b; }
3. }

in fpc as usual:

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

1. function foo(a,b:integer); cdecl; external;