gives me exactly the same error, I mean, aren't gcc DLLs compatible with FreePascal?
Mingw64 alone comes in
4! incompatible versions (POSIX and native threads, SEH and setjmp exceptions), and then there are msys and cygwin builds. One binary distribution of FPC can't be compatible with all at the same time. I would expect the native threads SEH version of mingw64 to be the most compatible.
A msvcrt version might even be better.
FPC is compatible with windows dlls. We even try to be compatible to the most common gcc derivatives on windows, the ones to build postgres, mysql clientlibs etc. Those work fine. SDL was always "special", see also below.
But mingw64 dlls can be constructed in many ways, and some might assume the main program also to be mingw compiled (and mingw runtime based). That will of course not work.
(I btw see "cyg" in the errors in your error output. Are you sure there are no mixups?)
How do you interact with an external lib then?
Also, is FreePascal compatible with MSVC compiler generated DLLs?
Same story.
Thing is, I have a big C project, it uses SDL2 as a backend, compiles and runs fine in Windows and Linux, my idea is to convert that project into a lib and continue development in Pascal, calling functionality from that lib, I think that won't be possible, but I've been in this scenario earlier with another project and it worked, something is broken around this and I don't know what it is...
We can't help you about that. What I do know is that in general you need to select the mingw/gcc toolchains that are the MOST windows like, and don't try to emulate *nix on Windows. For additional details, maybe it is best to ask on a ming64 list what the error means, and in general what issues SDL has on Windows. That error is not in FPC compiled code or general linking knowledge. It is mingw64 (flavour?) and possibly SDL specific.
I worked with SDL myself in the 2007 timeframe myself, and then it was also a trainwreck. They use every dirty trick in the book, including trying to wrap main() using an owner SDL_MAIN wrapper. That might also have something to do with it. The problem is that way it isn't a library, but a framework.
SDL on-windows itself might also have build options. Doing a custom build and disabling as much as possible of the integration at the expense of having to do some extra calls (SDL_INIT?) could also be a way forward.
As for the difference between external name and the external; {$linklib: as said the difference is who creates the so called import lib, which are the tables to load the dll on startup that go into the exe. The file you $linklib is generated by mingw, with the "external name", fpc generates them on the fly (and you shouldn't $linklib)