/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found lazarus / 32-Linux ---------------------------------------------------------------------- fedkad · 2022-03-28 13:59 I am running "Lazarus 2.2.0 / FPC 3.2.2 / x86_64-linux-gtk2" on Ubuntu 21.10. The code compiled under this environment, when attempted to be run on a slightly older (but, still supported) version of Linux, for example Debian 10 will give an error like this: ./my_program: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./my_program) How can I create Linux executable code that can be run on any version of GLIBC smaller than 2.34? Note: "objdump -T my_program | grep -i glibc" output is something like this: 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 wcrtomb 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 wcscoll 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlerror 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 setenv 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 setlocale 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 strcoll 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlopen 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 iconv_close 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 mbrlen 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlclose 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 mbrtowc 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  __libc_start_main 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dlsym 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 iconv 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 iconv_open 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 nl_langinfo 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 towlower 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.34  dladdr 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 __errno_location 0000000000000000      DF *UND*   0000000000000000  GLIBC_2.2.5 towupper 0000000000000000  w   DF *UND*   0000000000000000  GLIBC_2.2.5 __cxa_finalize ---------------------------------------------------------------------- trev · 2022-03-28 14:07 The obvious answer is to statically link the needed libraries rather than loading them dynamically. The most significant advantage of static linking is that the application can be certain that all its libraries are present and that they are the correct version. Static linking of libraries also allows the application to be contained in a single executable file, simplifying distribution and installation. Also with static linking, only those parts of the library that are directly and indirectly referenced by the target executable are included in the executable. With dynamic libraries, the entire library is loaded, as it is not known in advance which functions will be used by the application. ---------------------------------------------------------------------- PascalDragon · 2022-03-29 08:24 Quote from: fedkad on March 28, 2022, 03:59:03 pmHow can I create Linux executable code that can be run on any version of GLIBC smaller than 2.34? By compiling it on a system that has an older GLIBC. This is simply how things work on Linux or ELF files in general. See also Jonas Maebe's answer here. ---------------------------------------------------------------------- fedkad · 2022-03-29 08:31 Thanks for the answers. I was expecting a compile and/or link option that will prevent the usage of GLIBC 2.34. ---------------------------------------------------------------------- Gustavo 'Gus' Carreno · 2022-03-29 09:07 Hey Fedkad, Quote from: fedkad on March 29, 2022, 10:31:33 amThanks for the answers. I was expecting a compile and/or link option that will prevent the usage of GLIBC 2.34. I've had the same issue since I'm also in Ubuntu 21.10 and I've noticed this quite a while ago. I'm not sure the lower version `libc` is still installed in the system since I never bothered to actually go look, but if it still is, due to some relic binary that cannot link to 2.34, there could be a solution. The solution I've thought about is to do with messing around `fpc.cfg` to have `libc` served from another folder. I'm not quite sure if this is possible, since it would have to be passed to the lnker, but if possible, this would solve the problem. In any case, this would be a case for the more experienced Free Pascal users on this forum to pitch in and give some suggestions of the if its possible OR how to go about it. Cheers, Gus ---------------------------------------------------------------------- dbannon · 2022-03-29 09:22 Seems strange, I build my app on an U20.04 VM and it has libc6 2.31 and the resulting binary works fine on U16.04 and its a lot older 2.23 libc6.  Thats a far bigger jump than fedkad mentions. Is there some more significant change taken place with 2.34 ? Davo ---------------------------------------------------------------------- PascalDragon · 2022-03-29 11:24 Quote from: dbannon on March 29, 2022, 11:22:55 amIs there some more significant change taken place with 2.34 ? Yes, there is. They changed how the initialization works and thus an older libc with binaries compiled for a newer libc would lead to possibly hard to debug problems, because the initializers and finalizers of the binaries wouldn't be run. The last change with a versioned symbol was with 2.1, though that probably wouldn't affect FPC and then 2.0 which would affect FPC (thus you can't use a FPC compiled binary compiled on a system with a glibc < 2.34 with a glibc older than 2.0). ---------------------------------------------------------------------- dbannon · 2022-03-29 22:36 Hmm, I am not sure DP's explanation explains fedkad experience here though. Debian Buster was updated to 2.28 recently (March 22) and that should work fine. fedkad, is your Buster test system up to date ? Davo ---------------------------------------------------------------------- fedkad · 2022-03-30 08:43 Quote from: dbannon on March 30, 2022, 12:36:09 amfedkad, is your Buster test system up to date ? No. I tested my executable at: https://distrotest.net/Debian ---------------------------------------------------------------------- dbannon · 2022-03-30 08:56 I would recommend Virtual Box, only real downside is diskspace used by all the VMs you end up keeping. And, maybe, a VM to build your application too ?  Thats how I work, I have a Bullseye VM where I build the SRC Debs for Debian and a U20.04 VM where I build my binary distributions, its setup to cross compile so I can make 64 and 32 bit Linux, (Debs and RPMs), Win32, RaspPi .... Davo ---------------------------------------------------------------------- RDL · 2022-05-13 10:51 @fedkad Check my ticket on fpc gitlab https://gitlab.com/freepascal.org/fpc/projects/-/issues/3 ---------------------------------------------------------------------- MarkMLl · 2022-05-13 12:52 Noting what everybody else has said, but I believe that the fundamental issue is that the linker resolves/follows symlinks so the actual filename in the executable is that of the actual library. I don't believe that's fixable, it's quite simply the way that the linker and loader work on Linux (and possibly other unices). I've definitely seen comparable issues, although I can't recall whether they specifically involved (g)libc. Also I can't say whether they apply to unices other than Linux, since I've rarely (if ever) had multiple versions of these running and in any event it's long been my policy to try to have FPC/Lazarus on representatives of all OS variants and versions. A related problem I had a couple of years ago was due to an ALSA version change. I worked around that by putting Docker on my development system and setting up a container with the target OS such that I could ssh in and get a shell, after which I could run Lazarus and FPC in the normal way. So I suggest that the first thing to do is to follow through the symlink chain on both systems. I'd be very happy to be told I was wide of the mark, and that there was a simpler fix :-) Added: If it is a library naming issue, it might be possible to fix it using patchelf http://manpages.ubuntu.com/manpages/bionic/man1/patchelf.1.html I've not experimented with this, and I don't know what would happen if a symlink name was patched into the ELF header. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2022-05-16 11:27 Quote from: MarkMLl on May 13, 2022, 02:52:41 pmNoting what everybody else has said, but I believe that the fundamental issue is that the linker resolves/follows symlinks so the actual filename in the executable is that of the actual library. It's not an issue with symlinks or the name of the library. The issue is that newer libcs have a versioned symbol and according to the ELF spec when a symbol that has a version attached is used then this needs to be referenced as such in the ELF binary so that the dynamic linker can then resolve this using the correct version of the symbol, this implicitly also means that if you try to run a binary that uses such a versioned symbol on a system where the corresponding library does not have this symbol with the suitable version (or none at all) then the binary simply won't load. It's as if you'd use a symbol that doesn't exist at all. ---------------------------------------------------------------------- abouchez · 2022-09-27 06:24 Old Thread, but perhaps something was overseen. The error states that dlopen/dlsym/dlclose are not available in the libc/'c'. And they should not, because on Linux they are part of libdl/'dl' as stated by rtl/unix/dl.pp My guess is there is something wrong somewhere in your code or its dependency, which define dlopen/dlsym/dlclose manuall as external 'c'. Perhaps try to use the unit dl which defines things as expected. ---------------------------------------------------------------------- dbannon · 2022-09-27 06:27 WOW, unbelievable !  This thread is many months old and we had a clash. abouchez, maybe my summary will help ? OK, so its an old thread but still a problem. I thought I'd summarize where we are at ! The issue as we know is that, on Linux system, binaries compiled on a system with glib6-2.34 or later will not work on systems using an earlier glibc6. These Ubuntu and Debian distros use the following glibc6 - * U20.04  - 2.31  * U21.04  - 2.33 * U21.10  - 2.34  (Impish) * U22.04 -  2.35  (Jammy) * D.Bullseye - 2.31 * D.Bookworm - 2.34 If you build your app on Ubuntu Jammy or Impish or on Debian Bookworm it will not run on a number of still currently supported systems. I am talking here about Ubuntu and Debian but obviously, same situation applies for all the other distributions ! To my surprise, a build on Jammy works fine on Impish so its a one off problem, not ongoing. I, personally, will keep a Ubuntu 20.04 system going to use as a build machine for the packages I distribute directly, they will run everywhere and I can have a current FPC/Lazarus on them. But I also distribute through an Ubuntu PPA, there you must use the FPC/Lazarus provided by the target release or build newer ones from a source package. Ubuntu, Bionic, U18.04 for example has Lazarus 1.8 and is still an officially supported release until April 2023. I have in the past ported Lazarus 2.0.10 and FPC3.0.2 from Debian Backports to a PPA but really don't want to do that again, because Debian break these up into tiny little modules, its just too messy. I assume the really good Lazarus and FPC debs distributed through SourceForge are built as binaries from the start, not as source packages ?  If source, they could be pushed to a PPA ... Sigh .... Anyway, there it is, if you build and distribute binaries to other Linux users, beware ! Davo ---------------------------------------------------------------------- PascalDragon · 2022-09-27 07:01 Quote from: abouchez on September 27, 2022, 08:24:54 amThe error states that dlopen/dlsym/dlclose are not available in the libc/'c'. There is no mention of dlopen, dlsym or dlclose as part of the error. The only time they're mentioned here is in the listing of the unresolved symbols of the binary in the first message and there that is normal. Quote from: abouchez on September 27, 2022, 08:24:54 amMy guess is there is something wrong somewhere in your code or its dependency, which define dlopen/dlsym/dlclose manuall as external 'c'. Perhaps try to use the unit dl which defines things as expected. *sigh* It has nothing to do with these symbols, but with the symbol versioning of the C library. This was already solved. Quote from: dbannon on September 27, 2022, 08:27:53 amAnyway, there it is, if you build and distribute binaries to other Linux users, beware ! This! (except if they're statically linked like the FPC compiler binary itself ) ---------------------------------------------------------------------- Fred vS · 2022-09-28 22:33 Hello. For info: https://packages.debian.org/search?keywords=libc6 For Debian (who knows, afaik, what is stable or not), version 2.31 is the last stable release. 2.34-2.35 are considered as unstable and 2.36 is experimental. So if you want that your binary-release can run in lot of distros, better to compile+link with a stable libc. ---------------------------------------------------------------------- dbannon · 2022-09-29 00:15 Quote from: Fred vS on September 29, 2022, 12:33:26 am2.34-2.35 are considered as unstable and 2.36 is experimental. Yes Fred but consider that with Ubuntu, arguably the most used distro, the 22.04 long term release, already 5 months old, is using 2.35, that means that all the Ubuntu derivatives such as Linux Mint are also using 2.35 !  The cat is well and truly out of the bag ! Davo ---------------------------------------------------------------------- stephanie · 2022-10-02 08:59 Hello, I have the same problem. I've Lazarus both on a Debian 10 Buster, that uses glibc 2.28 and on a Xubuntu 22.04 LTS, that uses glibc 2.34. If I compile on Xubuntu (glibc 2.34) the executable cant't run on Debian Buster (glibc 2.28): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i stephanie@PcServer:~$ ldd /home/stephanie/MyErpNew/myerp_new_Laz224c/h ome/stephanie/MyErpNew/myerp_new_Laz224c: /lib/x86_64-linux- gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/stephanie/MyErpNew/myerp_new_Laz224c)  It seems it's always necessary to have a virtual machine with an older version of a Linux distro, in order to allow that the executable works on all version of Linux. Otherwise, if I compile with a new Linux distro, who has an older distro can't run the excecutable. Of course I find unconfortable this, but I've found a better solution yet. If anyone have an idea to bypass this problem, it would be very appreciated. I hope that in the future Lazarus can improve a solution to this case. Sorry for my bad English. Best regards, Stephanie ---------------------------------------------------------------------- colo · 2022-10-02 09:40 You don't really need a complete virtual machine around for this; a chroot environment (or "container") suffices. I keep a systemd-nspawn container with Debian oldstable in it (and a recent Lazarus installed from upstream-provided Debian packages) around to build executables with that will run on rather dated GNU/Linux environments, too. ---------------------------------------------------------------------- stephanie · 2022-10-02 09:53 Thank you for your reply. How could I configure a chroot environement? Where could I find documentation? I've no experience with this. Thank you again, best regards, Stephanie ---------------------------------------------------------------------- Fred vS · 2022-10-02 10:17 Quote from: stephanie on October 02, 2022, 10:59:43 am... I hope that in the future Lazarus can improve a solution to this case. The best solution would be that fpc does not need to link libc.so for his /rtl/. But this is not for soon (afaik). ---------------------------------------------------------------------- colo · 2022-10-02 11:56 Quote from: stephanie on October 02, 2022, 11:53:47 amThank you for your reply. How could I configure a chroot environement? Where could I find documentation? I've no experience with this. Thank you again, best regards, Stephanie Assuming you use a Debian-based distribution (such as Ubuntu) to develop on, you can install a package named debootstrap. This software can spawn complete Debian (and a number of derivatives) installations into another directory on your currently mounted file system. The Arch Linux wiki has an excellent article on this technique, which is applicable to an Ubuntu host: https://wiki.archlinux.org/title/Systemd- nspawn#Create_a_Debian_or_Ubuntu_environment The debbostrap documentation will tell you how you can set up Debian 9 or Debian 10 inside such a deboostrap directory, which you can then use to start that as a container via systemd-nspawn. If you want to run a complete Lazarus environment inside that Debian container, with access to its GUI, check out https://wiki.archlinux.org/title/Systemd- nspawn#Use_an_X_environment (which is kinda advanced, but also not necessary). You will also want to access the Lazarus project files from your current develpment environment in the container, and for that you will have to map paths from host to container. https://wiki.archlinux.org/title/Systemd-nspawn#Access_host_filesystem touches on that. My personal setup is an Arch Linux installation on my desktop computer, and I use Lazarus under my user account named "colo" there to develop applications. The source code is stored in /home/colo/codebase in that Arch Linux installation. I do have a Debian 10 Container in /var/lib/machines/deb10 (initially created via deboostrap), which also has a user account named "colo" created. To start and enter the container, I invoke `sudo systemd-nspawn -D /var/lib/machines/deb10 -b --bind=/home/colo/codebase/ --bind=/home/colo/.Xauthority --bind=/tmp/.X11-unix/` on my Arch Linux host, and log in to the Debian-based account on the login prompt that show up after that command succeeds. There, I can set the DISPLAY environment variable to point at my Xorg display on the host (export DISPLAY=:0.0) and use lazarus-ide from inside the container, or use lazbuild to create a new executable without having to use the GUI. The binaries end up in the directory shared between the host and the container. When I'm done, I shut down the container as if it were a real machine. ---------------------------------------------------------------------- stephanie · 2022-10-02 19:04 Thank you very very much! Very interesting. I'll study the documentaion and I'll try. Thank you again, best regards, Stephanie ---------------------------------------------------------------------- PascalDragon · 2022-10-03 12:28 Quote from: stephanie on October 02, 2022, 10:59:43 amI hope that in the future Lazarus can improve a solution to this case. There is no better solution than to compile your application on a suitable, older distribution. Anything else is just a hack waiting to break at the most unwanted time possible. Quote from: Fred vS on October 02, 2022, 12:17:06 pmQuote from: stephanie on October 02, 2022, 10:59:43 am... I hope that in the future Lazarus can improve a solution to this case. The best solution would be that fpc does not need to link libc.so for his /rtl/. But this is not for soon (afaik). Not linking to libc means no support for threads or linking to any other more involved library as the C library these libraries in turn depend on wouldn't be initialized correctly (as that is the task of the application startup code). ---------------------------------------------------------------------- stephanie · 2022-10-03 20:14 Hello, an AppImage might be a solution? I don't know if there is an easy tool to generate a Linux AppImage from Lazarus. An AppImage should have all dipendences in the unique file. Anyone has tried? Best regards, Stephanie ---------------------------------------------------------------------- Fred vS · 2022-10-03 22:03 Quote from: stephanie on October 03, 2022, 10:14:44 pmHello, an AppImage might be a solution? I don't know if there is an easy tool to generate a Linux AppImage from Lazarus. An AppImage should have all dipendences in the unique file. Anyone has tried? Best regards, Stephanie The quick, easy an safe way is to install Debian 10 Buster that uses libc.so.6 ver 2.28. https://www.debian.org/releases/buster/debian-installer/ You may install the downloaded iso image with a server virtualization software like VMWare or VirtualBox or QEmu. Then install on that virtual machine last fpc, last Lazarus and compile your last source (that you have developed on your main dev- machine an copy on a usb stick, loaded in the virtual machine). An copy the compiled-result-binary and paste it in your release- package. Your release will run on nearly all actual Linux distros. ---------------------------------------------------------------------- colo · 2022-10-04 08:19 You could look at AppImage, Flatpak, Snap, and potentially other "modern" software distribution vehicles and mechanisms, but they come with a fair share of added complexity and responsibility. If you just dynamically link the host OS's libc, you don't have to keep track of that library's security issues in your distributed copy. So as long as you can get away without shipping a complete "runtime" set of userspace libs along with our application, I think it's wise to do so. ---------------------------------------------------------------------- dbannon · 2022-10-04 09:02 Hmm, I always have several, maybe 10 or 12 current VirtualBox machines on hand because you need to test your app with different desktops. So, my build machine is U2004 Gnome. Its a good idea to build (ie a final, release build) on a different system than you develop on, helps catch situations where your app depends on something that you just happened to have installed on your day to day machine. And I need to test against Gnome and I'd never work, by choice, on a Gnome system. AppImage ?  I looked at that awhile ago, got some very conflicting answers about a GTK2 based AppImage, somone answered my question about where it is only to have that answer removed and replaced by a "we don't do GTK2" - no further response. Packaging containers are generally a real pain !  My App, tomboy-ng is about a 3Meg download and uses about 6meg of diskspace. It replaces the original Tomboy that you can still install as a Flatpack, its a 700Meg download and uses 2.4G of diskspace. Anyone want to guess how much RAM it uses when running ? Another build model that might be useful if you already make debs to distribute your app (and its open source) is Ubuntu's PPA. Despite my grizzels above about having to work with a Debian deb of FPC/Lazarus, I have built an up to date PPA based on U2004 with FPC3.2.2 and Lazarus 2.2.2, if you can make a source package, welcome to use it to build (and distribute) your app. Davo ---------------------------------------------------------------------- PascalDragon · 2022-10-04 11:15 Quote from: stephanie on October 03, 2022, 10:14:44 pman AppImage might be a solution? I don't know if there is an easy tool to generate a Linux AppImage from Lazarus. An AppImage should have all dipendences in the unique file. That would also mean that you're responsible for maintaining all the libraries (and when you replace libc it really is all the libraries) and keeping them up-to-date. Not to mention the size issue as dbannon mentioned. ---------------------------------------------------------------------- stephanie · 2022-10-04 12:03 Hello, thanks for your answers, they helped me a lot to understand better. At this point virtualization with VirtualBox or using debootstrap is the best solution. I was already using this solution, although sometimes vice versa, in the sense that I often test new versions of Lazarus on a virtual machine first before moving on to work on the updated version. For example now I have a Debian Buster with Lazarus 2.0.4 on the host machine and a XUbuntu 22.04 with Lazarus 2.2.4 on the guest. I just would have preferred to be able to test the executable generated on the guest on the host, but I understand that it is not possible and then I will test on the guest, no problem. One last question: being Linux Open Source, couldn't you add some older version library packages, with an option to compile with them? With Windows presumably it cannot be possible for licensing reasons, but with Linux it should perhaps be possible. However now it is much clearer to me, thank you very much for your answers. Best regards, Stephanie ---------------------------------------------------------------------- Fred vS · 2022-10-04 12:42 Quote from: stephanie on October 04, 2022, 02:03:45 pm... One last question: being Linux Open Source, couldn't you add some older version library packages, with an option to compile with them? Not sure to understand but, apart for libc.so, you may use LoadLibrary(/path/of/library) (= dlopen()) instead of linking the library at compilation (using "external"). https://wiki.freepascal.org/Lazarus/FPC_Libraries#Loadlibrary_- _dynamically_loading_a_dynamic_library And have the choice to load the library form where an when you want. For example, this fpgui project dynamically loads X11 and TThreads dependencies: https://github.com/fredvs/uidesigner_ext ---------------------------------------------------------------------- dbannon · 2022-10-04 23:25 Another thing worth keeping in mind is that this is, hopefully, a one- off problem. Over time, all the systems running Compiler Options -> Custom Options -> All Options ... gives you a checkbox for -sh (or you can just add that to the "Custom Options" list). Selecting that results in a build finishing with a ppas.sh script and a .res for the linker's -T option. That has some useful implications for an issue I raised a couple of weeks ago where it wasn't possible to build FPC 3.2 using 3.0 on Linux x86_64, which the developers brushed under the carpet. Another thing worth getting into the doctrine is that ld (GNU ld, particularly on Linux) resolves all symlinks, so moving a binary between systems with substantially different varianct of core libraries can be an issue. MarkMLl ---------------------------------------------------------------------- maxerist · 2022-11-25 08:43 Quote from: MarkMLl on November 24, 2022, 05:35:59 pmI'd throw in (after a few minutes playing) that on Linux Lazarus Options -> Compiler Options -> Custom Options -> All Options ... gives you a checkbox for -sh .... Great to know, thanks.  I wish I knew, my post would be much shorter :) I can confirm that for sh/st options the res file is exactly the same as the one that is created and deleted without it. Also the shell script generated by fpc works when executed on another machine (providing other necessary steps were made). It links and aslo extracts debug symbols (if necessary) and strips. The only difference I noticed between sh and st (shell for target linking) options is that latter uses the tool executable names without full paths, probably assuming that the tools locations might be different. ---------------------------------------------------------------------- MarkMLl · 2022-11-25 08:56 Quote from: maxerist on November 25, 2022, 09:43:30 amI can confirm that for sh/st options the res file is exactly the same as the one that is created and deleted without it. I've not checked yet but expect differences in the .res file between 3.0.4 and 3.2.0, relating to the -T warning that appeared during a 3.0 compilation. That can have various side-effects, depending on target. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2022-11-27 20:56 Quote from: maxerist on November 25, 2022, 09:43:30 amI can confirm that for sh/st options the res file is exactly the same as the one that is created and deleted without it. Also the shell script generated by fpc works when executed on another machine (providing other necessary steps were made). It links and aslo extracts debug symbols (if necessary) and strips. The only difference I noticed between sh and st (shell for target linking) options is that latter uses the tool executable names without full paths, probably assuming that the tools locations might be different. -sh -> Script for linking on host -st -> Script for linking on target That's why there are differences. ---------------------------------------------------------------------- MarkMLl · 2022-11-27 22:06 Quote from: PascalDragon on November 27, 2022, 09:56:02 pm-sh -> Script for linking on host -st -> Script for linking on target That's why there are differences. Sorry, I should have spotted that and saved you some work. MarkMLl ---------------------------------------------------------------------- c600g · 2022-12-02 17:02 I stumbled onto this issue a couple weeks ago with a client that runs our shared library in an AWS Lambda Function environment (using an Amazon Linux 2 base image). Amazon Linux 2 uses a libc version without the pthreads and dl library integration changes, so trying to use our shared library built on the most recent stable Ubuntu release (or Fedora) results in an error. Amazon is working on a new version of Amazon Linux (2022) with updated glibc support, but it does not seem ready yet and who knows when our client will decide to move over to that base image instead of AL2. To address the problem, I am currently building a container based on Ubuntu 20.04 that will add the necessary dependencies to build FPC and Lazarus via fpcupdeluxe, and use distrobox to use that as my dedicated Lazarus build environment. Alan ---------------------------------------------------------------------- MarkMLl · 2022-12-02 18:25 libc without pthreads... yes, I've come across that combination on an x86_64 tablet when investigating FPC with Termux. MarkMLl ---------------------------------------------------------------------- robert rozee · 2023-04-29 17:04 my apologies for resurrecting an old thread, but here seems to be the most complete discussion of the matter... i just experienced the disastrous consequences of pushing out a software release compiled on a recent linux install (mint 21.1) that ended up linked against glibc 2.34. the outcome was a right mess, and i just spent several hours in a panic creating an old mint 19.3 VM to create a working executable that i could substitute. here is the output i get from objdump -T progname | grep -i glibc piped through diff to show just the differences between 'bad' and 'good' executables: Code: [Select]                                  > (GLIBC_2.2.5) dlsym (GLIBC_2.34) dlerror       | (GLIBC_2.2.5) dlclose (GLIBC_2.34) dlopen               < (GLIBC_2.34) dlclose              < (GLIBC_2.34) __libc_start_main    | (GLIBC_2.2.5) dlerror (GLIBC_2.34) dlsym                <                                   > (GLIBC_2.2.5) dladdr                                   > (GLIBC_2.2.5) dlopen (GLIBC_2.34) dladdr               | (GLIBC_2.2.5) __libc_start_main it seems the difference is not insurmountably large - just a few symbols - is there not surely some simple way to pick up the library file:  /lib/x86_64-linux-gnu/libc-2.27.so  and place it where the linker will find and make use of it? a whole VM just to fix 6 small differences seems quite excessive. i have read through the various threads on this and other forums, and it seems to me that there is a great deal of philosophical debate going on (for instance: https://gitlab.com/freepascal.org/fpc/projects/-/issues/3), with little pragmatic consideration. the status quo: sending someone a program file that simply does not run, is a bit of a disaster. i feel we should be able to do better. help, someone, please? cheers, rob   :-) ---------------------------------------------------------------------- MarkMLl · 2023-04-29 18:52 Quote from: robert rozee on April 29, 2023, 07:04:14 pmthe status quo: sending someone a program file that simply does not run, is a bit of a disaster. i feel we should be able to do better. Compared with my comments to (and about) the developers about various build problems, I think you're being remarkably restrained :-) I think your problem cries out for something like a Docker container, or an Appimage. Having seen various compatibility issues relating to Docker I think I'd lean towards the latter, but I don't know how to do it. MarkMLl ---------------------------------------------------------------------- TRon · 2023-04-29 19:00 Quote from: robert rozee on April 29, 2023, 07:04:14 pm... is there not surely some simple way to pick up the library file:  /lib/x86_64-linux-gnu/libc-2.27.so  and place it where the linker will find and make use of it? There is not a proficiency present in the compiler / build system that I am aware of. I would copy the required/wanted file to somewhere else and use the Fl option to point the compiler towards that directory. You could use a define in case you wish to support multiple glibc versions. You/we (FPC) are not he only one facing this issue. It is easy to find online instructions on how to build an older version of glibc and what do do with it (when it comes to compiling/building). Quotethe status quo: sending someone a program file that simply does not run, is a bit of a disaster. i feel we should be able to do better. As said, FPC is not the only compiler having to deal with this issue (more accurate: the dev using the compiler) ---------------------------------------------------------------------- sketch · 2023-04-29 19:10 You can have multiple versions of glibc installed on your server. Code: [Select]wget https://ftp.gnu.org/gnu/glibc/glibc-2.2.5.tar.gz tar -xvzf glibc-2.2.5.tar.gz cd glibc-2.2.5 mkdir build cd build ../configure --prefix=~/opt/glibc-2.2.5 #or wherever you prefer make -j8 #or however many procs you have make install #add sudo if you don't have write privileges like to /usr/local in prefix Then in C++ you want to use -Wl,--rpath=~/opt/glibc-2.2.5 and -Wl,-- dynamic-linker=~/opt/glibc-2.2.5/ld-linux.so.2.27.  I'm not sure how you set those in FPC. Or if you have patchelf installed, then you can run that with the path to ld-linux.so.2.27 and the rpath to where your new glibc is installed against the binary you've already created. ---------------------------------------------------------------------- marcov · 2023-04-29 21:43 Quote from: sketch on April 29, 2023, 09:10:12 pmThen in C++ you want to use -Wl,--rpath=~/opt/glibc-2.2.5 and -Wl,--dynamic- linker=~/opt/glibc-2.2.5/ld-linux.so.2.27.  I'm not sure how you set those in FPC. You can pass paths to the linker with -Xr and the dynamic linker with -FD. ---------------------------------------------------------------------- robert rozee · 2023-04-30 12:37 i've tried all combinations of -Fl, -Xr and -FD plugged into the Custom Options field in the IDE, but the result when compiling is always much the same: Code: [Select]Warning: Only one source file supported, changing source file to compile from "~/pascal/GFXterm 2.1c/libc.so.6" into "project1.lpr" i've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy! an idea that did occur: could one be tricky and create a 'fake' dynamic library containing just the 6 offending symbols, convincing lazarus that the symbols are not part of the operating system? this library does not need to be functional, just provide the symbols and links that go either nowhere or to empty routines. the fake library would serve purely to 'guide' the compiling/linking process, and would be deleted/removed/renamed once that is finished. btw: i am far from a linux expert, but i do usually manage to muddle my way through! cheers, rob   :-) ---------------------------------------------------------------------- MarkMLl · 2023-04-30 14:30 Quote from: robert rozee on April 30, 2023, 02:37:18 pmi've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy! Snippet for you: I'm not sure to what extent this is universal behaviour, but my experience on Linux is that any library symlinks are resolved at build- rather than run-time. MarkMLl ---------------------------------------------------------------------- TRon · 2023-04-30 15:51 Quote from: robert rozee on April 30, 2023, 02:37:18 pmi've tried all combinations of -Fl, -Xr and -FD plugged into the Custom Options field in the IDE, but the result when compiling is always much the same: Code: [Select]Warning: Only one source file supported, changing source file to compile from "~/pascal/GFXterm 2.1c/libc.so.6" into "project1.lpr" i've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy! That is strange (or I am extremely lucky). When I use FPC from the commandline and have another version of libc.so located in the directory from which I invoke FPC then FPC automatically/firstly picks up on that libc.so (according to gnu ld linker). I do have another issue but that is my fault as I also need to use/build the correct pthreads lib. Have you tried to look at what adding the FPC option -k--trace produces for you ? ---------------------------------------------------------------------- Fred vS · 2023-04-30 17:27 Quote from: robert rozee on April 30, 2023, 02:37:18 pmi've tried all combinations of -Fl, -Xr and -FD plugged into the Custom Options field in the IDE, but the result when compiling is always much the same: Code: [Select]Warning: Only one source file supported, changing source file to compile from "~/pascal/GFXterm 2.1c/libc.so.6" into "project1.lpr" i've got two copies of the 'good' library file (uplifted from mint 19.3), one named libc.so.6, the other named libc-2.27.so, sitting in my project folder. i've also tried copying these into the lib/x86_64-linux directory of my project. but no luck. it seems that persuading the IDE to allow picking up a library from somewhere other than what it considers to be the correct location is not so easy! an idea that did occur: could one be tricky and create a 'fake' dynamic library containing just the 6 offending symbols, convincing lazarus that the symbols are not part of the operating system? this library does not need to be functional, just provide the symbols and links that go either nowhere or to empty routines. the fake library would serve purely to 'guide' the compiling/linking process, and would be deleted/removed/renamed once that is finished. btw: i am far from a linux expert, but i do usually manage to muddle my way through! cheers, rob   :-) Hello. Maybe not related but, fpc using "external", does not allow "extended" so extension ( libc.so.6 vs libc.so ). You may try using a symlink libc.so with target libc.so.6. ---------------------------------------------------------------------- marcov · 2023-04-30 19:36 IIRC you also needed -Xd to omit built-in paths. But it is all quite some time ago for me that I did it routinely, and the T_* files in the compiler might have changed since. ---------------------------------------------------------------------- MarkMLl · 2023-04-30 19:44 Quote from: Fred vS on April 30, 2023, 07:27:15 pmMaybe not related but, fpc using "external", does not allow "extended" so extension ( libc.so.6 vs libc.so ). You may try using a symlink libc.so with target libc.so.6. Now that's an interesting one. If my understanding that symlinks are resolved early is correct, that means that a symlink such as libc.so in the project directory would be followed at build time, allowing a reference to an "alien" version of libc without jeopardising the stability of the remainder of the system. MarkMLl ---------------------------------------------------------------------- TRon · 2023-04-30 20:10 @MarkMLI: That is correct. ---------------------------------------------------------------------- dbannon · 2023-05-01 00:13 I find it hard to believe that its not easier (and safer) to have a VM setup with a older OS such as U20.04 or Bullseye and do your 'release' builds there. I have such a VM, it has nothing except the things I know are needed to build and package. It's also good in that it will tell me if I have become dependent on a library I installed for another reason on my working machine that needs to be added to dependency list. Doing release builds on a dev system is not a great idea IMHO. Davo ---------------------------------------------------------------------- robert rozee · 2023-05-01 09:12 Quote from: dbannon on May 01, 2023, 02:13:10 amI find it hard to believe that its not easier (and safer) to have a VM setup well, i was going to disagree with dbannon, but then tried what Fred vS suggested: Quote from: Fred vS on April 30, 2023, 07:27:15 pmMaybe not related but, fpc using "external", does not allow "extended" so extension ( libc.so.6 vs libc.so ). You may try using a symlink libc.so with target libc.so.6. i placed libc.so in the project directory, and things happened... but unfortunately not quite in the way that i had hoped for! the presence of an 'old' libc.so rippled through the entire build of everything else that had built when anything was installed on the machine. so it would seem that the presence of the 'old' libc.so may needs to be strictly limited to just when the final executable is being put together. i can't see any sensible way to achieve this. Code: [Select]Compile Project, Mode: Release, Target: project1: Exit code 1, Errors: 1, Hints: 4 Hint: Start of reading config file /etc/fpc.cfg Hint: End of reading config file /etc/fpc.cfg unit1.pas(216,7) Hint: Local const "SoftwareKey" is not used unit1.pas(365,7) Note: Local variable "CPC" not used linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `lstat64@GLIBC_2.33' linker: /usr/bin/ld: /lib/x86_64-linux-gnu/libmount.so.1: undefined reference to `fstatat@GLIBC_2.33' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_trywrlock@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_wrlock@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlinfo@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutexattr_init@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `fcntl64@GLIBC_2.28' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `stat64@GLIBC_2.33' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_create@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `close_range@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `lstat@GLIBC_2.33' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlclose@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_tryrdlock@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_detach@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_setname_np@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_key_delete@GLIBC_2.34' linker: /usr/bin/ld: /lib/x86_64-linux-gnu/libselinux.so.1: undefined reference to `gettid@GLIBC_2.30' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlsym@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_unlock@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_setspecific@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlopen@GLIBC_2.34' linker: /usr/bin/ld: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `statx@GLIBC_2.28' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `fstat64@GLIBC_2.33' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_init@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_sigmask@GLIBC_2.32' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlerror@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_getspecific@GLIBC_2.34' linker: /usr/bin/ld: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `dn_expand@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutex_trylock@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutexattr_destroy@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_attr_setstacksize@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_join@GLIBC_2.34' linker: /usr/bin/ld: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `res_nquery@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutexattr_settype@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_rdlock@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `stat@GLIBC_2.33' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `fstat@GLIBC_2.33' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_once@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dladdr@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_destroy@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_key_create@GLIBC_2.34' linker: /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dladdr1@GLIBC_2.34' project1.lpr(24,1) Error: Error while linking Quote from: TRon on April 30, 2023, 05:51:22 pmThat is strange (or I am extremely lucky). [...] Have you tried to look at what adding the FPC option -k--trace produces for you ? i suspect you are extremely lucky! i'm picking that it is dependent on when everything else on your system was built and what versions of various libraries were present at that time. using the lazarus IDE, where can "-k--trace" be inserted? i have never tried using FPC at the commandline to build one of my projects. cheers, rob   :-) ---------------------------------------------------------------------- TRon · 2023-05-01 11:49 Quote from: robert rozee on May 01, 2023, 11:12:44 ami suspect you are extremely lucky! i'm picking that it is dependent on when everything else on your system was built and what versions of various libraries were present at that time. Sorry I thought it was clear from fredvs' comment. I placed the literal named file "libc.so" in my build directory. and end up with your result. Quoteusing the lazarus IDE, where can "-k--trace" be inserted? i have never tried using FPC at the commandline to build one of my projects. Lazarus has a special linker section for that in your project options. If you have your project open: - menu -> project -> project options to show the project options window - in the (left) tree select the root item Compiler Options - select the node Compilation and linking - at the bottom at the right side appears at the bottom a section named linking - check the box "Pass options to linker...." - you probably only need to add "--trace" (without quotes) to the edit box Depending on what version of glibc you have compiled (or are using to build against) the thread functions were removed (or added I can't remember which way it is). Point being, I got the same results and I need to either compile libc another way and/or compile the thread library as well. ---------------------------------------------------------------------- MarkMLl · 2023-05-01 12:01 Quote from: TRon on May 01, 2023, 01:49:22 pmSorry I thought it was clear from fredvs' comment. I placed the literal named file "libc.so" in my build directory. and end up with your result. A file or a symlink? MarkMLl ---------------------------------------------------------------------- TRon · 2023-05-01 12:04 Quote from: MarkMLl on May 01, 2023, 02:01:28 pmA file or a symlink? Literally a file. But because you asked I tried that with a symlink as well -> works. ---------------------------------------------------------------------- sketch · 2023-05-01 15:14 Code: [Select]$ ldd --version ldd ldd (Ubuntu GLIBC 2.35-0ubuntu3.1) 2.35 I built a different version of glibc into /tmp/glibc-2.36 Code: [Select]$ mkdir build $ cd build $ ../configure --prefix=/tmp/glibc-2.36 $ make $ make install Code: [Select]$ cat hello.c #include int main(void) {   printf("hello\n");   return 0; } Build a new executable. Code: [Select]$ g++ -Xlinker -Map=b.map -o xhello -static -L /tmp/glibc-2.36/lib -I /tmp/glibc-2.36/include -Wl,-- rpath=/tmp/glibc-2.36/lib -Wl,--dynamic-linker=/tmp/glibc-2.36/lib/ld- linux-x86-64.so.2 hello.c Code: [Select]$ more b.map Archive member included to satisfy reference by file (symbol) /tmp/glibc-2.36/lib/libc.a(libc-start.o)                               /usr/lib/gcc/x86_64-linux- gnu/11/../../../x86_64-l inux-gnu/crt1.o (__libc_start_main) /tmp/glibc-2.36/lib/libc.a(check_fds.o)                               /tmp/glibc-2.36/lib/libc.a(libc-start.o) (__libc_c heck_standard_fds) /tmp/glibc-2.36/lib/libc.a(libc-tls.o) ... Code: [Select]$ cd /tmp $ mv glibc-2.36 noglibc-2.36 $ ls -ld glibc-2.36 ls: cannot access 'glibc-2.36': No such file or directory $ ./xhello hello You can certainly build a static executable using a different version of glibc that you build yourself. Of course I used C++ in the build of the binary, but it should be translatable to fpc. ---------------------------------------------------------------------- Fred vS · 2023-05-01 15:49 Quote from: sketch on May 01, 2023, 05:14:43 pm... I built a different version of glibc into /tmp/glibc-2.36 Code: [Select]$ mkdir build $ cd build $ ../configure --prefix=/tmp/glibc-2.36 $ make $ make install Hello Sketch and thanks for your tips. About compiling a old version of libc.so, do you know how to find/get libc.so without install it in the system? This because the last time that I did this, with $ make install it erased the installed libc.so and after this the system was not working anymore. Thanks. Fre;D ---------------------------------------------------------------------- sketch · 2023-05-01 16:15 On Ubuntu you can use download packages and then extract the contents. Code: [Select]$ sudo apt-get download regina-rexx It will save the package to your CWD. Code: [Select]$ ar x regina-rexx_3.6-2.4_amd64.deb $ ls control.tar.xz  data.tar.xz  debian-binary  regina- rexx_3.6-2.4_amd64.deb $ unxz data.tar.xz $ tar -xvf data.tar ./ ./usr/ ./usr/bin/ ./usr/bin/regina ./usr/bin/rexx ./usr/bin/rxqueue ./usr/bin/rxstack ... $ cd usr/bin $ rexx --version Regina REXX-Regina_3.6 5.00 31 Dec 2011. All rights reserved. Regina is distributed under the terms of the GNU Library Public License and comes with NO WARRANTY. See the file COPYING-LIB for details. To run a Rexx program: ./rexx [-h?vrt[ir]ap] program [arguments...] ... I would assume Ubuntu has a public repository where you can also download .deb packages. I've downloaded Red Hat RPM packages before to extract them using rpm2cpio before too at the day job. Hopefully that is what you're looking for? ---------------------------------------------------------------------- Fred vS · 2023-05-01 16:38 Quote from: TRon on May 01, 2023, 02:04:15 pmQuote from: MarkMLl on May 01, 2023, 02:01:28 pmA file or a symlink? Literally a file. But because you asked I tried that with a symlink as well -> works. Are you talking about the trick to use -Fl, -Xr, Xd  and -FD and symlink without extended number extension? And saying it works for you? If yes, could you give the fpc parameters that you used? Even better, give in attachment the zipped files of old libc.so.6 and other files needed for linking? Thanks. Fre;D ---------------------------------------------------------------------- Fred vS · 2023-05-01 16:46 Quote from: sketch on May 01, 2023, 06:15:44 pm... Hopefully that is what you're looking for? Hum, not really but thanks. Afaik, if somebody want to install in a custom directory with $ sudo make install , a fake system-root directory must be created and use a parameter to use that fake-root-directory instead of the directory of the system. But if somebody has already done the job, of course I would prefer to use his zipped directory.  Fre;D ---------------------------------------------------------------------- robert rozee · 2023-05-02 07:20 Quote from: TRon on May 01, 2023, 01:49:22 pm- you probably only need to add "--trace" (without quotes) to the edit box is this the output you are after? my apologies for it being so long, you'll see i needed to trim it before the forum software would let me post it! i'm thinking more again about a 'fake' libc.so, no functioning code (or just stubs if needsbe) but the necessary symbols to keep the linker happy. one could then within it have defined the necessary minimum version numbers to match the requirements of your project. i can see (in a warped way) why the linker enforces the minimum versions - it is saying "i can build your project on this machine, but can not be sure the build will run on an older one. i am also assuming that YOU are going to fully test the code i've just built to make sure that everything works fully on this machine". what the linker does NOT know, however, is the minimum versions are for the your project it has just built. for instance, it might be imposing dlopen@GLIBC_2.34 based upon data it has gleaned from libc.so, but your project may only be making use of dlopen functionality that has been present since the 2.1.0 version. hence, while there is some rationale behind what the linker is doing, it is acting on incomplete information and it's strategy is flawed. btw: in the 'Wonderful World of Windows' - where i lived for many years but finally abandoned around 5 years ago - this problem is handled by every documented library call having a revision history, where history markers may be '2000', 'XP', 'XP SP3', '7', etc. when coding to use any library function, one just checks the level of functionality available at your minimum target level and make sure to not use any later functionality. cheers, rob   :-) Code: [Select]Hint: (11030) Start of reading config file /etc/fpc.cfg Hint: (11031) End of reading config file /etc/fpc.cfg Free Pascal Compiler version 3.2.0 [2020/07/07] for x86_64 Copyright (c) 1993-2020 by Florian Klaempfl and others (1002) Target OS: Linux for x86-64 (3104) Compiling project1.lpr (3104) Compiling unit1.pas (3104) Compiling unit2.pas [...] (3104) Compiling unit3.pas [...] (3104) Compiling unit4.pas [...] (3104) Compiling unit5.pas [...] (9022) Compiling resource /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/project1.or (9015) Linking /home/user/pascal/GFXterm 2.1c/project1 /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/si_c.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/abitag.o /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/project1.o /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/project1.or /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/system.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/fpintres.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/objpas.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/cthreads.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/interfaces.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/forms.o /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/unit1.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/linux.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/unixcp.o /usr/share/lazarus/2.0.12/lcl/units/x86_64- linux/gtk2/gtk2disableliboverlay.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2int.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/classes.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/x11/x.o /usr/lib/fpc/3.2.0/units/x86_64-linux/gtk2/gdk2x.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/gtk2/pango.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazfileutils.o [...] /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazstringutils.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/dialogs.o [...] /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/lcltype.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/graphtype.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/graphmath.o [...] /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2msgqueue.o /usr/lib/fpc/3.2.0/units/x86_64-linux/x11/xrender.o /usr/lib/fpc/3.2.0/units/x86_64-linux/cairo/cairo.o /usr/lib/fpc/3.2.0/units/x86_64-linux/gtk2/atk.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazutilsstrconsts.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/fpcadds.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl-objpas/strutils.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-base/gettext.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazclasses.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazmethodlist.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/laz_avl_tree.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/fgl.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/laztracer.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazutilities.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/lresources.o [...] /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/lcltaskdialog.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/uitypes.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/fileutil.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl-objpas/variants.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazconfigstorage.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/dynqueue.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazutf8classes.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl-objpas/varutils.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/avglvltree.o [...] /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazsysutils.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/fpimage.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/intfgraphics.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/fpreadbmp.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/fptiffcmn.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/lclversion.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/icnstypes.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/fpimgcmn.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/pngcomn.o /usr/lib/fpc/3.2.0/units/x86_64-linux/paszlib/zstream.o /usr/lib/fpc/3.2.0/units/x86_64-linux/paszlib/zbase.o /usr/lib/fpc/3.2.0/units/x86_64-linux/paszlib/gzio.o /usr/lib/fpc/3.2.0/units/x86_64-linux/hash/crc.o /usr/lib/fpc/3.2.0/units/x86_64-linux/paszlib/zdeflate.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/paszlib/inffast.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazversion.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-base/contnrs.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/fpcanvas.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/fpreadgif.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/lclrescache.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsreferences.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/clipping.o /usr/lib/fpc/3.2.0/units/x86_64-linux/pasjpeg/jpeglib.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/pasjpeg/jfdctflt.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-base/syncobjs.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/tmschema.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64-linux/masks.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-process/process.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-process/pipes.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/termio.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-base/custapp.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/customtimer.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/actnlist.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/helpintfs.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/imglist.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-base/singleinstance.o [...] /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-image/ellipses.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsimglist.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsproc.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsfactory.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/propertystorage.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-base/rttiutils.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsmenus.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazlogger.o /usr/lib/fpc/3.2.0/units/x86_64-linux/chm/fasthtmlparser.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsforms.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/imagelistcache.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/textstrings.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/extendedstrings.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsstdctrls.o [...] /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wstoolwin.o /usr/lib/fpc/3.2.0/units/x86_64-linux/gtk2/gtk2ext.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/extdlgs.o [...] /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/lclmemmanager.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsprivate.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-base/uriparser.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wscontrols.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lazlinkedlist.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsfactory.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsstdctrls.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wschecklst.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2themes.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/spin.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/grids.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/pairsplitter.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsspin.o /usr/lib/fpc/3.2.0/units/x86_64-linux/fcl-xml/htmldefs.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/maskedit.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/dynamicarray.o [...] /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/laz2_xmlutils.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wsgrids.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/wspairsplitter.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsbuttons.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wscalendar.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wscomctrls.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsdialogs.o /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/cthreads.o: in function `CTHREADS_$$_LOADPTHREADS$$BOOLEAN': cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0xe): undefined reference to `dlopen' /usr/bin/ld: cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0x34): undefined reference to `dlsym' /usr/bin/ld: cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0x4e): undefined reference to `dlsym' /usr/bin/ld: cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0x68): undefined reference to `dlsym' /usr/bin/ld: cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0x82): undefined reference to `dlsym' /usr/bin/ld: cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0x9c): undefined reference to `dlsym' /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64- linux/rtl/cthreads.o:cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$bo olean+0xb6): more undefined references to `dlsym' follow /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/cthreads.o: in function `CTHREADS_$$_UNLOADPTHREADS$$BOOLEAN': cthreads.pp:(.text.n_cthreads_$$_unloadpthreads$$boolean+0xd): undefined reference to `dlclose' /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/dl.o: in function `DL_$$_UNIXGETMODULEBYADDR$POINTER$POINTER$OPENSTRING': dl.pp:(.text.n_dl_$$_unixgetmodulebyaddr$pointer$pointer$openstring+0x 39): undefined reference to `dladdr' /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/dynlibs.o: in function `DYNLIBS_$$_SYSLOADLIBRARYA$RAWBYTESTRING$$INT64': dynlibs.pas:(.text.n_dynlibs_$$_sysloadlibrarya$rawbytestring$$int64+0 x17): undefined reference to `dlopen' /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/dynlibs.o: in function `DYNLIBS_$$_SYSGETPROCEDUREADDRESS$INT64$ANSISTRING$$POINTER': dynlibs.pas:(.text.n_dynlibs_$$_sysgetprocedureaddress$int64$ansistrin g$$pointer+0x12): undefined reference to `dlsym' /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/dynlibs.o: in function `DYNLIBS_$$_SYSUNLOADLIBRARY$INT64$$BOOLEAN': dynlibs.pas:(.text.n_dynlibs_$$_sysunloadlibrary$int64$$boolean+0x6): undefined reference to `dlclose' /usr/bin/ld: /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/dynlibs.o: in function `DYNLIBS_$$_SYSGETLOADERRORSTR$$SHORTSTRING': dynlibs.pas:(.text.n_dynlibs_$$_sysgetloaderrorstr$$shortstring+0xd): undefined reference to `dlerror' /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsextctrls.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsextdlgs.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsforms.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsgrids.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsimglist.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsmenus.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/gtk2wsspin.o /usr/share/lazarus/2.0.12/lcl/units/x86_64- linux/gtk2/gtk2wspairsplitter.o /usr/share/lazarus/2.0.12/lcl/units/x86_64-linux/gtk2/unitywsctrls.o /usr/share/lazarus/2.0.12/lcl/units/x86_64- linux/gtk2/gtk2cellrenderer.o /usr/share/lazarus/2.0.12/lcl/units/x86_64- linux/gtk2/gtk2listviewtreemodel.o /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/unit2.o /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/unit3.o /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/unit4.o /home/user/pascal/GFXterm 2.1c/lib/x86_64-linux/unit5.o /usr/share/lazarus/2.0.12/components/lazutils/lib/x86_64- linux/lconvencoding.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/dos.o /usr/lib/fpc/3.2.0/units/x86_64-linux/rtl/strings.o /usr/lib/x86_64-linux-gnu//libpthread.a /usr/lib/x86_64-linux-gnu//libasound.so /usr/lib/x86_64-linux-gnu//libdl.a /usr/lib/x86_64-linux-gnu//libgdk-x11-2.0.so /usr/lib/x86_64-linux-gnu//libX11.so /usr/lib/x86_64-linux-gnu//libgdk_pixbuf-2.0.so /usr/lib/x86_64-linux-gnu//libgtk-x11-2.0.so /usr/lib/x86_64-linux-gnu//libgobject-2.0.so /usr/lib/x86_64-linux-gnu//libglib-2.0.so /usr/lib/x86_64-linux-gnu//libgthread-2.0.so /usr/lib/x86_64-linux-gnu//libgmodule-2.0.so /usr/lib/x86_64-linux-gnu//libpango-1.0.so /usr/lib/x86_64-linux-gnu//libcairo.so /usr/lib/x86_64-linux-gnu//libatk-1.0.so ./libc.so /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o /usr/lib/x86_64-linux-gnu/crtn.o /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `lstat64@GLIBC_2.33' /usr/bin/ld: /lib/x86_64-linux-gnu/libmount.so.1: undefined reference to `fstatat@GLIBC_2.33' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_trywrlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_wrlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlinfo@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutexattr_init@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `fcntl64@GLIBC_2.28' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `stat64@GLIBC_2.33' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_create@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `close_range@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `lstat@GLIBC_2.33' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlclose@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_tryrdlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_detach@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_setname_np@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_key_delete@GLIBC_2.34' /usr/bin/ld: /lib/x86_64-linux-gnu/libselinux.so.1: undefined reference to `gettid@GLIBC_2.30' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlsym@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_unlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_setspecific@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlopen@GLIBC_2.34' /usr/bin/ld: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `statx@GLIBC_2.28' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `fstat64@GLIBC_2.33' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_init@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_sigmask@GLIBC_2.32' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dlerror@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_getspecific@GLIBC_2.34' /usr/bin/ld: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `dn_expand@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutex_trylock@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutexattr_destroy@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_attr_setstacksize@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_join@GLIBC_2.34' /usr/bin/ld: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined reference to `res_nquery@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_mutexattr_settype@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_rdlock@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `stat@GLIBC_2.33' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `fstat@GLIBC_2.33' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `pthread_once@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dladdr@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_rwlock_destroy@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libglib-2.0.so: undefined reference to `pthread_key_create@GLIBC_2.34' /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libasound.so: undefined reference to `dladdr1@GLIBC_2.34' /home/user/pascal/GFXterm 2.1c/project1.lpr(24,1) Error: (9013) Error while linking /home/user/pascal/GFXterm 2.1c/project1.lpr(24,1) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode ---------------------------------------------------------------------- robert rozee · 2023-05-02 09:11 Quote from: TRon on May 01, 2023, 01:49:22 pm- you probably only need to add "--trace" (without quotes) to the edit box or are you after the file link.res? cheers, rob   :-) ---------------------------------------------------------------------- TRon · 2023-05-02 10:46 Quote from: Fred vS on May 01, 2023, 06:38:20 pmAre you talking about the trick to use -Fl, -Xr, Xd  and -FD and symlink without extended number extension? And saying it works for you? I am saying that I am investigating if the normal route can be made shorter (meaning that I can compile the required libraries myself instead of the need to copy them over from an older system) and see if it can be done in a bit more civil manner (other then sysrooting etc)). QuoteEven better, give in attachment the zipped files of old libc.so.6 and other files needed for linking? I have no problem zipping up the libraries from an older (debian) system and make them available. But why rely on someone else ? I do not even trust myself In the (FPC) compiler's point of view it is nothing more than cross- compiling to another platform. See for instance https://wiki.freepascal.org/Cross_Compile_to_RasPi_from_Linux (note the instructions to archive files from a raspberry pi and copy them over to your host). ---------------------------------------------------------------------- TRon · 2023-05-02 10:56 Quote from: robert rozee on May 02, 2023, 09:20:49 amis this the output you are after? my apologies for it being so long, you'll see i needed to trim it before the forum software would let me post it! Thank you for having posted your output. Yes, that is the /first/ step of output that helps to determine what the linker does (which files it pick up on from what directory). I am missing the part(s) where it picks up on the correct files though (at first glance it looks to me as a 'normal' compilation) Quotei'm thinking more again about a 'fake' libc.so, no functioning code (or just stubs if needsbe) but the necessary symbols to keep the linker happy. one could then within it have defined the necessary minimum version numbers to match the requirements of your project. Yes, also a possibility according to some online posts but do note that other report that this also could give issues (It goes out of scope for me to repeat those issues here as most go beyond my technical understanding) Quotewhat the linker does NOT know, however, is the minimum versions are for the your project it has just built. for instance, it might be imposing dlopen@GLIBC_2.34 based upon data it has gleaned from libc.so, but your project may only be making use of dlopen functionality that has been present since the 2.1.0 version. Yes, that is how I understand things to be/work as well. ---------------------------------------------------------------------- TRon · 2023-05-02 10:58 Quote from: robert rozee on May 02, 2023, 11:11:08 amor are you after the file link.res? That is indeed another step in the process to determine what the linker actually does. Not entirely what I was looking right now (though it does help) for as the first step (trace) already seem to indicate it picks up on things in a wrong manner. Do note that I myself am not even looking at Lazarus yet but just pure FPC (in order to run we first need to walk  ) edit: I had a closer look. Yes, it seems to pickup on the correct libc. That raises the following question: did you have the units recompiled using the "other" libc ? Note that I am currently facing the exact same issue and am trying to wrap my head around the removal of phthread from libc (in theory it should not matter but afaik you would need to compile/link against libpthreads as well). Note that currently I am experimenting and gain/obtain the information as I go along (slowly). So, please be careful ---------------------------------------------------------------------- robert rozee · 2023-05-02 12:08 Quote from: TRon on May 02, 2023, 12:58:58 pm[...] edit: I had a closer look. Yes, it seems to pickup on the correct libc. That raises the following question: did you have the units recompiled using the "other" libc ? Note that I am currently facing the exact same issue and am trying to wrap my head around the removal of phthread from libc (in theory it should not matter but afaik you would need to compile/link against libpthreads as well). i deleted the lib//x86_64-linux folder from my project folder before building. i assumed this would force a recompile of all the project's units - in my case units 1-5. or do you mean recompile the LCL and all the other units that sit in the lazarus directories? if so, how do i do this? i tried doing a "Run" -> "Clean up and Build..." but it fails to delete most of the files - see attached screenshot. Quote from: TRon on May 02, 2023, 12:58:58 pmSo, please be careful  oh yes, i am being careful! i've had my share of disasters in the past when "rushing in where...". cheers, rob   :-) ---------------------------------------------------------------------- TRon · 2023-05-02 12:18 @robert rozee I don't believe that Lazarus automatically recompiles the FPC units when you rebuild the IDE. My first idea/hunch is to try recompile at least FPC unit cthreads. I have no idea why you seem unable to delete the file(s) as shown. Note that I do not have fpc/lazarus installed using the OS' package manager or otherwise. I have mine installed completely stand-alone not depending on any system paths (except for those that I have manually added to the compiler options). Also note that Lazarus version 2.0.12 is /very/ old (read officially unsupported) ---------------------------------------------------------------------- robert rozee · 2023-05-02 13:20 Quote from: TRon on May 02, 2023, 02:18:35 pmI have no idea why you seem unable to delete the file(s) as shown [...] Also note that Lazarus version 2.0.12 is /very/ old (read officially unsupported) have just updated lazarus to 2.2.6. no obvious changes to the earlier behavior observed when bringing in the old libc.so to the project directory. the files are all created by the installer from the .deb package, which runs as root. hence all the files are 'owned' by root. now i do remember i once accidentally ran the IDE as root, and it created a right mess, so am disinclined to go down that path again in a hurry! will look at creating a VM tomorrow to experiment on. cheers, rob   :-) ---------------------------------------------------------------------- robert rozee · 2023-05-02 13:31 just realized, i don't need to build another VM - i already have a brand new mint 19.3 VM with 2.2.6 installed. tried doing a "Run" -> "Clean up and Build..." on that and it behaved just the same, refused to delete the files not in my project directory. is this perhaps a bug/oversight in lazarus - when trying to delete files in places like /usr/share lazarus should surely be wrapping it in a sudo? not a problem that crops up under windows i'd imagine, so maybe no one has tried/tested it under linux. are you operating as root permanently on your machine? there are some distros that do this. cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2023-05-02 13:44 Quote from: TRon on May 02, 2023, 12:46:01 pmQuote from: Fred vS on May 01, 2023, 06:38:20 pmAre you talking about the trick to use -Fl, -Xr, Xd  and -FD and symlink without extended number extension? And saying it works for you? I am saying that I am investigating if the normal route can be made shorter (meaning that I can compile the required libraries myself instead of the need to copy them over from an older system) and see if it can be done in a bit more civil manner (other then sysrooting etc)). I did fight last night with a older libc.so in the same directory of the project but I get same errors as Robert. And playing with  -Fl, -Xr, Xd  and -FD did not help. One of the problem is, for example, libX11.so of the system is not happy with the older libc.so ( it want methods of last libc.so installed in system). So it seems that all the system must be installed using that old libc.so. Of course it would be better to have the possibility to use a different libc.so to link the program but, at the end, I fear that using a virtual box with a older distro will be easier. That said, if you find the way to do it with a "fake libc.so system", I buy it. Fre;D ---------------------------------------------------------------------- robert rozee · 2023-05-02 14:13 there is also another problem to consider - lazarus 2.2.6 won't run on all older linux distros    i had a go with a mint 7 VM, and none of the three .deb files would even open. while with mint 16 there were dependencies that couldn't be met as 16's update manager wouldn't work. so the 'oldest' distro i can run lazarus on (mint 19.3, presumably 19.0 will also work) is relatively new. given that lazarus is built with lazarus (well, fpc), i can see us "painting ourselves into a corner". today's 2.2.6 will install and run on systems without libc 2.34, but what happens with the next release (or the release after that) when installation itself requires 2.34? at that point it will no longer be possible to do a compile on any older system. in a sense, it is a form of forced obsolescence. so much for the being able to 'compile once, run anywhere' that windows gave us! cheers, rob   :-) ---------------------------------------------------------------------- TRon · 2023-05-02 16:30 Quote from: robert rozee on May 02, 2023, 04:13:30 pmso much for the being able to 'compile once, run anywhere' that windows gave us! I'm currently a bit busy to be able to write a elaborated response but as a quick note: you can always compile Free Pascal and Lazarus manually from source (it isn't that difficult to do) or use FPCDeluxe to do it for you. The experience you described is exactly why I do not use the systems package manager (amongst other things such as strange divide of packages on some distributions). ---------------------------------------------------------------------- MarkMLl · 2023-05-02 20:22 Quote from: TRon on May 02, 2023, 06:30:15 pmI'm currently a bit busy to be able to write a elaborated response but as a quick note: you can always compile Free Pascal and Lazarus manually from source (it isn't that difficult to do) or use FPCDeluxe to do it for you. But the interplay of compiler and source versions can be particularly obscure, and well beyond the abilities of a less-experienced practitioner to work out. MarkMLl ---------------------------------------------------------------------- Fred vS · 2023-05-02 21:55 Quote from: robert rozee on May 02, 2023, 04:13:30 pmthere is also another problem to consider - lazarus 2.2.6 won't run on all older linux distros    ... so much for the being able to 'compile once, run anywhere' that windows gave us! Hum, if I may and afaik, 'compile once, run anywhere' is the slogan of fpc. Re-hum, no it seems to be the slogan of Lazarus not fpc (or maybe both?), sorry. Lazarus is dependent of the widgetset that he uses and indeed, a new Lazarus version that needs last widgetset version could not be compatible with older distros. Here, the dependencies needed at linking for a Lazarus simple empty form ( using the -sh parameter ): Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i INPUT(-lpthread-ldl-lgdk-x11-2.0-lgtk-x11-2.0-lX11-lgdk_pixbuf-2.0- lgobject-2.0-lglib-2.0-lgthread-2.0-lgmodule-2.0-lpango-1.0-lcairo- latk-1.0)GROUP(-lc) And, if I may once again, I have installed last MSEgui + MSEide + fpc on old distros ( + 10 years ) and all is working out-of-the-box and the compiled applications too. Note too that those MSEgui applications compiled on (very) old distros are running perfectly on last Linux distros. Here, the dependencies needed at linking for a MSEgui  multi not-empty forms ( using the -sh parameter ): Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i )INPUT(-lpthread-ldl-lX11)GROUP(-lc) Ok, ok, I am boring, I leave  Fre;D ---------------------------------------------------------------------- dbannon · 2023-05-02 23:32 Quote from: robert rozee on May 02, 2023, 03:31:02 pm..... is this perhaps a bug/oversight in lazarus - when trying to delete files in places like /usr/share lazarus should surely be wrapping it in a sudo? not a problem that crops up under windows i'd imagine, so maybe no one has tried/tested it under linux. No, no , no (I almost did a Thaddy there). Lazarus should never be able to delete files in /usr/.   When Lazarus finds itself in a situation where it's own source files (and obj etc) are in root space, it moves its operations down to user space, in the PCP. So, asking for a sudo never need happen, the situation would never, ever arise .... Davo ---------------------------------------------------------------------- robert rozee · 2023-05-04 09:11 it would certainly seem to be much simpler to have lazarus, from the get-go, install and run in /home/... instead of /usr. amongst other things, it would get around the complexity created when adding new components to the IDE's component bar. but that is another topic! there are hints of a solution here: https://stackoverflow.com/questions/21018216/rewrite-shared-library- undef-symbol-version-of-compiled-object/21059674#21059674: QuoteRemoving version info post-link is infeasible -- these strings are entered into hash tables, and rebuilding these hash tables is too complicated a thing to do with objcopy. What you want to do is create a stub libssl.so.10 with DT_SONAME set to libssl.so.10, which defines all the symbols you need from it, but without any version info. For example, this would do if you only needed the SSL_new symbol: Code: [Select] echo "void SSL_new() { }" > t.c &&  gcc -fPIC -shared -o libssl.so -Wl,--soname='libssl.so.10' t.c Now link your program against this stub library, and it will not require any versioned symbols. The runtime linker will then satisfy this undefined unversioned SSL_new with SSL_new@libssl.so.10 on CentOS, and with SSL_new@Base on CloudLinux. cheers, rob   :-) addendum: tried with a file called test.c containing the following: Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // 2.34 void __libc_start_main() { }void dlsym() { }void dladdr() { }void dlclose() { }void dlerror() { }void dlopen() { } // 2.2.5 void sysconf() { }void sched_yield() { } void wcscoll() { }void strcoll() { } void iconv() { }void iconv_open() { }void iconv_close() { } void setenv() { }void setlocale() { }void nl_langinfo() { } void mbrlen() { }void mbrtowc() { }void wcrtomb() { } void __errno_location() { }void __cxa_finalize() { }  unsigned int towlower(unsigned int i) { }unsigned int towupper(unsigned int i) { }(above code updated 21 may 2023) and compiled with the below gcc commandline to produce a libc.so: Code: [Select]gcc -fPIC -shared -o libc.so -Wl,--soname='libc.so.6' test.c did something, but not what we want! 21 may 2023: produces 486 warnings but no explicit errors, but still fails: Code: [Select]Compile Project, Mode: Release, Target: project1: Exit code 1, Errors: 1 project1.lpr(24,1) Error: Error while linking full list of warnings, etc attached below ---------------------------------------------------------------------- MarkMLl · 2023-05-04 10:53 Quote from: robert rozee on May 04, 2023, 11:11:44 amQuoteWhat you want to do is create a stub libssl.so.10 with DT_SONAME set to libssl.so.10, which defines all the symbols you need from it, When "stub" is used in that context, does it actually mean a linker script? Debian tried that for libusb-0.1, and the result was that anything that tried to load it dynamically (i.e. under explicit program control) also had to be prepared to parse that script in order to determine the name of the actual compatibility library. MarkMLl ---------------------------------------------------------------------- dbannon · 2023-05-11 01:36 As it seems to have quietened down a touch here, below is an updated version of the small table I posted on page one - The issue as we know is that, on Linux system, binaries compiled on a system with glib6-2.34 or later will not work on systems using an earlier glibc6. These Ubuntu and Debian distros use the following glibc6 - Distros that can make binaries that will run irrespective of the version of libc6 - Ubuntu 20.04  - 2.31    Linux Mint 20.3 Debian Bullseye - 2.31Distros that cannot make a binary to run on systems with 'earlier' libc6 - U21.04  - 2.33U21.10  - 2.34  (Impish)U22.04 -  2.35  (Jammy)Linux Mint 21.1Debian Bookworm - 2.36 (release in a few months) Not withstanding the efforts of people in previous posts of this thread, the most practical solution still seems to be to have an old install of, perhaps U20.04, perhaps in a VM, to build release versions of your app. (Sorry, I am not tracking the RPM world, RedHat, as a distro has quite long support ...) Davo ---------------------------------------------------------------------- robert rozee · 2023-05-11 05:29 i've had close to zero success finding a good solution. one nugget of information though, from https://sourceware.org/glibc/wiki/Glibc%20Timeline: Date          Release 2021-08-02    GLIBC 2.34... 2012-03-21    GLIBC 2.15... 2002-01-20    GLIBC 2.2.5 the above suggests to me that the recent version requirements (2.34 or later) are 'breaking' something that had been not broken for a couple of decades. has anyone looked into what changes to the linker might be a solution? (1) a switch that disables embedding ANY minimum version requirement for instance? or (2) a switch that allows setting an explicit version requirement? ie, so you could explicitly set 2.2.5? at the moment it remains that neither the linker nor the library (libc.so.6) has ANY information about what the code it is linking actually requires, and so is enforcing an arbitrary rule. the one source of knowledge - the programmer - is excluded from the decision making process. cheers, rob   :-) ---------------------------------------------------------------------- dbannon · 2023-05-11 06:02 Robert, please look back on page one of this thread. As usual, PascalDragon's posts are authoritative. Davo ---------------------------------------------------------------------- robert rozee · 2023-05-11 08:32 Quote from: dbannon on May 11, 2023, 08:02:32 amRobert, please look back on page one of this thread. As usual, PascalDragon's posts are authoritative. Davo you are referring to the link in reply #6: https://sourceware.org/git/?p=glibc.git;a=commit;h=035c012e32c11e84d64 905efaf55e74f704d3668 "A new symbol version __libc_start_main@@GLIBC_2.34 is introduced because new binaries running on an old libc would not run their ELF constructors, leading to difficult-to-debug issues."? and yet a way of defeating the introduction of this new symbol version exists, insofar as simply compiling on an 'old' VM that uses the 2002 era glibc 2.2.5. does this workaround not prove that the mechanism introduced is ineffective? i would have thought that a better approach would be for any 'new binary' to check the version of libc served up to it, and perform the 'run their ELF constructors' step dependant upon the version of libc found at runtime? now from the point of view of the helpdesk staff, the solution is even simpler: tell the customer to "just download the WindowsTM version of our application. you'll find there was a free WindowsTM CD that shipped with your computer, pop it in the slot and follow the simple onscreen instructions..." cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2023-05-11 10:51 Quote from: dbannon on May 11, 2023, 03:36:20 am... Distros that cannot make a binary to run on systems with 'earlier' libc6 - U21.04  - 2.33U21.10  - 2.34  (Impish)U22.04 -  2.35  (Jammy)Linux Mint 21.1Debian Bookworm - 2.36 (release in a few months) ... Note too that those distros accept only some libraries compiled on those last distros. For example, the library libsndfile.so from earlier distros cannot be used in the last distros mentioned ( and libsndfile.so from last distros does not work on previous distros), so no solution of backward compatibility here. Fre;D ---------------------------------------------------------------------- dbannon · 2023-05-11 12:12 Quote from: Fred vS on May 11, 2023, 12:51:12 pm....... Note too that those distros accept only some libraries compiled on those last distros. For example, the library libsndfile.so from earlier distros cannot be used in the last distros mentioned ( and libsndfile.so from last distros does not work on previous distros), so no solution of backward compatibility here. Hum, I am not sure I like what the core-dev of Linux have done recently. Fre;D Fred, I don't think anyone ever suggested that every  Library is forward compatible.  That would be quite impossible because the new system would not find the new functions in old library that it expects, functions that had not been thought of when the older version of the library was made. A library is expected to be backwards compatible, that is, offer the same services as a earlier version did. Generally, a binary application is expected to be forward compatible, it should run on future systems (because the libraries on that future system are backwards compatible). In this situation, we asking for our binary application to be backward compatible and its NOT. Its an absolute pain in what you sit on and I desperately wish it had not be allowed to happen but it did happen. And its entirely reasonable that it might happen again in the future. Robert - https://forum.lazarus.freepascal.org/index.php/topic,58888.ms g442518.html#msg442518 but you are more than welcome to dig your Windows CD out of the bottom drawer. I wonder what version of Windows it is ? Davo ---------------------------------------------------------------------- Fred vS · 2023-05-11 12:38 Quote from: dbannon on May 11, 2023, 02:12:10 pmFred, I don't think anyone ever suggested that every  Library is forward compatible.  That would be quite impossible because the new system would not find the new functions in old library that it expects, functions that had not been thought of when the older version of the library was made. A library is expected to be backwards compatible, that is, offer the same services as a earlier version did. Generally, a binary application is expected to be forward compatible, it should run on future systems (because the libraries on that future system are backwards compatible). In this situation, we asking for our binary application to be backward compatible and its NOT. Its an absolute pain in what you sit on and I desperately wish it had not be allowed to happen but it did happen. And its entirely reasonable that it might happen again in the future. Of course I dont suggest that a library should be forward compatible. But for more than 10 years now, libsndfile.so was backward compatible, a older libsndfile.so can be used in newer distros. And it is the first time, with those last distros that you you mentioned, that is not the case anymore, libsnfile.so must be compiled on the last distro, otherwise it fails to load. ---------------------------------------------------------------------- ASBzone · 2023-05-11 13:11 Quote from: Fred vS on May 11, 2023, 02:38:30 pmBut for more than 10 years now, libsndfile.so was backward compatible, a older libsndfile.so can be used in newer distros. But that's not the definition of backwards compatibility.  That's the definition of forwards compatibility. As long as the new DLL in the new OS still runs programs that were compiled previously, which reference the old DLL, and they still work when you run that old binary on the new OS, then you have backwards compatibility. That's not what appears to be in place here.  If the app is compiled with the new version is cannot be run, after the fact, on the old version of the OS.   That's not a backwards compatibility issue. ---------------------------------------------------------------------- Fred vS · 2023-05-11 13:23 Quote from: ASBzone on May 11, 2023, 03:11:50 pmQuote from: Fred vS on May 11, 2023, 02:38:30 pmBut for more than 10 years now, libsndfile.so was backward compatible, a older libsndfile.so can be used in newer distros. But that's not the definition of backwards compatibility.  That's the definition of forwards compatibility. As long as the new DLL in the new OS still runs programs that were compiled previously, which reference the old DLL, and they still work when you run that old binary on the new OS, then you have backwards compatibility. That's not what appears to be in place here.  If the app is compiled with the new version is cannot be run, after the fact, on the old version of the OS.   That's not a backwards compatibility issue. Ha, ok, clear now, thanks. What I wanted to note ( how to call this ? ) is that before those last distros mentioned,  programs that dynamically loaded libraries with "loadlibrary()" could load older libraries on new distros. It is not the case for some libraries with those last distros mentioned. ---------------------------------------------------------------------- robert rozee · 2023-05-11 13:34 Quote from: dbannon on May 11, 2023, 02:12:10 pmRobert - https://forum .lazarus.freepascal.org/index.php/topic,58888.msg442518.html#msg442518 but you are more than welcome to dig your Windows CD out of the bottom drawer. I wonder what version of Windows it is ? Quote from: PascalDragon on May 16, 2022, 01:27:26 pmThe issue is that newer libcs have a versioned symbol and according to the ELF spec when a symbol that has a version attached is used then this needs to be referenced as such in the ELF binary so that the dynamic linker can then resolve this using the correct version of the symbol, this implicitly also means that if you try to run a binary that uses such a versioned symbol on a system where the corresponding library does not have this symbol with the suitable version (or none at all) then the binary simply won't load. It's as if you'd use a symbol that doesn't exist at all. Davo: i don't see what you are getting at. PascalDragon is just stating the mechanism used, and on that point we all more-or-less seem to agree. we already know how to 'defeat' it, by building our binaries using an 'old' distro. however, this solution has a limited lifespan if you like, as at some point there will come along a lazarus/FPC that will no longer run on our 'old' distro. at that future time the libc authors can not be 'held accountable', because we are trying to use such an old distro as part of our build process - they will have plausible deniability. i also understand why this is likely being done, it is an attempt to shed some of the load of maintaining backward compatibility. if the libc authors came out and said this openly, then that wouldn't be so bad. if the authors said " libc.so.6 is old and outdated, we are going to abandon it completely and only work on a new, better libc.so.7 " then i would applaud their bold decision. but instead we see what is essentially a flaw quietly introduced that will lead to an eventual obsolescence/failure that can be blamed (if blaming is needed) on the end user. without binary application compatibility, linux on the desktop will die. or everything will be written in python. cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2023-05-11 13:47 Quote from: Fred vS on May 11, 2023, 03:23:01 pmQuote from: ASBzone on May 11, 2023, 03:11:50 pmQuote from: Fred vS on May 11, 2023, 02:38:30 pmBut for more than 10 years now, libsndfile.so was backward compatible, a older libsndfile.so can be used in newer distros. But that's not the definition of backwards compatibility.  That's the definition of forwards compatibility. As long as the new DLL in the new OS still runs programs that were compiled previously, which reference the old DLL, and they still work when you run that old binary on the new OS, then you have backwards compatibility. That's not what appears to be in place here.  If the app is compiled with the new version is cannot be run, after the fact, on the old version of the OS.   That's not a backwards compatibility issue. Ha, ok, clear now, thanks. What I wanted to note ( how to call this ? ) is that before those last distros mentioned,  programs that dynamically loaded libraries with "loadlibrary()" could load older libraries on new distros. It is not the case for some libraries with those last distros mentioned. Ooops, sorry, my fault, the guilty is in libsndfile.so. So, once again, sorry for the noise, old libraries (apart for some with bug or bad design) can be loaded on those distros mentioned. ---------------------------------------------------------------------- ASBzone · 2023-05-11 13:57 Quote from: robert rozee on May 11, 2023, 03:34:04 pmwithout binary application compatibility, linux on the desktop will die. or everything will be written in python. Binary application compatibility exists.  Just not in the direction you want, in this case. It's also interesting that you bring up the example of Python, which is still dealing with the mess of v2 and v3, years later. Nonetheless, there continue to be different views on the ramifications of what was done, and there are others who feel about the matter similarly as you do:  https://developers.redhat.com/articles/2021/12/17/why- glibc-234-removed-libpthread# ---------------------------------------------------------------------- PascalDragon · 2023-05-11 21:15 Quote from: robert rozee on May 11, 2023, 03:34:04 pmwithout binary application compatibility, linux on the desktop will die. or everything will be written in python. Linux systems are more geared towards open source and compiling applications on the systems where you need them (this includes package managers as there the software is compiled for the current state of the packages as well) thus binary compatiblity to the extend that you expect is usually less of an issue. Then again you don't necessarily expect to run an application that was programmed for Windows 10 on Windows 7 or even Windows XP. It might work if the author handled it correctly, but it's in no way guaranteed. This is the same situation here: an application compiled for a newer distro doesn't necessarily work on an older one. ---------------------------------------------------------------------- dbannon · 2023-05-11 23:29 Quote from: Fred vS on May 11, 2023, 03:23:01 pm libsndfile.so ... What I wanted to note ( how to call this ? ) is that before those last distros mentioned,  programs that dynamically loaded libraries with "loadlibrary()" could load older libraries on new distros. It is not the case for some libraries with those last distros mentioned. But Fred, why not just use the newer version of the library, as the distro builders intend ?  You use Debian, in Bullseye its 1.0.31-2 and in the forthcoming Bookworm, its 1.2.0-1. Its there and its the one that Debian will have subjected to extensive testing. Davo ---------------------------------------------------------------------- dbannon · 2023-05-12 00:11 Quote from: robert rozee on May 11, 2023, 03:34:04 pm........ i also understand why this is likely being done, it is an attempt to shed some of the load of maintaining backward compatibility. .... Yes, to some degree that is the case. It must, over time, happen. What is surprising really is not that there is an non-backward compatibility issue right now, when you think about it, we should be surprised its worked at all over the last few years. No one has ever set that backward compatibility requirement in an application as a requirement or a guarantee or even a performance measure. We were, for a few years, lucky ! Quote from: robert rozee on May 11, 2023, 03:34:04 pm without binary application compatibility, linux on the desktop will die. or everything will be written in python. Sorry Robert, but that is, frankly, nonsense. * The vast majority of linux application code people use comes from the distribution's repo. Its built from source provided by developers but, importantly, its built using the forerunner of that distribution release. There is no forward or backward comparability issues. Where its an issue is where developers distribute packages of their application. Again, if you are to follow eg Debian's rules, you would build a specific package, in the right environment, for each and every distribution you target. Few people do that because we have all discovered, through testing, we can make general purpose packages. For example, my app, tomboy-ng, I submit source code to Debian, they use it to build specific Bullseye and Bookworm packages on, respectively, Bullseye and Bookworm. I also make packages (on github) for people who want the most current release, as generic deb packages (and rpms). I build and package them on an Ubuntu 20.04 machine and I know, because of testing, they will run on even an U18.04 or Buster through to U23.04 and Bookworm. I also release a PPA version, again, built on a U20.04 Launchpad machine. Launchpad allows me to either rebuild for later Ubuntu releases or to 'copy' the binary. I know, from testing, that 'copy' works fine, U20.04 through to U23.04. (*) sorry if I have offended with use of word 'nonsense' but it does annoy me when people say "unless {insert mildly annoying issue} is fixed, the world will end". The fact is, its entirely manageable. Annoying but manageable ! /quote] Davo Ref https://github.com/tomboy-notes/tomboy-ng/releases/tag/v0.36c https://packages.debian.org/search?searchon=sourcenames&keywords=tombo y-ng https://launchpad.net/~d-bannon/+archive/ubuntu/ppa-tomboy-ng ---------------------------------------------------------------------- Fred vS · 2023-05-12 10:51 Quote from: dbannon on May 12, 2023, 01:29:31 amQuote from: Fred vS on May 11, 2023, 03:23:01 pm libsndfile.so ... What I wanted to note ( how to call this ? ) is that before those last distros mentioned,  programs that dynamically loaded libraries with "loadlibrary()" could load older libraries on new distros. It is not the case for some libraries with those last distros mentioned. But Fred, why not just use the newer version of the library, as the distro builders intend ?  You use Debian, in Bullseye its 1.0.31-2 and in the forthcoming Bookworm, its 1.2.0-1. Its there and its the one that Debian will have subjected to extensive testing. Davo Hello Davo. I will try to explain the problem. If you take the last version of distro XUbuntu 23.04, here are the dependencies of libsndfile.so: Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ~> ldd /usr/lib/x86_64-linux-gnu/libsndfile.so         linux-vdso.so.1 (0x00007fffa39f9000)        libFLAC.so.12 => /lib/x86_64-linux- gnu/libFLAC.so.12 (0x00007f6c0dbe1000)        libvorbis.so.0 => /lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f6c0dbb4000)        libvorbisenc.so.2 => /lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f6c0db09000)        libopus.so.0 => /lib/x86_64-linux- gnu/libopus.so.0 (0x00007f6c0daae000)        libogg.so.0 => /lib/x86_64-linux-gnu/libogg.so.0 (0x00007f6c0daa4000)        libmpg123.so.0 => /lib/x86_64-linux-gnu/libmpg123.so.0 (0x00007f6c0da46000)        libmp3lame.so.0 => /lib/x86_64-linux- gnu/libmp3lame.so.0 (0x00007f6c0d9d0000)        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6c0d8e7000)        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c0d600000)        /lib64/ld-linux-x86-64.so.2 (0x00007f6c0dcec000)  There are 2 problems with the dependencies:  1) libc.so.6 = same problem as with fpc link: it was linked with last version of libc.so.6 and then will not work on previous distros.  2) libFLAC.so.12 = this is a new flac version, previous distros used libflac.so.8 ( strict version number needed ). So, not compatible with my religion "out-of-the-box", if I want give in the release a unique libsndfile.so for new and old distros. If I use a old version of libsndfile.so compiled with old libc.so.6, we know that libc.so.6 is backward compatible, so it is ok. But it is not the case for libflac.so.8 that is strict and does not exist in XUbuntu 23.04 ( only exist libflac.so.12 ). Of course you may create a symlink  libflac.so.8 -> libflac.so.12 but it is bricolage and not out-of-the-box. So, my solution is to recompile libsndfile.so on a older distro ( for the libc.so.6 problems ) and build statically the deps inside the library. Fortunately there is a great project that gives the script to do this (wow, it works out-of-the-box): https://github.com/bastibe/libsndfile- binaries/blob/master/linux_build.sh Of course that new libsndfile.so is bigger ( 2.5 megas vs 800k ) but no more possible problems of dependencies, all is in the library: Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ~> ldd /home/fred/StrumPract_linux64/lib/Linux/64bit/LibSndFile-64.so        linux-vdso.so.1 (0x00007ffcf01d0000)        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0ff5717000)        libmvec.so.1 => /lib/x86_64-linux-gnu/libmvec.so.1 (0x00007f0ff561d000)        libc.so.6 => /lib/x86_64-linux- gnu/libc.so.6 (0x00007f0ff5400000)        /lib64/ld-linux-x86-64.so.2 (0x00007f0ff5adb000)  So, for the release of StrumPract, the user has 2 choices: -1) Or use the library installed on system:      Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  DynLibs.LoadLibrary('libsndfile.so.1');     In that case LoadLibrary() will search in all the library-directories defined by the system. -2) Or use the libraries given in release StrumPract/lib         Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  DynLibs.Lo adLibrary('/directory_of_release_lib/custom_libsndfile.so');     In that case LoadLibrary() will try to load only the path of library defined). At first loading, if library of system did not load, it will try to load the library from release. And in setup, user may decide what library use for loading. Fre;D ---------------------------------------------------------------------- robert rozee · 2023-05-12 10:54 Quote from: dbannon on May 12, 2023, 02:11:44 amSorry Robert, but that is, frankly, nonsense. * The vast majority of linux application code people use comes from the distribution's repo. Its built from source provided by developers but, importantly, its built using the forerunner of that distribution release. There is no forward or backward comparability issues. (*) sorry if I have offended with use of word 'nonsense' but it does annoy me when people say "unless {insert mildly annoying issue} is fixed, the world will end". The fact is, its entirely manageable. Annoying but manageable ! no offense taken... and you are quite right - i was over-reacting in my comment      i just find it so frustrating that such a 'visually small' change (even if made for good reasons) can prove so difficult (for me) to work around. i do realize that what i call a 'visually small' change is in fact just the very tip of a very large series of updates and improvements under the hood of libc.so.6 that are probably long overdue. the sorts of applications i write using lazarus/FPC are generally of interest to a quite limited audience, with maybe just a few hundred users, and usually evolve based upon user feedback. as such they are not the sort of things that would fit in with a distribution's repo, far more suitable for github or similar. and the users are not at a level where they can install lazarus and compile something themselves, while most would balk at the scale of something like a docker container, appimage, flatpak, etc. this leaves limited options open - and the further i dig, the less confidence i have that building binaries on an old distro is a good long-term solution. i get the feeling that window is slowly closing. Quote from: dbannon on May 11, 2023, 02:12:10 pmI wonder what version of Windows it is ? for generating win32 applications i use an XP VM. cheers, rob   :-) ---------------------------------------------------------------------- dbannon · 2023-05-14 02:42 Quote from: robert rozee on May 12, 2023, 12:54:31 pm...... this leaves limited options open - and the further i dig, the less confidence i have that building binaries on an old distro is a good long-term solution. i get the feeling that window is slowly closing. .... for generating win32 applications i use an XP VM. I would think your Linux solution would be exactly the same as your Windows solution. Ubuntu 20.04 is supported for several years yet, run it in a VM as a dedicated build environment, always a good idea IMHO. Davo ---------------------------------------------------------------------- dbannon · 2023-05-14 02:58 Fred, sorry, I really don't quite understand your problem, currently in an aeroplane and difficult to concentrate. But I am guessing its similar to what this thread is about. When we find we can build binaries that run on a wide range of systems, we should feel lucky ! Sigh ... Davo ---------------------------------------------------------------------- robert rozee · 2023-05-20 18:04 a little more back story, gleaned from: https://codebrowser.dev/glibc/glibc/csu/libc-start.c.html lines 392-397: Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i /* Starting with glibc 2.34, the init parameter is always NULL.  Older   libcs are not prepared to handle that.  The macro   DEFINE_LIBC_START_MAIN_VERSION creates GLIBC_2.34 alias, so that   newly linked binaries reflect that dependency.  The macros below   expect that the exported function is called   __libc_start_main_impl.  */ line 223-228: Code: C  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i /* Note: The init and fini parameters are no longer used.  fini is   completely unused, init is still called if not NULL, but the   current startup code always passes NULL.  (In the future, it would   be possible to use fini to pass a version code if init is NULL, to   indicate the link-time glibc without introducing a hard   incompatibility for new programs with older glibc versions.) and from an article someone (i believe) previously linked: https://developers.redhat.com/articles/2021/12/17/why- glibc-234-removed-libpthread Quote Jeremy Andrews 9 months ago It's worth noting that this change breaks some older applications that were compiled against glibc earlier than 2.34. It's very hit and miss, but I have encountered older applications that don't work at all on 2.34 and work fine on 2.33, and any kind of attempt to debug shows that things are getting gummed up in futex-internal or that pthread_mutex_lock isn't working. Mostly it seems to happen where stack protection is involved. these three excerpts tell us: 1. the parameters to _libc_start_main (or more correctly LIBC_START_MAIN()) include init and fini. these are entry points to the user (application) program (not 100% sure about fini). on pre-2.34 versions of libc, it is not valid for init to be NULL. 2. libc version 2.34 and later can handle init being set to NULL, and someone thinks this can be used in future as some sort of version signalling. exactly how, i am not quite sure, as any application program that set init to NULL would be none-too-bright. it would be similarly reckless to set fini to point to anything other than valid code. 3. compiling an application on an 'old' linux distro seems to be no guarantee that it will work with libc 2.34 and later - at least according to one Jeremy Andrews. this leads me further down the path that our current 'best solution' is a poor one and libc is only sort- of compatible with older binaries. i wonder if one could use a variation on the concept of UPX, to meld together two quite different blocks of binary code. your application (ELF) binary would be treated as just a block of data packaged up with small 'check and patch' utility - much like a UPXed binary contains an unpacker and the compressed user application. the utility portion would check the libc version installed, and then either run the application from RAM, or, if needsbe, patch then run the application. the  'check and patch' utility could itself be written in pascal as a console application. this doesn't get around the need to build an 'old' binary, but at least gives some assurance that the correct binary ('old' or 'new') is run. it is 6am here, so now time for bed... i hope what i've written makes sense in the light of day! cheers, rob   :-) ---------------------------------------------------------------------- TRon · 2023-05-21 11:43 Well, just as others such as Fred Vs mentioned not one of the options to influence the linker seem to be working as intended (at least I was unable to see any changes in the behavior of the linker). Since I had installed an older debian distro (squeeze) in a VM, I copied some files from there to a separate directory named linklibs (in my project directory on a recent (bookworm) setup): - ld-2.11.3.so - ld-linux-x86-64.so.2 - libc-2.11.3.so - libdl-2.11.3.so - libm-2.11.3.so - libpthread-2.11.3.so I also copied them with removing the version numbers (creating proper links can be done later). In case wondering how to know which files to copy: pass verbosity option to the linker. Then I copied some example code from the wiki, making use of libc (cthreads to be exact): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Program ThreadTest; {test multi threading capability } uses  {$ifdef unix}cthreads, {$endif} sysutils; const  threadcount = 10;  stringlen = 1000; var finished : longint; threadvar thri : ptrint; function f(p : pointer) : ptrint;var s : ansistring;begin  Writeln('thread ',longint(p),' started');  thri:=0;  while (thri