[fpc-devel] fnmatch (linux), where is the external

[Marco van de Voort]

Op 17-10-2023 om 13:17 schreef robert rozee via fpc-devel:
> Date: Tue, 17 Oct 2023 09:32:16 +0200
> From: Marco van de Voort <fpc at pascalprogramming.org>
>> - without the patches you are reviewing it works all fine, suggesting a
>> problem in those patches that somehow forces linking to the symbol
>> without it being used.
>
> and installed the three packages (fpc-laz, fpc-src, lazarus-project) as per instructions. this gives a completely unpatch, unadulterated 64-bit Linux, running a completely unpatch, unadulterated FPC and Lazarus.

And that works.

> (1002) Target OS: Linux for x86-64
> (3104) Compiling project1.lpr
> (10001) PPU Loading /usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2/gtk2int.ppu
> (10011) PPU Source: gtk2int.pas not found
> (10011) PPU Source: gtk2defines.inc not available
> (10011) PPU Source: gtk2winapih.inc not available
> (10011) PPU Source: gtk2lclintfh.inc not available
> (10011) PPU Source: gtk2listslh.inc not available
> (10011) PPU Source: gtk2widgetset.inc not available
> (10011) PPU Source: gtk2winapi.inc not available
> (10011) PPU Source: gtk2lclintf.inc not available
> (10011) PPU Source: gtk2listsl.inc not available
> (10028) Recompiling Gtk2Int, checksum changed for /usr/lib/fpc/3.2.2/units/x86_64-linux/gtk2/gtk2.ppu
> /usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2/gtk2int.ppu:gtk2int.pas(14,36) Fatal: (10022) Can't find unit Gtk2Int used by Interfaces

This is not a linking error or mis-resolved symbol or something similar. 
It is about incrementally rebuilding the LCL automatically as a 
dependency of your project after

(1) installing a new compiler, possibly erasing a release (-Ur) compiler 
with one that isn't.

(2) modifying LCL source.

Which is not _that_ surprising as you leave a lot of state behind from 
your earlier compilation. A Lazarus developer might give you some tips 
on that how to do this more systematic.  I usually first build lazarus 
with make bigide and then with lazbuild (to reenable packages) after 
such mods.

Another, simpler thing might be to simply erase all .o and .ppu from the 
lazarus repo before doing the lazbuild. That erases state (that 
hopefully will then be rebuilt in a consistent way by lazbuild)

> reversing the edit, rebuilding the compiler, RTL, etc, and now when run lazbuild reports:

This seems to indicate the cause of the state problem is the source 
modification rather than the compiler recompile. Which is logical since 
it invalidates the RTL.