About Free Pascal and MinGW (or cygwin) lazarus / 43-Android ---------------------------------------------------------------------- jmpessoa · 2013-06-04 03:26 Hi there! I learned that the android-ndk can produce/compile native library  write in "C" "binding" against MinGW (or cygwin) stuff on Windows environment... Anyone know about the possibility of Free Pascal "binding" against MinGW(or cygwin) stuff on Windows to produce Linux library? I found this: ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/ Is it about this subject? Thanks in advance .. ---------------------------------------------------------------------- marcov · 2013-06-05 08:01 One can generate linux binaries on Windows. This is what crosscompiling does. Generally on windows, one uses crossassemblers, archivers and linkers from mingw sources.  The rest is not really necessary. (in rare cases also windres). Just search for crosscompiling topics on this forum. ---------------------------------------------------------------------- jmpessoa · 2013-06-05 15:11 Very thank Marcov! ---------------------------------------------------------------------- rforcen · 2024-07-01 09:41 i use this release with full posix thread support and compatible .dll generation, other version are incompatible in terms of .dll headers or do not support std::threads g++  -std=c++11 -pthread -static -shared -O3 -o yourdll.dll source_cpp_files.cpp https://sourceforge.net/projects/mingwbuilds/files/host- windows/releases/4.8.1/64-bit/threads-posix/sjlj/x64-4.8.1-release- posix-sjlj-rev5.7z/download ---------------------------------------------------------------------- marcov · 2024-07-01 09:44 Note that FPC on Windows is SEH not SJLJ, though for the 32-bit version that is relatively recent (3.2.0) ---------------------------------------------------------------------- rforcen · 2024-07-01 16:52 moved to the seh version @ https://sourceforge.net/projects/mingwbuilds/ so what's the recommended MinGw version & location, currently using gcc version 4.8.1 ? current 3.4 version uses GNU ld (GNU Binutils) 2.23.2, so should mingw version be compatible? I've also tried to generate a .dll w/visual studio 2022 with no success (import library not found), is this possible? ---------------------------------------------------------------------- marcov · 2024-07-01 17:38 The recommend utils come with FPC. But for building DLLs to be used with FPC, SEH is probably best. I compile my C/C++ code with Visual Studio though, so I wouldn't know what  mingw to use currently ---------------------------------------------------------------------- rforcen · 2024-07-02 07:11 i get "import library not found" when replacing .dll generated by minGW with VS2022 one ---------------------------------------------------------------------- marcov · 2024-07-02 11:49 Huh? Free Pascal usually doesn't need import libs. ---------------------------------------------------------------------- rforcen · 2024-07-02 11:57 Yes, the mingw versión doesn't need It, I use {$linklib} not LoadLibrary('module.DLL') ---------------------------------------------------------------------- marcov · 2024-07-02 12:03 Quote from: rforcen on July 02, 2024, 01:57:09 pmYes, the mingw versión doesn't need It, I use {$linklib} not LoadLibrary('module.DLL') $linklib is for static libraries (.a). For .dll, just name them in your declarations Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function xx(parameters):resulttype; stdcall; external 'bla.dll'  name 'myxx'; you can use a constant e.g.  Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const kernel32dll='kernel32.dll'; ---------------------------------------------------------------------- Zvoni · 2024-07-02 12:07 Quote from: marcov on July 02, 2024, 02:03:50 pmQuote from: rforcen on July 02, 2024, 01:57:09 pmYes, the mingw versión doesn't need It, I use {$linklib} not LoadLibrary('module.DLL') $linklib is for static libraries (.a). For .dll, just name them in your declarations Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function xx(parameters):resulttype; stdcall; external 'bla.dll'  name 'myxx'; you can use a constant e.g.  Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const kernel32dll='kernel32.dll'; From here: https://forum.lazarus.freepascal.org/index.php/topic,66610.0.html QuoteIn a nutshell: {$LinkLib LIBNAME} --> you need the LIBNAME.a file {$Link LIBNAME} --> you need the LIBNAME.o file In any case, your Declarations are as follows: Function SomeFunction(SomeArguments):SomeReturnType;call_convention;external; --> NO LIBNAME!! ---------------------------------------------------------------------- marcov · 2024-07-02 13:32 That is not about DLL, but static libraries. ---------------------------------------------------------------------- Zvoni · 2024-07-02 14:29 Quote from: marcov on July 02, 2024, 03:32:35 pmThat is not about DLL, but static libraries. You sure? TS is talking about trying to generate a dll, but uses linklib ---------------------------------------------------------------------- rforcen · 2024-07-02 14:35 Quote from: Zvoni on July 02, 2024, 02:07:18 pmQuote from: marcov on July 02, 2024, 02:03:50 pmQuote from: rforcen on July 02, 2024, 01:57:09 pmYes, the mingw versión doesn't need It, I use {$linklib} not LoadLibrary('module.DLL') $linklib is for static libraries (.a). For .dll, just name them in your declarations Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function xx(parameters):resulttype; stdcall; external 'bla.dll'  name 'myxx'; you can use a constant e.g.  Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i const kernel32dll='kernel32.dll'; From here: https://forum.lazarus.freepascal.org/index.php/topic,66610.0.html QuoteIn a nutshell: {$LinkLib LIBNAME} --> you need the LIBNAME.a file {$Link LIBNAME} --> you need the LIBNAME.o file In any case, your Declarations are as follows: Function SomeFunction(SomeArguments):SomeReturnType;call_convention;external; --> NO LIBNAME!! you can link dynamic libs with {$linklib dl.dll} / win in all os {$linklib dl.so} / linux {$linklib dl.dylib} / macos the problem i'm addressing is some compilers/versions are not compatible ---------------------------------------------------------------------- MarkMLl · 2024-07-03 07:39 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 · 2024-07-03 08:25 Quote from: MarkMLl on July 03, 2024, 09:39:38 amYears 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 · 2024-07-03 08:29 Quote from: Zvoni on July 02, 2024, 04:29:25 pmQuote from: marcov on July 02, 2024, 03:32:35 pmThat 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 · 2024-07-03 08:32 Quote from: marcov on July 03, 2024, 10:25:20 amFirst 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 · 2024-07-07 19:48 Quote from: rforcen on July 02, 2024, 09:11:23 ami 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 · 2024-07-07 20:25 Quote from: PascalDragon on July 07, 2024, 09:48:53 pmFPC'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 · 2024-07-07 20:32 Quote from: 440bx on July 07, 2024, 10:25:59 pmQuote from: PascalDragon on July 07, 2024, 09:48:53 pmFPC'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 · 2024-07-08 01:18 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 · 2024-07-08 07:50 in visual studio exported funcs MUST include prefix "__declspec(dllexport)  " Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i extern "C" {    __declspec(dllexport) int foo(int a, int b) { return a+b; }} in fpc as usual: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function foo(a,b:integer); cdecl; external;