weirdness with fnmatch (linux)

[robert rozee]

hi,
    i've been developing a modification to FPC so that under linux any generated binaries link against the BASE versions of glibc symbols. this is done by adding code into the procedure pd_external (contained in the file pdecsub.pas) that intercepts references to known glibc symbols (there are around 2500 of them) and using a lookup-table substitutes the BASE version for said symbols. for instance dlopen is converted to dlopen@GLIBC_2.2.5.

this works for all bar one symbol - fnmatch. it appears that FPC internally does something mightily weird with fnmatch for reasons that are not entirely clear. are any of the FPC developers able to explain:
1. why is whatever is being done with fnmatch done?
2. what exactly is being done with fnmatch?
3. from within pd_external how can i differentiate the 'internal' fnmatch so that i can leave it well alone?

unfortunately i've not been able to discover the structure of tabstractprocdef/tprocdef which packages up the data passed into pd_external. is anyone able to:
4. show me where tabstractprocdef/tprocdef  is defined and explain (some of) the fields?


cheers,
rob   :-)

[robert rozee]

found some of the required information in /usr/share/fpcsrc/3.2.2/compiler/symdef.pas around line 786:

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

1.           { import info }
2.           import_dll,
3.           import_name : pshortstring;
4.           { info for inlining the subroutine, if this pointer is nil,
5.             the procedure can't be inlined }
6.           inlininginfo : pinlininginfo;
7. {$ifdef oldregvars}
8.           regvarinfo: pregvarinfo;
9. {$endif oldregvars}
10.           import_nr    : word;
11.           extnumber    : word;
12.           { set to a value different from tsk_none in case this procdef is for
13.             a routine that has to be internally generated by the compiler }

import_dll points to the string 'libgtk-x11-2.0.so' when the problematic fnmatch shows up and so we can skip if 'gtk' occurs within the string. extnumber may also be worth examining in future to see what significance it may have. i'm a little disappointed none of the FPC developers have offered input.

a functioning patch to implement automatic BASE versioning for all glibc symbols is posted here:
https://forum.lazarus.freepascal.org/index.php/topic,64731.0.html


cheers,
rob   :-)