Hi,
On Sun, 21 Aug 2022, Anthony Walter via fpc-pascal wrote:
> I will pay $100 to the first person that can solve my problem of linking
> a compiled C static library to a Free Pascal program on Windows.
I'm not an expert for FPC on Windows by any meanns, but I think I've ran
into the problems you're having.
> {$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
Err, sorry for the trivial question, but are you using the internal or an
external linker? From the error messages, I assume you use the internal
one. On Windows FPC now defaults to its internal linker, which as known
difficulties linking against some C libraries. Which is solvable, but
probably not subject of a $100 bounty, but a bigger piece of work.
Wouldn't simply using GNU LD as an external linker (-Xe argument, IIRC)
would solve this problem? Note that the external linker is known to
produce larger executables, because it's not that good in removing unused
pieces of code as the internal linker. But at least you could get
something built.
Charlie_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
