FPC 3.2.2 / Lazarus 2.2.6 patch for GLIBC_2.34 versioning issue

[robert rozee]

i think i've eliminated the versions of fnmatch in
/usr/share/fpcsrc/3.2.2/packages/unixutil/src/unixutils.pp
and
/usr/share/fpcsrc/3.2.2/rtl/unix/sysutils.pp

while there is a fair bit of traffic passing through the fnmatch function in sysutils, the point at which a project build fails appears to be elsewhere; doing a compare of trace logs of the function shows identical input and output prior to the point of failure. the code added to the fnmatch function to capture the trace was:

Code: Pascal  [Select][+][-]

1. { assumes that pattern and name have the same code page }
2. Function FNMatch(const Pattern,Name:string):Boolean;
3. //////////
4. // internal functions clipped out, see fnmatch in file /usr/share/fpcsrc/3.2.2/rtl/unix/sysutils.pp for full code
5. //////////
6. var S:string[64];
7.     T:text;
8.     B:boolean;
9.  
10. Begin {start FNMatch}
11. /////////////////////////////////////////////////////////////////////////////
12.             S:='/tmp/matches.txt';                
13.             Assign(T, S);                                
14.             if not FileExists(S) then Rewrite(T)
15.                                  else Append(T);
16. /////////////////////////////////////////////////////////////////////////////
17.   LenPat:=Length(Pattern);
18.   LenName:=Length(Name);
19. //FNMatch:=DoFNMatch(1,1);          
20.  
21. /////////////////////////////////////////////////////////////////////////////
22.             B:=DoFNMatch(1,1);
23.             FNMatch:=B;
24.             if B then S:='MATCH'
25.                  else S:='false';
26.             writeln(T, paramstr(0), ' : ', pattern, ' - ', name, ' = ', S);
27.             Close(T);
28. /////////////////////////////////////////////////////////////////////////////
29. End;

btw, below is the output of lazbuild when building a project (with fnmatch versioned to fnmatch@GLIBC_2.2.5) fails. things go off the rails at around line 67/68:

Code: Text  [Select][+][-]

1. user@Mint21:~/Desktop/clock2$ lazbuild project1.lpr --verbose --verbose --verbose
2. Hint: (lazarus) primary config path: /home/user/.lazarus
3. Hint: [TPCTargetConfigCache.NeedsUpdate] TargetOS="" TargetCPU="" Options="" compiler file changed "/usr/bin/fpc" FileAge=1697277096 StoredAge=1695728491
4. Hint: [TPCTargetConfigCache.NeedsUpdate] /usr/bin/fpc TargetOS= TargetCPU= CompilerOptions= ExtraOptions= PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
5. Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-iWTOTP"
6. Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-va" "compilertest.pas"
7. Hint: [TPCTargetConfigCache.Update] has changed
8. Hint: [TPCTargetConfigCache.NeedsUpdate] TargetOS="linux" TargetCPU="x86_64" Options="" compiler file changed "/usr/bin/fpc" FileAge=1697277096 StoredAge=1695728491
9. Hint: [TPCTargetConfigCache.NeedsUpdate] /usr/bin/fpc TargetOS=linux TargetCPU=x86_64 CompilerOptions= ExtraOptions= PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
10. Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-iWTOTP" "-Px86_64" "-Tlinux"
11. Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-va" "compilertest.pas" "-Px86_64" "-Tlinux"
12. Hint: [TPCTargetConfigCache.Update] has changed
13. Hint: (lazarus) [TBuildManager.SetBuildTarget] OS=linux CPU=x86_64 CompQueryOptions= DefaultOS=linux DefaultCPU=x86_64
14. Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=x86_64-linux-gtk2 New=x86_64-linux-gtk2 Changed: OS/CPU=True LCL=False
15. Hint: (lazarus) [TBuildManager.SetBuildTarget] OS=linux CPU=x86_64 CompQueryOptions= DefaultOS=linux DefaultCPU=x86_64
16. Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=x86_64-linux-gtk2 New=x86_64-linux-gtk2 Changed: OS/CPU=True LCL=False
17. Hint: (lazarus) package FCL 1.0.1 was compiled via "make" with parameters " -Fu.  -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq fcllaz.pas"
18. Hint: (lazarus) package LazUtils 1.0 was compiled via "make" with parameters " -Fu../../packager/units/x86_64-linux;.  -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq lazutils.pas"
19. Hint: (lazarus) package freetypelaz 1.0 was compiled via "make" with parameters " -Fu../../packager/units/x86_64-linux;../lazutils/lib/x86_64-linux;.  -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq freetypelaz.pas"
20. Hint: (lazarus) package LCLBase 2.2.6 was compiled via "make" with parameters " -Fuforms;widgetset;nonwin32;../packager/units/x86_64-linux;../components/lazutils/lib/x86_64-linux;../components/freetype/lib/x86_64-linux;. -Fiinclude  -MObjFPC -Scghi -O1 -g -gl -vew -l alllclunits.pp"
21. Hint: (lazarus) package LCL 2.2.6 was compiled via "make" with parameters " -MObjFPC -Scghi -O1 -g -gl -vewnhi -l -Fugtk2;../../packager/units/x86_64-linux;../../components/lazutils/lib/x86_64-linux;../../components/freetype/lib/x86_64-linux;../units/x86_64-linux;. -Figtk2 lcl.pas"
22. Hint: (lazarus) Project needs building: Compiler file changed for Project
23.   File="/usr/bin/fpc"
24. TCompiler.Compile WorkingDir="/home/user/Desktop/clock2/" CompilerFilename="/usr/bin/fpc" CompilerParams=" -MObjFPC -Scghi -CX -Cg -O3 -XX -l -vewnhibq -Fi/home/user/Desktop/clock2/lib/x86_64-linux -Fu/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2 -Fu/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux -Fu/usr/share/lazarus/2.2.6/components/freetype/lib/x86_64-linux -Fu/usr/share/lazarus/2.2.6/components/lazutils/lib/x86_64-linux -Fu/usr/share/lazarus/2.2.6/packager/units/x86_64-linux -Fu/home/user/Desktop/clock2/ -FU/home/user/Desktop/clock2/lib/x86_64-linux/ -FE/home/user/Desktop/clock2/ -o/home/user/Desktop/clock2/project1 -dLCL -dLCLgtk2 project1.lpr"
25. [TCompiler.Compile] CmdLine="/usr/bin/fpc -B  -MObjFPC -Scghi -CX -Cg -O3 -XX -l -vewnhibq -Fi/home/user/Desktop/clock2/lib/x86_64-linux -Fu/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2 -Fu/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux -Fu/usr/share/lazarus/2.2.6/components/freetype/lib/x86_64-linux -Fu/usr/share/lazarus/2.2.6/components/lazutils/lib/x86_64-linux -Fu/usr/share/lazarus/2.2.6/packager/units/x86_64-linux -Fu/home/user/Desktop/clock2/ -FU/home/user/Desktop/clock2/lib/x86_64-linux/ -FE/home/user/Desktop/clock2/ -o/home/user/Desktop/clock2/project1 -dLCL -dLCLgtk2 project1.lpr"
26. Hint: (lazarus) TBuildManager.MacroFuncInstantFPCCache /usr/bin/instantfpc
27. Hint: (lazarus) [RunTool] "/usr/bin/instantfpc" "--get-cache"
28. Hint: (lazarus) [TBuildManager.MacroFuncInstantFPCCache] /home/user/.cache/instantfpc/
29. Info: (lazarus) Execute Title="Compile Project, Target: project1"
30. Info: (lazarus) Working Directory="/home/user/Desktop/clock2/"
31. Info: (lazarus) Executable="/usr/bin/fpc"
32. Info: (lazarus) Param[0]="-B"
33. Info: (lazarus) Param[1]="-MObjFPC"
34. Info: (lazarus) Param[2]="-Scghi"
35. Info: (lazarus) Param[3]="-CX"
36. Info: (lazarus) Param[4]="-Cg"
37. Info: (lazarus) Param[5]="-O3"
38. Info: (lazarus) Param[6]="-XX"
39. Info: (lazarus) Param[7]="-l"
40. Info: (lazarus) Param[8]="-vewnhibq"
41. Info: (lazarus) Param[9]="-Fi/home/user/Desktop/clock2/lib/x86_64-linux"
42. Info: (lazarus) Param[10]="-Fu/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2"
43. Info: (lazarus) Param[11]="-Fu/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux"
44. Info: (lazarus) Param[12]="-Fu/usr/share/lazarus/2.2.6/components/freetype/lib/x86_64-linux"
45. Info: (lazarus) Param[13]="-Fu/usr/share/lazarus/2.2.6/components/lazutils/lib/x86_64-linux"
46. Info: (lazarus) Param[14]="-Fu/usr/share/lazarus/2.2.6/packager/units/x86_64-linux"
47. Info: (lazarus) Param[15]="-Fu/home/user/Desktop/clock2/"
48. Info: (lazarus) Param[16]="-FU/home/user/Desktop/clock2/lib/x86_64-linux/"
49. Info: (lazarus) Param[17]="-FE/home/user/Desktop/clock2/"
50. Info: (lazarus) Param[18]="-o/home/user/Desktop/clock2/project1"
51. Info: (lazarus) Param[19]="-dLCL"
52. Info: (lazarus) Param[20]="-dLCLgtk2"
53. Info: (lazarus) Param[21]="project1.lpr"
54. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
55. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
56. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
57. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
58. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
59. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
60. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
61. Hint: (11030) Start of reading config file /etc/fpc.cfg
62. Hint: (11031) End of reading config file /etc/fpc.cfg
63. Free Pascal Compiler version 3.2.2 [2023/10/14] for x86_64
64. Copyright (c) 1993-2021 by Florian Klaempfl and others
65. (1002) Target OS: Linux for x86-64
66. (3104) Compiling project1.lpr
67. (10001) PPU Loading /usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2/gtk2int.ppu
68. (10011) PPU Source: gtk2int.pas not found
69. (10011) PPU Source: gtk2defines.inc not available
70. (10011) PPU Source: gtk2winapih.inc not available
71. (10011) PPU Source: gtk2lclintfh.inc not available
72. (10011) PPU Source: gtk2listslh.inc not available
73. (10011) PPU Source: gtk2widgetset.inc not available
74. (10011) PPU Source: gtk2winapi.inc not available
75. (10011) PPU Source: gtk2lclintf.inc not available
76. (10011) PPU Source: gtk2listsl.inc not available
77. (10028) Recompiling Gtk2Int, checksum changed for /usr/lib/fpc/3.2.2/units/x86_64-linux/gtk2/gtk2.ppu
78. /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
79. Fatal: (1018) Compilation aborted
80. Error: /usr/bin/ppcx64 returned an error exitcode
81. TExternalToolsConsole.HandleMesages: Calling CheckSynchronize!
82. Error: (lazarus) Compile Project, Target: project1: stopped with exit code 1
83. [TCompiler.Compile] end
84. Error: (lazbuild) failed compiling of project /home/user/Desktop/clock2/project1.lpi
85. user@Mint21:~/Desktop/clock2$
86. user@Mint21:~/Desktop/clock2$
87.  

i am at a loss as to how to proceed. if someone could suggest where in the compiler's source the error codes 10011 come from...


cheers,
rob   :-)

[TRon]

i am at a loss as to how to proceed. if someone could suggest where in the compiler's source the error codes 10011 come from...

The 10011 codes that you refer to as error codes aren't actually error codes but informational messages.

It seem that the compiler tries to inform you that the directory where the includes files are located is not known. That is more a configuration issue.

More problematic is the 10022 code that you received (also related to configuration) where the compiler is unable to locate the source-file for unit gtk2int. The compiler has at least detected that something is off for unit gtk2int and therefor tries to recompile the unit in an attempt to 'fix' the units that was updated.

I usually use FPC parameter option -va to show all relevant details for a build but you could probably get by with using the parameter option -vt in order to show all files/directories the compiler tried (in order to determine which directory is misconfigured (if any) or plain missing from your configuration).

fwiw: I am still puzzled with your results regarding fnmatch and libc. As I showed in my previous response none of the elf-files that are present (both fpc and lazarus) have any reference to it, ergo this is not compiled in (despite what you may think the source-code is telling you). All fnmatch libc references are either not for linux/unix target or only present when used explicitly by unit unixutil. So, it is currently beyond me how you are able to trigger its use. The present ELF files are riddled with sysutils (pascal) implementation of fnmatch though. Perhaps I need to carefully re-read the thread...

[WayneSherman]

...with fnmatch versioned to fnmatch@GLIBC_2.2.5 fails
i am at a loss as to how to proceed.

GLIBC 2.2.5 was released in 2002 [edited / fixed]
https://sourceware.org/glibc/wiki/Glibc%20Timeline

(EDITED)
Has fnmatch had an ABI change since GLIBC_2.2.5?
Checking GLIBC 2.37 there is only one ABI version reported:

Code: [Select]

readelf --dyn-syms -W /lib/libc.so.6 | grep fnmatch
   802: 00000000000ddab0   411 FUNC    GLOBAL DEFAULT   15 fnmatch@@GLIBC_2.2.5
For visibility into which external functions have name changes, can debug code be added in to output the import_name, file name, and line number?:

Code: Pascal  [Select][+][-]

1. if sym_name=gf.Name then
2. begin
3.   stringdispose(import_name);                       // dispose of unversioned symbol name
4.   import_name:=stringdup(gf.Name+'@'+gf.Version);   // replace with versioned symbol name
5.   //add debug output here to report 'GLIBC_Symbol_Versioning',import_name, source_file_name, source_file_line_number
6.   break;
7. end;

[robert rozee]

For visibility into which external functions have name changes, can debug code be added in to output the sym_name, file name, and line number?:

Code: Pascal  [Select][+][-]

1. if sym_name=gf.Name then
2. begin
3.   stringdispose(import_name);                       // dispose of unversioned symbol name
4.   import_name:=stringdup(gf.Name+'@'+gf.Version);   // replace with versioned symbol name
5.   //add debug output here to report 'GLIBC_Symbol_Versioning',import_name, source_file_name, source_file_line_number
6.   break;
7. end;

i'm actually using the patch as i originally posted, not DonAlfredo's version. but the result should be the same.

the data structure that holds the key information, pd from procedure pd_external(pd:tabstractprocdef);... is entirely opaque, with import_name and import_dll being the only fields i have knowledge of. there may be (indeed, almost certainly are) fields containing more clues as to where a symbol is coming from - such as file currently being compiled and source line numbers - but i need the FPC developers to release this information. to date, they appear to have refused to help in any way. my own 'development environment' is limited to a just simple text editor and Fred vS's 4-line bash script to rebuild everything.

I usually use FPC parameter option -va to show all relevant details for a build

i'm using lazbuild, which does not directly support -va.

bear in mind that the compiler is being deprived of access to the unversioned fnmatch, instead being given fnmatch@GLIBC_2.2.5. this is what lies behind the errors. it is not a configuration file error. there is almost certainly nothing wrong with gtk2int, but rather with the compiler needing to make use of whatever the unversioned fnmatch resolves to.

to date, we have no idea where the unversioned fnmatch lands. well, slight correction,we do know it doesn't land in libc/glibc! and if it does land in an external library, then the means by which it gets there is extremely well obscured!


cheers,
rob   :-)

[WayneSherman]

The data structure that holds the key information, pd from procedure pd_external(pd:tabstractprocdef);... is entirely opaque...there may be (indeed, almost certainly are) fields containing more clues as to where a symbol is coming from - such as file currently being compiled and source line numbers

(NOTE: chatGPT responses below are untested and unverified)

Asking chatGPT: "In the fpc compiler file pdecsub.pas, I want to add code to the procedure pd_syscall.  For debugging purposes I want to output the current source code file and line number being processed.  How do I output this?"

Answer was longer, but to summarize:

In the context of Free Pascal Compiler (FPC), the information about the current source file and line number is usually available in the global current_filepos record, which typically contains fields like file, line, and column.

Code: Pascal  [Select][+][-]

1. procedure pd_syscall;
2. begin
3.   { ... existing code ... }
4.  
5.   { Debug output }
6.   writeln('Processing file: ', current_filepos.file, ' at line: ', current_filepos.line);
7.  
8.   { ... existing code ... }
9. end;

Asked: "there is a procedure named "message" which appears to help output compiler information.  Where is this defined and does it output the current source file and line number?"

Answer:

The message procedure usually comes in several overloaded variants, allowing for different types of messages and formats. One of these variants usually takes a message identifier (often an enumerated value) which determines the specific message to be shown. Some of these messages might include placeholders for additional data, such as file names, line numbers, etc.

To output a message with the current file and line number, you can use the message procedure combined with the appropriate message identifier and make use of the current_filepos record for file and line information. However, many of the message routines automatically include file and line information based on the context.  Here's a conceptual example:

Code: Pascal  [Select][+][-]

1. message1(file_e_some_error, current_filepos.file^);

In this hypothetical example, file_e_some_error might be a message identifier that corresponds to a message like "Error in file %s". The %s is a placeholder that would be replaced by the value provided by current_filepos.file^. To determine the exact format, parameters, and identifiers you need, you'd have to refer to the definition.  Do note that using the message procedure in the compiler can impact the user experience because these messages are meant to inform the user about compilation issues. If you're using it for debugging purposes, you'd ideally want to remove or comment out these messages once you're done debugging.

[WayneSherman]

(NOTE: chatGPT responses below are untested and unverified)

So chatGPT responses pointed in the right direction, but the details were not entirely correct.

globals.pas (which is in the uses of pdecsub.pas), has global variable:

Code: Pascal  [Select][+][-]

1.        current_filepos : tfileposinfo;    { current position }  //line

globtype defines

Code: Pascal  [Select][+][-]

1. tfileposinfo = record
2.   { if types of column or fileindex are changed, modify tcompilerppufile.putposinfo }
3.   line      : tfileposline;
4.   column    : tfileposcolumn;
5.   fileindex : tfileposfileindex;
6.   moduleindex : tfileposmoduleindex;
7. end;

verbose.pas defines some message procedures

[WayneSherman]

This isn't quite what I want, but after more searching around fpc compiler sources, maybe this will at least output a message with filename and line number and the import name:

Code: Pascal  [Select][+][-]

1. MessagePos1(current_filepos, sym_w_experimental_symbol, import_name);

EDIT: I also found the globals.pas has parser_current_file : string
(which I think is the filename of the currently parsed file)

EDIT2: the verbose.pas procedure "Comment" appears to be more generic:

Code: Pascal  [Select][+][-]

1. Comment(V_Note,'output this comment as a compiler message');

EDIT3: Better use V_Note for the verbose level (debug level verbosity is probably not set so the message would not be shown if using V_Debug)

[WayneSherman]

BTW, I was having trouble finding where the GLIBC source files define the mapping for symbol versions (specifically for Linux x86_64).  I discovered that instead of using map files directly, they use "*.abilist" files which get transformed into map files and fed to the linker when generating *.so files.  (I also see many "Versions" map files scattered throughout the source, I don't know why)

GLIBC symbol versioning declarations for Linux x86_64:
https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/unix/sysv/linux/x86_64/64
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/64/libc.abilist

[WayneSherman]

To @myself and @other interested.
Included a better and more complete patch for versioned linking using the new -XLC compiler option.

For a patch or merge request to be accepted does it have to be based on fpc trunk (main / head)?  I had to do some minor rework to get it to apply to the most recent trunk.  fpc builds without errors, but I haven't tested it.

https://gitlab.com/waynesherman/fpc-source/-/compare/main...glibc_versioning_donalf?from_project_id=28644964

[TRon]

For a patch or merge request to be accepted does it have to be based on fpc trunk (main / head)?

For new features, yes.

[WayneSherman]

i'm actually using the patch as i originally posted, not DonAlfredo's version. but the result should be the same.

I took your code and applied it to a new branch based off a recent fpc main commit.  It builds, but I did not test it.  I put the "basesyms.map" file in the compiler directory with pdecsub.pas, but the code that loads it doesn't specify a path (at the moment) so the compiler will not find the map file at run time.

https://gitlab.com/waynesherman/fpc-source/-/compare/main...glibc_versioning_rrozee?from_project_id=28644964

[TRon]

I put the "basesyms.map" file in the compiler directory with pdecsub.pas, but the code that loads it doesn't specify a path (at the moment) so I don't know if it will find it.

Besides using a hardcoded path or expecting a dedicated location and meant as a suggestion, you can use something like GetEnvironmentVariable to make the path configurable in a quick (simple) manner.

[robert rozee]

globals.pas (which is in the uses of pdecsub.pas)...

brilliant! within globals.pas there is a string variable called inputfilename that holds the name of the source file currently being compiled. tinkering with my debug output code in pd_external:

Code: Pascal  [Select][+][-]

1.                                                                // DEBUG: the build script supresses some console output,
2.             temp:=GetTempDir+'symbols.txt';                    // so the below lines are to capture ALL versioning into
3.             Assign(T, temp);                                   // a file in the tmp directory.
4.             if not FileExists(temp) then Rewrite(T)
5.                                     else Append(T);
6.             writeln(T, inputfilename, '    "', sym_name, '" >> "', ver_name, '"');
7.             if assigned(import_dll) then writeln(T, 'DLL = ', import_dll^);
8.             Close(T)

... yields the following debug information:

Code: Text  [Select][+][-]

1. buildgtk2.pp    "fnmatch" >> "fnmatch@GLIBC_2.2.5"
2. DLL = libgtk-x11-2.0.so

buildgtk2.pp refers to /usr/share/fpcsrc/3.2.2/packages/gtk2/src/buildgtk2.pp which contains very little, but digging into the units it includes ends up at:

/usr/share/fpcsrc/3.2.2/packages/gtk2/src/gtk+/gtk/fnmatch.pas
and the code:

Code: Pascal  [Select][+][-]

1. { Match STRING against the filename pattern PATTERN,
2.    returning zero if it matches, FNM_NOMATCH if not.   }
3. function fnmatch(__pattern: char; __string: char;
4.   __flags: gint): gint; cdecl; external gtklib;

i believe this is where the errant fnmatch symbol is coming from. but alas, i'm still no closer to figuring out where it lands!


cheers,
rob   :-)

[robert rozee]

/usr/share/fpcsrc/3.2.2/packages/gtk2/src/gtk+/gtk/fnmatch.pas
and the code:

Code: Pascal  [Select][+][-]

1. { Match STRING against the filename pattern PATTERN,
2.    returning zero if it matches, FNM_NOMATCH if not.   }
3. function fnmatch(__pattern: char; __string: char;
4.   __flags: gint): gint; cdecl; external gtklib;

indeed, commenting out lines 3 and 4 above in /usr/share/fpcsrc/3.2.2/packages/gtk2/src/gtk+/gtk/fnmatch.pas yields a successful build using Fred vS's bash script, but a subsequent inability to build a GUI application.


cheers,
rob   :-)

[robert rozee]

/usr/share/fpcsrc/3.2.2/packages/gtk2/src/gtk+/gtk/fnmatch.pas
and the code:

Code: Pascal  [Select][+][-]

1. { Match STRING against the filename pattern PATTERN,
2.    returning zero if it matches, FNM_NOMATCH if not.   }
3. function fnmatch(__pattern: char; __string: char;
4.   __flags: gint): gint; cdecl; external gtklib;

thanks to assistance from Mattias Gaertner on the fpc-devel mailing list, the fnmatch mystery/problem has been cracked!

the procedure is as follows...

1. edit fnmatch.inc to remove the reference to gtklib:

Code: Pascal  [Select][+][-]

1. { Match STRING against the filename pattern PATTERN,
2.    returning zero if it matches, FNM_NOMATCH if not.   }
3. function fnmatch(__pattern: char; __string: char;
4.   __flags: gint): gint; cdecl; external; // gtklib;

2. (if desired) patch pdecsub.pas as required so that pd_external() converts unversioned libc symbols into BASE versioned symbols. in my version of the patch (see first posting in this thread), you can now delete or comment out (as shown below) the three lines in the patched file pdecsub.pas:

Code: Pascal  [Select][+][-]

1. //      if assigned(import_dll) then temp:=import_dll^
2. //                              else temp:='';
3. //      if pos('GTK', upcase(temp))=0 then

DonAlfredo's version may require editing in another way, or could be left unchanged.

2A. ADDENDUM: create a symlink from libdl.so to libdl.so.2 using:

Code: Bash  [Select][+][-]

1. sudo ln -s /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libdl.so

the above symlink is really important to ensure libdl.so.2 is correctly referenced in future ELF headers

3. rebuild FPC using Fred vS's script (run as root using sudo), that has been placed in /usr/share/fpcsrc/3.2.2:

Code: Bash  [Select][+][-]

1. #!/bin/bash
2. if (( $EUID != 0 )); then
3.     echo "Please run as root"; exit
4. fi
5. time (
6. COMPILER=fpc
7. make clean
8. make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
9. make FPC=$COMPILER install INSTALL_PREFIX=/usr/
10. )

4. rebuild Lazarus using the below script (run as root using sudo), created with Mattias Gaertner's help:

Code: Bash  [Select][+][-]

1. #!/bin/bash
2. if (( $EUID != 0 )); then
3.     echo "Please run as root"; exit
4. fi
5. time (
6. make distclean bigide
7. )

the result should be a fully functioning FPC and Lazarus, with the fnmatch anomaly fixed and BASE versioned glibc symbols so your compiled applications will run against ANY glibc version.


cheers,
rob   :-)