The freepascal program is compiled on Debian 13.
Lazarus: 4.0
Freepascal Version: I can not found.

Trying to run the program on Debian 11 shows the error

[prgname]: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found (required by [prgname])

? ? ?

there was an incompatible update in GLIBC.

You have to compile against old GLIBC to run on old Linux.

Have a look at tools like "distrobox" to get a build-environment.

Hi,

This isn't a Free Pascal issue, this is a "welcome to Linux" issue.

Your code, or code that gets included in your software either by Lazarus or Free Pascal as part of their respective libraries, uses functionality that are only available in glibc 2.34 or newer. It won't work on Debian 11, that shipped with glibc 2.31.

Without knowing more about what your project tries to do, it's not really possible to tell, if there are any easy solutions to get around this, apart from upgrading the target system...

Charlie

...or compiling on the lowest version you intend to support, or creating programs not using libc (which is possible with FPC even when targetting Linux, but with limitations which make this theoretical option impossible for Lazarus applications).

Tomas

This sounds complicated.
I try to avoid anything that makes my work more complicated.

On 32 Bit Linux Systems that worked perfectly for more than 20 years. The Software runs on more than 100 different Computers with different Linux versions.

Now with 64 Bit there are these Problems.

What kind of application is that - is it a Lazarus (GUI) application, or you just use Lazarus as your IDE? Is it a multi-threaded application?

Tomas

What kind of application is that - is it a Lazarus (GUI) application, or you just use Lazarus as your IDE? Is it a multi-threaded application? Tomas

No GUI on more than 100 Computers (except on the compiling Computer, which runs fine), I use the Framebuffer to set the Pixel directly. 800 x 600 Pixel Screen.
No multi-threaded application.
Just use Lazarus as the IDE.

On the compiling Computer on KDE the 800 x 600 screen is copied frequently into an X Window. There the X Libraries are load at runtime dynamically. It runs all fine.

When there is no KDE (more than 100 computers outside) then there is a simple, plain Linux without any GUI.

I use the openssl and libcrypto library load at runtime dynamically. I think that should be ok and has nothing to do with this issue.

Compiled on Debian 13 in a KDE environment, runs fine. Debian 13 (without KDE) runs fine
Debian 11 (without KDE) does not work as already described. Debian 12 (without KDE) works.

Can I put an older libc.so.6 somewhere and say fpc that it should use that library for compiling?

The question is - do you really need to use libc at all then?

Tomas

What kind of application is that - is it a Lazarus (GUI) application, or you just use Lazarus as your IDE? Is it a multi-threaded application? Tomas

A very simple

writeln( 'hello' );

works!

I have to search what causes the error in my (huge) software.

https://forum.lazarus.freepascal.org/index.php?topic=38069.0

Comment: August 26, 2017, 07:18:24 pm

Library libc usage and unit libc usage are totally different subjects. Unit libc is deprecated for a long time (since it is basically an one off header for a 15+ old libc), library libc not.

May be this is the issue.

I assume that you don't use this deprecated unit libc, do you? However, AFAIK, Lazarus adds a couple of units like cwstrings, cthreads, etc., to applications automatically, and these imply use of libc.so even without using unit libc. Unit cwstrings may be relevant for working with UnicodeStrings - does your application use UnicodeStrings / WideStrings? If not, you might be able to remove that dependency. If you use them, you might still try using unit fpwidestring instead.

Tomas

By now unit libc I can not find on the fly.

Units cwstrings, cthreads, UnicodeStrings, etc. I don't use.

Most things I write by myself, except the ssl library and the crypto library.

I have to test step by step what causes the issue.

The same huge (more than 100 units, mostly self written) Program in 32 Bit works perfect as I mentioned already.

Obvious question was Debian 11,
version 'GLIBC_2.34' could be compiled from source or installed via a backports repo for debian 11, did OP try that?

On Wed, Jun 3, 2026 at 7:52 AM Rainer Stratmann via fpc-pascal <

Warren Postma wrote

Obvious question was Debian 11, version 'GLIBC_2.34' could be compiled from source or installed via a backports repo for debian 11, did OP try that?

That potential solution isn't very practical if the issue appears on a machine owned by someone else than the OP (in particular someone using the program provided by OP)...

Tomas

Warren Postma wrote

Obvious question was Debian 11, version 'GLIBC_2.34' could be compiled from source or installed via a backports repo for debian 11, did OP try that?

No, how does it work exactly?
I think this is not easy.

Searching for "debian 11 backports glibc_2.34" gives no easy solution, but a bunch of sites with the same problem.

The software runs in root mode. It is more or less the only user software that runs on the computer. Nevertheless, it is probably not practicable.

On Wed, Jun 3, 2026 at 8:05 AM Tomas Hajny via fpc-pascal <

Welcome to linux. Google “containers” and “snaps” and “flatpaks”

It is not that complicated as it sounds to be: An environment for "Debian 11" is created by a single command. Afterward you enter that environment and install FPC/Lazarus there. You can compile your source in the third step. The environment does share most of the host's file system - especially your /home.

As an alternative you can use an old machine to compile.

It is caused by the incompatible change in GLIBC 2.34. The distros before and after are compatible again.

You always might run into unexpected trouble when running a binary compiled on modern distro when running it on old distro.

I made a little writeln( 'Hello' ); Testprogram with all units from the big Program.

The unit dynlibs causes the issue.

If I compile it without dynlibs then it runs.

That's not a surprise.

Using dynlibs links your program to the C library, which is needed to load other C dynamic libraries.

So as soon as you use it, your program depends on the C library, and you need to deal with C library versions.

Michael.

Is it possible to put an older libc in an own directory and tell the compiler to link to it?

I suppose that by manipulating the linker search path to an older version, you can do it. We do it with Delphi at work, no reason why FPC would not be able to do it.

Michael.