Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
Le 22/08/2022 à 18:18, Henry Vermaak via fpc-pascal a écrit : On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal 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. You can always pass option to the external linker using '-k' option: Use -k-static (without space) or -k-lc or -k-L -k/DIR/ It can be good to use 'vx' option to see what is the command line really generated by the Free Pascal compiler when calling the external linker. Pierre ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal
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
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
Hi, On Mon, 22 Aug 2022, Anthony Walter via fpc-pascal wrote: > I know in the past I had been able to compile / link libraries created > with MinGW GCC on Windows. Parts of the problem also include determining > which other static dependencies to link IN ADDITION to the order of the > linking. Yes, the order makes a big difference. Indeed, that is true. But if the linking order worked on Linux, it should work on Windows too, I think. > Unfortunately, many years ago (around 10) I lost or overwrote the bits > of code I was using for static linking on Windows (using the correct > linklib commands). Please note that 10 years ago FPC might not have had an internal linker, or it might not have been the default one on Windows. :) So this might be the missing bit of info why it worked back then. > I will try to recreate it again, using your suggestion of falling back > to the external linker. If it works I'll send you a part of the reward. Thanks, but it is not necessary. If it works, and you still would like to send money, donate it to any charity of your choice instead. Charlie___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
Marco, The missing symbols change depending on the order and which libraries are referenced. But I have tried all sorts of combinations and widdled them down, but I can never get it to compile. I think it might be a problem with the internal linker as Karoly suggested because sometimes I can almost get it working and then when it's about to work I get a mysterious internal linking error message. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
On 22-8-2022 15:01, Anthony Walter via fpc-pascal wrote: I never thought about the linker changes to FPC and am probably using the internal one. I know in the past I had been able to compile / link libraries created with MinGW GCC on Windows. Parts of the problem also include determining which other static dependencies to link IN ADDITION to the order of the linking. Yes, the order makes a big difference. Unfortunately, many years ago (around 10) I lost or overwrote the bits of code I was using for static linking on Windows (using the correct linklib commands). I will try to recreate it again, using your suggestion of falling back to the external linker. If it works I'll send you a part of the reward. That offer also stands for anyone else that can offer helpful advice. Do the "inp" symbols go away if you put the kernel32 dependency first ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
I never thought about the linker changes to FPC and am probably using the internal one. I know in the past I had been able to compile / link libraries created with MinGW GCC on Windows. Parts of the problem also include determining which other static dependencies to link IN ADDITION to the order of the linking. Yes, the order makes a big difference. Unfortunately, many years ago (around 10) I lost or overwrote the bits of code I was using for static linking on Windows (using the correct linklib commands). I will try to recreate it again, using your suggestion of falling back to the external linker. If it works I'll send you a part of the reward. That offer also stands for anyone else that can offer helpful advice. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
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
