Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2024-06

How to use external linker on windows i386

5 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Ondrej Pokorny

Hello,

I am on Windows 64bit, but using the i386 compiler.

I have to link a 3rd party OBJ file with {$L 'xyz.obj'}.

With the internal linker I get these errors:
Error: COMDAT selection mode 0 not supported (section: "0") Error: Failed reading coff file, invalid section index while reading xyz.obj Error: Associative COMDAT section for section ".rdata" not found

So I tried to use the external linker with -Xe and I get these errors: Linking myProgram.exe
ld: warning: directory not found for option '-L/usr/lib' ld: warning: directory not found for option '-F/System/Library/Frameworks/' ld: warning: option -b is obsolete and being ignored ld: file not found: pei-i386
Error: Error while linking

I searched for any information but couldn't find any help or tutorial how to setup the external linker.

I tried:
I downloaded the current mingw32 binaries and registered the search path with:
-Xe -XRp:\software\MinGW\mingw32\bin
But it didn't not help - still the same error.

Can anybody help please?
Delphi can link the OBJ file without problems.

Thanks
Ondrej

Reply by email

Ondrej Pokorny
to Sven Barth: Ondrej Pokorny via fpc-pascal schrieb am Do., 6. Juni 2024, 09:30: Can you provide a…
Sven Barth wrote 35 lines
Ondrej Pokorny via fpc-pascal schrieb am Do., 6. Juni 2024, 09:30: Hello, I am on Windows 64bit, but using the i386 compiler. I have to link a 3rd party OBJ file with {$L 'xyz.obj'}. With the internal linker I get these errors: Error: COMDAT selection mode 0 not supported (section: "0") Error: Failed reading coff file, invalid section index while reading xyz.obj Error: Associative COMDAT section for section ".rdata" not found Can you provide a small example as a bug report that shows this behavior (preferably also with source for the object file) so that we can improve the internal linker? So I tried to use the external linker with -Xe and I get these errors: Linking myProgram.exe ld: warning: directory not found for option '-L/usr/lib' ld: warning: directory not found for option '-F/System/Library/Frameworks/' ld: warning: option -b is obsolete and being ignored ld: file not found: pei-i386 Error: Error while linking That reads like the compiler is picking up the wrong linker (a WSL one perhaps?). The ld.exe (probably with platform prefix) should already be located in the compiler's binary directory and PATH needs to point to that first.

Thank you Sven for the help!

I changed the PATH so that the FPC bin directory is the first entry and the output indeed changed: I get only "Error: Error while linking" output without additional information that I got before.

Furthermore, I see from the docs that the -XR isn't supported on Windows (https://www.freepascal.org/docs-html/user/userap1.html) -XR<x>     Prepend <x> to all linker search paths (BeOS, Darwin, FreeBSD, Linux, Mac OS, Solaris)

Maybe it would be good to support it on Windows as well to be able to explicitly tell which linker to use.

Ondrej

Reply by email

Sven Barth
to Ondrej Pokorny: I am on Windows 64bit, but using the i386 compiler. I have to link a 3rd party OBJ file…

Ondrej Pokorny via fpc-pascal schrieb am
Do., 6. Juni 2024, 09:30:

Show quoted text 12 lines
Hello, I am on Windows 64bit, but using the i386 compiler. I have to link a 3rd party OBJ file with {$L 'xyz.obj'}. With the internal linker I get these errors: Error: COMDAT selection mode 0 not supported (section: "0") Error: Failed reading coff file, invalid section index while reading xyz.obj Error: Associative COMDAT section for section ".rdata" not found

Can you provide a small example as a bug report that shows this behavior (preferably also with source for the object file) so that we can improve the internal linker?

Show quoted text 8 lines
So I tried to use the external linker with -Xe and I get these errors: Linking myProgram.exe ld: warning: directory not found for option '-L/usr/lib' ld: warning: directory not found for option '-F/System/Library/Frameworks/' ld: warning: option -b is obsolete and being ignored ld: file not found: pei-i386 Error: Error while linking

That reads like the compiler is picking up the wrong linker (a WSL one perhaps?). The ld.exe (probably with platform prefix) should already be located in the compiler's binary directory and PATH needs to point to that first.

Regards,
Sven

Reply by email

Sven Barth
to Ondrej Pokorny: Thank you Sven for the help! I changed the PATH so that the FPC bin directory is the…

Ondrej Pokorny schrieb am Do., 6. Juni 2024, 11:56:

Show quoted text 45 lines
On 06.06.2024 11:16, Sven Barth via fpc-pascal wrote: Ondrej Pokorny via fpc-pascal schrieb am Do., 6. Juni 2024, 09:30: > Hello, > > I am on Windows 64bit, but using the i386 compiler. > > I have to link a 3rd party OBJ file with {$L 'xyz.obj'}. > > With the internal linker I get these errors: > Error: COMDAT selection mode 0 not supported (section: "0") > Error: Failed reading coff file, invalid section index while > reading xyz.obj > Error: Associative COMDAT section for section ".rdata" not found > Can you provide a small example as a bug report that shows this behavior (preferably also with source for the object file) so that we can improve the internal linker? > So I tried to use the external linker with -Xe and I get these errors: > Linking myProgram.exe > ld: warning: directory not found for option '-L/usr/lib' > ld: warning: directory not found for option > '-F/System/Library/Frameworks/' > ld: warning: option -b is obsolete and being ignored > ld: file not found: pei-i386 > Error: Error while linking > That reads like the compiler is picking up the wrong linker (a WSL one perhaps?). The ld.exe (probably with platform prefix) should already be located in the compiler's binary directory and PATH needs to point to that first. Thank you Sven for the help! I changed the PATH so that the FPC bin directory is the first entry and the output indeed changed: I get only "Error: Error while linking" output without additional information that I got before. You should probably look at the unfiltered output of the message window.

Furthermore, I see from the docs that the -XR isn't supported on Windows (

Show quoted text 7 lines
https://www.freepascal.org/docs-html/user/userap1.html) -XR<x> Prepend <x> to all linker search paths (BeOS, Darwin, FreeBSD, Linux, Mac OS, Solaris) Maybe it would be good to support it on Windows as well to be able to explicitly tell which linker to use.

-XR does not do what you think it does. It only exists for specific cross compiling issues on *nix platforms.

If you need to specify a path for the binutils you can use -FD<x>.

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth: Ondrej Pokorny via fpc-pascal schrieb am Do., 6. Juni 2024, 09:30: Can you provide a…

Sven Barth schrieb am Do., 6. Juni 2024,
11:16:

Show quoted text 20 lines
Ondrej Pokorny via fpc-pascal schrieb am Do., 6. Juni 2024, 09:30: > Hello, > > I am on Windows 64bit, but using the i386 compiler. > > I have to link a 3rd party OBJ file with {$L 'xyz.obj'}. > > With the internal linker I get these errors: > Error: COMDAT selection mode 0 not supported (section: "0") > Error: Failed reading coff file, invalid section index while > reading xyz.obj > Error: Associative COMDAT section for section ".rdata" not found > Can you provide a small example as a bug report that shows this behavior (preferably also with source for the object file) so that we can improve the internal linker?

Thanks to your privately provided example I was able to solve that (though it still won't link due to missing symbols, but that is not the linker's fault and probably also the reason why the external linker fails as well). I still don't understand why the object file contained a COMDAT field with an invalid selection of 0, but it seems that other linkers ignore that as well... 🤷‍♀️

Regards,
Sven

Reply by email