On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal
<fpc-pascal@lists.freepascal.org> wrote:
> I am also able to use mingw32 gcc to compile this same C source into a static
> library for Windows using these two commands while inside the folder
> containing the Chipmunk2D sources:
>
> x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99 -ffast-math
> src/*.c -Iinclude -c
-static and -static-libgcc are linking options, so they won't do
anything here. You'll have to link libgcc in manually in your pascal
source.
> {$ifdef windows}
> {$linklib mingw32}
> {$linklib mingwex}
> {$linklib kernel32}
> {$linklib msvcrt}
> {$linklib chipmunk-win}
> {$endif}
>
> I get many errors similar to these below:
>
> Verbose: Compiling resource
> C:\Development\Projects\physics\lib\x86_64-win64\Physics.obj
> Verbose: Linking C:\Development\Pascal\Projects\physics\Physics.exe
> Physics.lpr(30,1) Error: Undefined symbol: ___chkstk_ms
> Physics.lpr(30,1) Error: Undefined symbol: __mingw_raise_matherr
> Physics.lpr(30,1) Error: Undefined symbol: __imp_WideCharToMultiByte
> Physics.lpr(30,1) Error: Undefined symbol: __imp_IsDBCSLeadByteEx
> Physics.lpr(30,1) Error: Undefined symbol: __imp_MultiByteToWideChar
> Physics.lpr(30,1) Verbose: There were 5 errors compiling module, stopping
> Verbose: Compilation aborted
The order of the linklib entries make a difference. I can get the
undefined symbols down to nothing by using this order:
{$linklib libchipmunk.a}
{$linklib libmingwex.a}
{$linklib libmingw32.a}
{$linklib libgcc.a}
//{$linklib libmsvcrt.a}
{$linklib libmsvcr120.a}
{$linklib libkernel32.a}
But then I get an internal error (200603061). It may be down to the
toolchain/libraries I used (recent msys2 x64), which would be a lot
newer than fpc (I should really try to package it for msys2 when I
have some free time).
Henry
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
