Sign in Join

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

Mailing lists / fpc-pascal / 2021-06

Linker error on simple program (windows)

4 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

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

Bart

Given this unit:

unit ExtMath;
{$mode objfpc}
interface
function LeadingZeroBits(n: Byte): Integer; inline;
implementation
function LeadingZeroBits(n: QWORD; BitSize: Integer): Integer;
begin
  Result := 0;
end;
function LeadingZeroBits(n: Byte): Integer;
begin
  Result := LeadingZeroBits(QWORD(n), SizeOf(Byte)*8);
end;
end.

and this program

program test;
{$mode ObjFPC}
uses
  Extmath;
var
  b: byte;
  L: Integer;
begin
  b := 0;
  L := LeadingZeroBits(b);
end.

On Windows this won't build with 3.2.2 or 3.2.0.
It will build with 3.0.4.

C:\Users\Bart\LazarusProjecten\bugs\Console\linkerror>fpc test.pas Free Pascal Compiler version 3.2.2 [2021/05/15] for i386 Copyright (c) 1993-2021 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling test.pas
Compiling extmath.pp
test.pas(9,3) Note: Local variable "L" is assigned but never used Linking test.exe
test.pas(13,1) Error: Undefined symbol:
EXTMATH_::=::\_LEADINGZEROBITS$QWORD$LONGINT::=::\LONGINT test.pas(13,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: C:\devel\fpc\3.2.2\bin\i386-win32\ppc386.exe returned an error exitcode

The error goes away if I remove the inline directive from the function definition in the interface section, or if I also declare the other function (which gives the linker error) in the interface section.

Bart

Reply by email

Sven Barth
to Bart

Bart via fpc-pascal schrieb am Mi., 23.
Juni 2021, 18:59:

The error goes away if I remove the inline directive from the function definition in the interface section, or if I also declare the other function (which gives the linker error) in the interface section.

The compiler shouldn't do the inlining in that case, cause the pre-3.3.1 compiler doesn't allow inlining of implementation-only functions (and that was something that was indeed fixed in 3.2.0: the overload that's not declared in the interface section is no longer available globally).

3.3.1 handles inlining of implementation-only functions correctly.

Thus for 3.2.0 and 3.2.2 you indeed need to use the workarounds you mentioned.

Regards,
Sven

Reply by email

Bart
AM Sven Barth wrote
Thus for 3.2.0 and 3.2.2 you indeed need to use the workarounds you mentioned.

Not a problem.
It just surprised me.

Will this be fixed in 3.2.4?
(The linker error is a bug IMO, compilation should have failed with a sensible message)

Bart -- Bart

Reply by email

Sven Barth
to Bart
Bart wrote 7 lines
On Thu, Jun 24, 2021 at 11:10 AM Sven Barth wrote: > Thus for 3.2.0 and 3.2.2 you indeed need to use the workarounds you mentioned. Not a problem. It just surprised me. Will this be fixed in 3.2.4?

It's not even sure if there will be a 3.2.4 with the migration to Git.

(The linker error is a bug IMO, compilation should have failed with a sensible message)

No, the linker error is not a bug, that is exactly what should happen given the symptoms. What should have happened is that the compiler does not inline the function, because the overload is not reachable from outside.

Regards,
Sven

Reply by email