using musl-libc instead of glibc

[robert rozee]

No, we don't want something like that. The issue can be easily fixed by compiling on a system with the suitable version of the libary instead of implemting some frickle scheme.

google tells me that "A frickle is a fried pickle originating in America's south but now seen on the menus of hip urban pubs and cafes in Australia and New Zealand. Our modern interpretation of this addictive snack is accompanied by a sriracha (Vietnamese chilli sauce) spiked mayonnaise". although i'm not quite sure you mean this - can you please clarify your use of the term? also, who is the 'we' you mean in "we don't want something like that"? in this country, New Zealand, 'we' refers to the sitting monarch. again, this might mean something different where you live. please clarify.

users of FPC/Lazarus seem to have been searching for a solution to the 'libc problem' for years, and this seems to be one that operates entirely within how glibc's authors intended. glibc contains multiple versions of symbols to cater for this very situation, and FPC is quite conservative in the use of libc features. if it were a problem due to FPC doing something 'weird' under the hood, then FPC would surely be designed to refuse to compile unless a minimum compatible version of libc was detected?

And what if the user does not want the old behavior? What if the new function fixed some critical functionality and by using the old one you'll run into problems because code you expect to work against the new behavior will run into problems? The __libc_start_main is exactly such an example.

"What if"... what if the user somehow manages to poke their eye out when using the mouse, or pours a hot cup of tea into their computer, or the sky suddenly falls?! there is only so much cotton wool and bubblewrap that can be placed between the user and the consequences of their actions. perhaps we should require a competency test and submission of three sworn written references before a user is allowed to download FPC/Lazarus in the first place.

i'm placing at the top of each source file:

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

1. {$INCLUDE /usr/share/fpcsrc/3.2.2/LCsymbol.inc}

and in the body code blocks of the form:

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

1. {$IF DECLARED(libcSTARTM)}
2.   procedure libc_start_main; external name libcSTARTM;
3. {$ELSE}
4.   procedure libc_start_main; external name '__libc_start_main';
5. {$ENDIF}

the file LCsymbol.inc will contain:

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

1. const libcSTARTM =  '__libc_start_main@GLIBC_2.2.5';            // version numbers picked to match glibc at time of file creation
2.       libcDLOPEN =  'dlopen@GLIBC_2.2.5';
3.       libcDLSYM  =  'dlsym@GLIBC_2.2.5';
4.       libcDLADDR =  'dladdr@GLIBC_2.2.5';
5.       libcDLERROR = 'dlerror@GLIBC_2.2.5';  
6.       libcDLCLOSE = 'dlclose@GLIBC_2.2.5';

if the user wants to go back to original behavior (using the latest version of each symbol) they merely needs to replace LCsymbol.inc with an empty file - or delete the file if i can figure out how to $INCLUDE conditionally on the file existing. after making any changes to the contents of LCsymbol.inc it will then be necessary for the user to rebuild the FPC source tree.

once i've got it working, i'll write a GUI application that gets all the available symbol versions (for __libc_start_main, dlopen, dlsym, dladdr, dlerror, and dlclose) and present the user with the options of: default, earliest, matching set. the user's choice can then be written to LCsymbol.inc and a rebuild of the FPC source tree initiated.


speaking of which - under linux how do you rebuild the FPC source tree? and how do you optionally {$INCLUDE ...} a file that may or may not exist?


cheers,
rob   :-)

[marcov]

users of FPC/Lazarus seem to have been searching for a solution to the 'libc problem' for years,

Yes. As Windows users they expect the same freedoms on Linux as they have on Windows with backwards and forwards exe compatibility. That's why it comes up each time again.

and this seems to be one that operates entirely within how glibc's authors intended. glibc contains multiple versions of symbols to cater for this very situation, and FPC is quite conservative in the use of libc features.

If so, it would be good to have a report of an intermediate user that pioneers this feature and evaluate it long time if it actually is the panacea for binary compatibility.

Maybe it is in a narrow sense, but I doubt it will be of universal use.  There are more issues than  just symbol versioning:

• struct versioning
• startup code
• dynamic loader behaviour
• compatibility breaks papered over with macros

the list goes on.

if it were a problem due to FPC doing something 'weird' under the hood, then FPC would surely be designed to refuse to compile unless a minimum compatible version of libc was detected?

What is weird or not, is not terribly well defined. Basically they just do a change, patch up just enough so that enough remains working with gcc,  and the rest can go hang.

So there is no specification (Posix is too narrow for non trivial stuff), and no compatibility guarantee. That makes it very hard for others. 

The problem is also that there is no mechanism like Windows (where you can submit a binary that doesn't work with a new OS, and it is actually looked at), and most APIs are supported wrt backwards compatibility. (*) The base system maintainers simply close everything, in all those 25 years I can't remember one single occurrence where they fixed a breakage at their end.

"What if"... what if the user somehow manages to poke their eye out when using the mouse, or pours a hot cup of tea into their computer, or the sky suddenly falls?! there is only so much cotton wool and bubblewrap that can be placed between the user and the consequences of their actions. perhaps we should require a competency test and submission of three sworn written references before a user is allowed to download FPC/Lazarus in the first place.

If you up the requirements for minimal user, you can just let the exceptional cases build and modify their own.

i'm placing at the top of each source file:

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

1. {$INCLUDE /usr/share/fpcsrc/3.2.2/LCsymbol.inc}

The RTL is already precompiled and won't change with that.

[PascalDragon]

google tells me that "A frickle is a fried pickle originating in America's south but now seen on the menus of hip urban pubs and cafes in Australia and New Zealand. Our modern interpretation of this addictive snack is accompanied by a sriracha (Vietnamese chilli sauce) spiked mayonnaise". although i'm not quite sure you mean this - can you please clarify your use of the term?

I meant fickle.

also, who is the 'we' you mean in "we don't want something like that"? in this country, New Zealand, 'we' refers to the sitting monarch. again, this might mean something different where you live. please clarify.

Well, the “sitting monarch” isn't that wrong, cause I mean the “we” in the sense of us FPC core developers.

users of FPC/Lazarus seem to have been searching for a solution to the 'libc problem' for years, and this seems to be one that operates entirely within how glibc's authors intended. glibc contains multiple versions of symbols to cater for this very situation, and FPC is quite conservative in the use of libc features. if it were a problem due to FPC doing something 'weird' under the hood, then FPC would surely be designed to refuse to compile unless a minimum compatible version of libc was detected?

No, because FPC does not do any analysis of the involved binaries. It leaves all that to the linker which is GNU ld on Linux.

And what if the user does not want the old behavior? What if the new function fixed some critical functionality and by using the old one you'll run into problems because code you expect to work against the new behavior will run into problems? The __libc_start_main is exactly such an example.

"What if"... what if the user somehow manages to poke their eye out when using the mouse, or pours a hot cup of tea into their computer, or the sky suddenly falls?! there is only so much cotton wool and bubblewrap that can be placed between the user and the consequences of their actions. perhaps we should require a competency test and submission of three sworn written references before a user is allowed to download FPC/Lazarus in the first place.

As a developer of a development system one has to keep those “what if” situations in mind as much as possible, cause users will abuse such systems and thus they need to be as robust as reasonably possible. And especially here it's more likely that users would want the more modern, potentially bug free behavior than an older one, especially if they don't care about the support of older Linux distributions.

speaking of which - under linux how do you rebuild the FPC source tree?

make clean all

and how do you optionally {$INCLUDE ...} a file that may or may not exist?

You can't.

[robert rozee]

Maybe it is in a narrow sense, but I doubt it will be of universal use.  There are more issues than  just symbol versioning:

• struct versioning
• startup code
• dynamic loader behaviour
• compatibility breaks papered over with macros

my solution, if it works, is narrowly focused on address just SIX versioned symbols from the ELF Dynamic Symbol Table of compiled linux binaries: __libc_start_main, dlopen, dlsym, dladdr, dlerror, dlclose. currently these are versioned to "2.34", my proposal changes the versioning to "2.2.5". this pushes back the 'drop-dead' date of FPC/Lazarus for linux by about 10 years - an estimate based upon how versioning has been handled in the past. it is NOT a cure, it is a treatment, a 'band-aid' if you like, but nonetheless gives more time to find a permanent solution.

Well, the “sitting monarch” isn't that wrong, cause I mean the “we” in the sense of us FPC core developers

ummm... my reference to a monarch was NOT intended in a positive sense!   

speaking of which - under linux how do you rebuild the FPC source tree?

make clean all

interesting - another forum member sent me a slightly different solution. create a script in the FPC root directory (/usr/share/fpcsrc/3.2.2) containing:

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

1. #!/bin/sh
2. COMPILER=fpc
3. make clean
4. make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
5. make FPC=$COMPILER install INSTALL_PREFIX=/usr/

what is the material difference between their solution and yours? i am using a stock-standard install of FPC and Lazarus from the three .deb files downloaded from https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20amd64%20DEB/Lazarus%202.2.6/. the FPC root directory is owned by 'root' and so anything run on it needs to be done under sudo.

and how do you optionally {$INCLUDE ...} a file that may or may not exist?

You can't.

i suspected as much, but was hoping otherwise. the documentation for $INCLUDE says:

1.2.41  $I or $INCLUDE : Include file
The {$I filename} or {$INCLUDE filename} directive tells the compiler to read further statements from the file filename. The statements read there will be inserted as if they occurred in the current file.
If the file with the given filename exists, it will be included.

the words "If the file with the given filename exists" gave me hope that if the file did NOT exist then compiling would (or could be made to) continue on unimpeded.


cheers,
rob   :-)

[TRon]

speaking of which - under linux how do you rebuild the FPC source tree?

make clean all

interesting - another forum member sent me a slightly different solution. create a script in the FPC root directory (/usr/share/fpcsrc/3.2.2) containing:

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

1. #!/bin/sh
2. COMPILER=fpc
3. make clean
4. make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
5. make FPC=$COMPILER install INSTALL_PREFIX=/usr/

what is the material difference between their solution and yours?

PascalDragon did not "install" the compiler (missing make install option). Perhaps silently he did assume you would do so yourself with make install (in which case the make file uses the default options to install the compiler for you. What location that exactly is and perhaps other tidbits it performs during the makefile install target depends on your host)

Semantically they are almost the same except that PascalDragon's solution combines the make "targets" into one command.

The "another forum member" providing the solution could just as well have wrote to you:

Code: [Select]

make clean all install FPC=$COMPILER OPT="-Fl/usr/local/lib" INSTALL_PREFIX=/usr/
Another significant difference is that the "another forum member" lets you specifically specify the compiler used for the build process while PascalDragon's solution implicitly tells to use any compiler for the build that the build script is able to find/locate (system path, alias, etc.) But since "another forum user" defines the compiler as being "fpc" there is no  practical difference. Note that this is usually referred to as "bootstrap compiler".

I do not know the significance of "-F/usr/local/lib" that "another forum member" recommends to use because for me that directory is empty but it is to tell the compiler where to look/search for libraries as it represents the library path (see also https://www.freepascal.org/docs-html/user/userap1.html).

[robert rozee]

problem solved:

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

1. user@user-VirtualBox:~/pascal/test 1$ ldd --version
2. ldd (Ubuntu GLIBC 2.35-0ubuntu3.1) 2.35
3. Copyright (C) 2022 Free Software Foundation, Inc.
4. This is free software; see the source for copying conditions.  There is NO
5. warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
6. Written by Roland McGrath and Ulrich Drepper.
7. user@user-VirtualBox:~/pascal/test 1$
8. user@user-VirtualBox:~/pascal/test 1$ objdump -T project1 | grep "("
9. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) wcrtomb
10. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) wcscoll
11. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) setenv
12. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) dlclose
13. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) setlocale
14. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) strcoll
15. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) iconv_close
16. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) mbrlen
17. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) dlerror
18. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) mbrtowc
19. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) dlopen
20. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) iconv
21. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) __libc_start_main
22. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) iconv_open
23. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) nl_langinfo
24. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) towlower
25. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) dlsym
26. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) __errno_location
27. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) towupper
28. 0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) sched_yield
29. 0000000000000000  w   DF *UND*  0000000000000000 (GLIBC_2.2.5) __cxa_finalize
30. user@user-VirtualBox:~/pascal/test 1$

the above lazarus GUI application was compiled on a linux mint 21.1 64-bit VM.


cheers,
rob   :-)

addendum: well, i may have spoken too quick! tried running the binary on a linux mint 19 64-bit VM and it fails with:

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

1. user@Mint19:~/Desktop$ ./project1
2. ./project1: relocation error: ./project1: symbol dlopen version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
3. user@Mint19:~/Desktop$

a couple of quick checks reveal:

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

1. user@Mint19:~/Desktop$ readelf --dyn-syms -W /lib/x86_64-linux-gnu/libc.so.6 | grep "__libc_start_main"
2.   2206: 0000000000021ba0   446 FUNC    GLOBAL DEFAULT   13 __libc_start_main@@GLIBC_2.2.5
3. user@Mint19:~/Desktop$
4. user@Mint19:~/Desktop$ readelf --dyn-syms -W /lib/x86_64-linux-gnu/libc.so.6 | grep "dlclose"
5.   1266: 0000000000166620   168 FUNC    GLOBAL DEFAULT   13 __libc_dlclose@@GLIBC_PRIVATE
6. user@Mint19:~/Desktop$

so one problem has been replaced with another! on the plus side, __libc_start_main is versioned correctly, so i just need to find a workaround for the remaining five (dlsym, dladdr, dlclose, dlerror, and dlopen). i have a few ideas...

[marcov]

I do not know the significance of "-F/usr/local/lib" that "another forum member" recommends to use because for me that directory is empty but it is to tell the compiler where to look/search for libraries as it represents the library path (see also https://www.freepascal.org/docs-html/user/userap1.html).

/usr/local/lib comes from BSD and is historically a prefix where third party (non package system or even non base system) libraries are stored. I think on Linux it matters less, except Slackware iirc adhered to it.

The original buildfaq was mostly crafted on BSD, which might explain why it is so prevalent in buildscripts.

For reference, my *nix build script that also contains it:

Code: [Select]

#!/usr/bin/env bash
# simple i386/x86_64 building on linux/*BSD.

# -j and -T factor.  Rule of thumb physical cores plus 1 or 2. Values above 4-6 have little effect, even if you have the cores.
# there is not enough parallelism in the tree.
CORES=2
HOSTARCH=`uname -m`
HOSTOS=`uname -s`
SRCDIR=/fpc/fpc
DESTDIR=~/src/builded
HAVEDEBUG=1
OVERRIDEDETECTION=0
HAVEOPT=0
LIBCRTL=0
ARGS=" -viwn -Sg -Fl/usr/local/lib  -dLZX_USETHREADS "
OPTSETTINGS=" -O4 -Opcoreavx -Cpcoreavx  -Cfavx "
DEBUGSETTING=" -gw2 -gl  -Xg  -godwarfsets "

#----------------------

is64=0
START=ppcrel
GENCOMPILER=ppc386
NEWOPT=""

if [ $LIBCRTL = "1" ] ; then
  ARGS+=" - dFPC_USE_LIBC "
fi
if [ $OVERRIDEDETECTION != 1 ]; then
if [ "$HOSTARCH" = "x86_64" ] ; then
  is64=1
fi
if [ "$HOSTARCH" = "amd64" ] ; then
  is64=1
fi
fi

if [ $is64 = 1 ]; then
  START=ppcrel64
  GENCOMPILER=ppcx64
fi

if [ "$HAVEDEBUG" = "1" ] ; then
  if [ "$ARGS" != "" ]; then
   ARGS="$ARGS$DEBUGSETTING"
  fi
fi

if [ "$HAVEOPT" = "1" ] ; then
  $NEWOPT=$OPTSETTINGS
fi
 
GMAKE=gmake
if [ $HOSTOS = "Linux" ] ; then
  GMAKE=make
fi

JOPT="-j $CORES"
FPMAKEOPT="-T $CORES"
while getopts ":nj:" optname
  do
    case "$optname" in
      "j")
        echo Cores overriden to $OPTARG
        JOPT="-j $OPTARG"
        FPMAKEOPT="-T $OPTARG"
        ;;
      "n")
         JOPT=""
        ;;
      *)
        echo "Unknown error while processing options"
        ;;
    esac
  done

if [ $OVERRIDEDETECTION != 1 ]; then
echo ARCH is $HOSTARCH on \(OS:\) $HOSTOS
echo Build in $SRCDIR, installing in $DESTDIR with $CORES cores
fi

cd $SRCDIR

$GMAKE $JOPT clean   FPMAKEOPT="$FPMAKEOPT" PP="$START" FPC="$START" OPT="$ARGS" NEWOPT="$NEWOPT" &> ~/cleanlog64

$GMAKE $JOPT  all  FPMAKEOPT="$FPMAKEOPT" PP="$START" FPC="$START" OPT="$ARGS" NEWOPT="$NEWOPT" &> ~/buildlog64

if [ ! $? = 0 ] ; then
 echo DAMN, failed again
else
 $GMAKE install FPC=compiler/$GENCOMPILER OPT="$ARGS" NEWOPT=$NEWOPT INSTALL_PREFIX=$DESTDIR &> ~/installog
 if [ ! $? = 0 ] ; then
  echo INSTALL failed | tee ~/outcome
 else
  echo Everything _should_ be fine.| tee ~/outcome
 fi
fi


[TRon]

Thank you for that explanation marcov. My distribution seems to omit it, as per FHS.

[marcov]

Thank you for that explanation marcov. My distribution seems to omit it, as per FHS.

The equivalent FreeBSD page is man hier

[PascalDragon]

Well, the “sitting monarch” isn't that wrong, cause I mean the “we” in the sense of us FPC core developers

ummm... my reference to a monarch was NOT intended in a positive sense!   

Doesn't matter how you meant it, it doesn't change the fact that we devs are acting as gate keepers to ideas that are not really feasible.

speaking of which - under linux how do you rebuild the FPC source tree?

make clean all

interesting - another forum member sent me a slightly different solution. create a script in the FPC root directory (/usr/share/fpcsrc/3.2.2) containing:

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

1. #!/bin/sh
2. COMPILER=fpc
3. make clean
4. make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
5. make FPC=$COMPILER install INSTALL_PREFIX=/usr/

what is the material difference between their solution and yours?

As TRon said, my example doesn't include the installation step and combines the clean and all steps into a single call. As long as you don't use parallel invocation (by passing -j <number> to make) there won't be a difference. If you use parallel invocation you should use the separate invocations from the other example.

In essence you just need to invoke make with the correct parameters to compile FPC. See also here plus looking at documentation in how to invoke make in general.

i am using a stock-standard install of FPC and Lazarus from the three .deb files downloaded from https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20amd64%20DEB/Lazarus%202.2.6/. the FPC root directory is owned by 'root' and so anything run on it needs to be done under sudo.

You should not mess with your existing installation. Just download the FPC source (no matter if the development branch or a release) and build that.

and how do you optionally {$INCLUDE ...} a file that may or may not exist?

You can't.

i suspected as much, but was hoping otherwise. the documentation for $INCLUDE says:

1.2.41  $I or $INCLUDE : Include file
The {$I filename} or {$INCLUDE filename} directive tells the compiler to read further statements from the file filename. The statements read there will be inserted as if they occurred in the current file.
If the file with the given filename exists, it will be included.

the words "If the file with the given filename exists" gave me hope that if the file did NOT exist then compiling would (or could be made to) continue on unimpeded.

The documentation could use some improvement then...

[robert rozee]

we devs are acting as gate keepers to ideas

well... that makes it even worse. in effect, you are saying that the developers are keeping certain information 'closed source'. certainly this is a violation of the GPL et al, if not in the letter of the law then certainly in spirit! is this stance any different to the high priests of ancient societies that used the control of knowledge to keep the population subservient?


cheers,
rob   :-)

[PascalDragon]

we devs are acting as gate keepers to ideas

well... that makes it even worse. in effect, you are saying that the developers are keeping certain information 'closed source'. certainly this is a violation of the GPL et al, if not in the letter of the law then certainly in spirit! is this stance any different to the high priests of ancient societies that used the control of knowledge to keep the population subservient?

Huh? Where did I write that we keep things “closed source”?! My point was that we don't let everything get into the language or the RTL. Functionality that never gets into the language/RTL is not part of the distribution and thus never part of the license.

[robert rozee]

we devs are acting as gate keepers to ideas

well... that makes it even worse. in effect, you are saying that the developers are keeping certain information 'closed source'. certainly this is a violation of the GPL et al, if not in the letter of the law then certainly in spirit! is this stance any different to the high priests of ancient societies that used the control of knowledge to keep the population subservient?

Huh? Where did I write that we keep things “closed source”?!

is "gate keepers to ideas" not just a more prosaic way of saying 'closed source'? ideas, knowledge, being withheld or suppressed because those ideas are deemed 'bad' by a select group of experts.

am getting close to a workable solution of the symbol versioning issue. turns out that just a single line in each of  si_c.inc and si_g.inc needs changing, and a 'dummy' replacement for libdl.so dropping into each of your project directories. the end result is a binary that has all GLIBC symbols versioned to 2.2.5. it works under linux mint 21.1 (glibc 2.35), producing a binary that runs fine under mint 19.3 (glibc 2.27). other folks are testing with other distros. i've only been testing with a couple of relatively simple GUI application so far, but the results look promising. i'm hoping to create a shell script to make the necessary small changes, and am considering if it is worth creating two branches in /usr/share/fpcsrc of 3.2.2 (3.2.2_old and 3.2.2_new) with a symlink used to switch between them.


cheers,
rob   :-)

[marcov]

is "gate keepers to ideas" not just a more prosaic way of saying 'closed source'? ideas, knowledge, being withheld or suppressed because those ideas are deemed 'bad' by a select group of experts.

Gate keepers also select people/things coming in. That's what I think PascalDragon hinted on. IOW what patches/features to integrate.

[robert rozee]

Gate keepers also select people/things coming in. That's what I think PascalDragon hinted on. IOW what patches/features to integrate.

perhaps i am being a bit harsh... i can understand the need to avoid 'feature creep', where a product has more and more features added to meet (usually sales executive) demands. i've worked on hardware projects which suffered from this, to the point of nearly being cancelled by management after several years of continual additions.

but at the same time, i do feel that (open source) developers should also be open about the internal workings of their projects. if someone asks "how can i modify it to do this", the developers should not say "that is a 'frickle scheme' (maintaining PascalDragon's keyboard mishap) but rather help out (where practical) anyone who wants to dig into the source code themselves. even if their changes will never go into the main source.

case in point is the alterations i am working on with some other forum members at the moment. turns out it is relatively easy to modify FPC to build against any version of libc that the currently installed glibc supports. my glibc (version 2.35) has internal support for glibc 2.34 symbols, as well as a complete base set of glibc 2.2.5 symbols. the glibc 2.2.5 support is complete, and likely to be with glibc for many years to come. but i couldn't care less about the alterations being incorporated into the main source of FPC. all i want to do is create a set of patches that anyone else is free to incorporate into FPC if they wish to. is this unreasonable?


cheers,
rob   :-)