I have used Lazarus 2.2.6 with fpc 3.2.2 on an Ubuntu 22.04 PC (recently dist-upgraded from 20.04) to modify a video handling command line utility I started back in 2018.
It uses calls to ffmpeg to do the actual video stuff and it was originally built using earlier versions of Lazarus (2.0.12) and FPC (3.0.4), but now I fixed a few issues using an updated installation with the latest versions.

The program I have built runs fine on that PC (an HP Elitebook w8440) but when I move the executable from this machine to my Ubuntu 20.04 server PC I get this when I try to run it:

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

So it seems like somehow the program uses some underlying function in the Linux system which I have no control over...

What can I do in order to make the executable portable to other linux machines with the same CPU architecture???

I do not know what the library libc.so.6 even does....

Bo Berglund wrote

I do not know what the library libc.so.6 even does....

It is the C library that one or more of units/libraries you are linking against require.

The issue is that you are making a binary on a newer version of glibc (the C library) than the system you want to run it - glibc (and most libraries really) is *backwards* compatible but not *forward* compatible: you can only run binaries on a system that uses the same or older versions of the library/libraries but not newer.

The solution is very simple: build the binary on the oldest version of libraries you want to support - with the easiest approach being to download an ISO of some older version of a distro that has the oldest versions you want to support. For example AppImage suggests using at most the oldest still supported version of Ubuntu (e.g. Bionic Beaver from 2018).

This is not unique to Lazarus or FPC, BTW, it is the same for any language and program that links against shared libraries on Linux.

Kostas

On Fri, Mar 17, 2023 at 8:18?AM Kostas Michalopoulos via lazarus <

Some portability is obtained if the libraries are linked as "static" . If "dynamic" linking is selected , during execution of the program , the "same" library should be in the executing computer .

Mehmet Erol Sanliturk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230317/233f77f8/attachment-0001.htm>

Mehmet Erol Sanliturk wrote

Some portability is obtained if the libraries are linked as "static" . If "dynamic" linking is selected , during execution of the program , the "same" library should be in the executing computer .

How is this accomplished in Lazarus?

Does this change happen randomly or is it connected to the major Ubuntu releases like going from 20.04 to 22.04 rather than just keeping 20.04 up-to-date?

It implies having to build applications on as old a system as ever possible, maybe using 16.04 or earlier just for making apps that can run on all systems, is that really true?

It makes no sense to me...

And from https://wiki.freepascal.org/Lazarus/FPC_Libraries ------------------------------------------------------------------------------ Static linking

FPC compiles and links a static executable by default. That means it tells the linker to put all .o files of the project and all packages into one big executable.

Advantages:
No external dependencies.
Disadvantages:
No code is shared between different programs on the same computer. You can not load/unload a plugin.
-------------------------------------------------------------------------------

This idea was always why I liked Delphi when it came along in 1995 or so, just build an executable and it could be run everywhere. This is also why I liked FreePascal when it appeared because I did not need to bother with distributing extra files all over the place.

So why has it changed now and how can I get around it? Developing on an up-to-date system should ensure the output could work everywhere, but not so now it appears....

I cannot find any setting for this in Lazarus.

Notice: This is a command line utility so it needs no access to any GUI components at all...

You need to change the units that refer to other libraries so they use static linking.

Does this change happen randomly or is it connected to the major Ubuntu releases like going from 20.04 to 22.04 rather than just keeping 20.04 up-to-date?

It is unpredictable, but will mostly happen in major releases of linux distributions.

It implies having to build applications on as old a system as ever possible, maybe using 16.04 or earlier just for making apps that can run on all systems, is that really true?

No, this will not help you, as then you will have another problem: old libraries installed on such systems may not exist on newer systems.

It makes no sense to me...

Why not ?

It's perfectly simple. Distributions changed the libraries which they ship, and the libraries are no longer compatible.

FPC has not changed. It still works the same.
Everything that is under control of FPC is linked statically.

But a complex GUI system like the LCL uses GTK/GDK/Qt and other libraries, and those are dynamic, external libraries over which FPC or lazarus has no control.

If you use a unit that relies on LibC somewhere, you automatically depend on the libc version.

Developing on an up-to-date system should ensure the output could work everywhere, but not so now it appears....

No-one can ensure this. It was never so. It used to be worse in the past.

Distributions change, and sometimes break binary compatibility. This means you must cater for that.

There are roughly 2 ways:
- Compile on a system that has the correct version of libraries as on the target computer.
- Distribute the needed libraries with your executable.

I cannot find any setting for this in Lazarus.

This cannot be solved with some setting.

Notice: This is a command line utility so it needs no access to any GUI components at all...

You use libc through some unit that is included in your sources. The libc library on both systems you tested on differ too much, that is why you have the error.

Michael.

On Fri, Mar 17, 2023 at 10:07?AM Bo Berglund via lazarus <

Please study fpc.cfg file structure , and Lazarus IDE linking options . On my computer , neither FPC nor Lazarus are installed .

There is an option to specify either dynamic linking or static linking of libraries .

When static linking is selected , it is necessary to have static linkable libraries ( *.a )
of used parts , i.e. , dynamic linkable libraries ( *.so.* ) can not be used for
static linking .

https://www.google.com/search?q=lazarus+static+linking+of+libraries&sxsrf=AJOqlzXTPuAEwc2JkAaon6mLwAvBM-kn5A%3A1679053415469&ei=Z1IUZL2NHP-Qxc8PqvqOuAM&ved=0ahUKEwj93Iyz8eL9AhV_SPEDHSq9AzcQ4dUDCA4&uact=5&oq=lazarus+static+linking+of+libraries&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQAzIFCCEQoAE6BwgAEB4QsAM6BAgjECc6BggAEBYQHjoICAAQFhAeEAo6CAgAEBYQHhAPOgUIABCRAjoFCAAQgAQ6BwguEIAEEAo6BwgAEIAEEAo6CgguEIAEENQCEAo6CAgAEIAEEMsBOgsILhCABBDUAhDLAToICC4QgAQQywE6BQguEIAEOgsILhCABBDHARCvAToKCAAQgAQQFBCHAjoHCAAQDRCABDoICAAQBRAeEA06BAghEBU6BwghEKABEApKBAhBGAFQpBdYi8IBYIHJAWgDcAB4AIABxwGIAcYikgEEMC4zNpgBAKABAcgBAsABAQ&sclient=gws-wiz-serp

lazarus static linking of libraries

Comparison of Linux and Windows is not a fruitful action , because they do not have much similarity
other than being operating systems .

Mehmet Erol Sanliturk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230317/1fa96a41/attachment.htm>

This aplication is a console (i.e NO GUI) application and it only uses these units:

videosplitcmb.lpr:

uses

  {$IFDEF UNIX}
    cthreads,
  {$ENDIF}
  Classes,
  { you can add units after this }
  sysutils,
  utils,
  runthread;

and

utils.pas:

uses
Classes,
SysUtils,

  Process;

What is complex here?

If you use a unit that relies on LibC somewhere, you automatically depend on the libc version.

Since I am only using FPC units, how can I know???

I checked out the project into another Ubuntu 20.04 device with Lazarus/FPC available.

Project compiled just fine and this binary runs on 20.04 and 22.04...

Well, since I have *not* added any units except what is supplied by FPC/Lazarus I don't understand what this means for a simple command line utility which uses TProcess to start instances of ffmpeg....

Bo Berglund via lazarus schrieb am Fr., 17.
M?rz 2023, 13:54:

Your code uses threads and on *nix systems that requires the C library.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230317/6680a33f/attachment.htm>

Mehmet Erol Sanliturk via lazarus schrieb
am Fr., 17. M?rz 2023, 12:58:

Depending on the used units static linking is simply not an option. E.g. the database units load the database libraries dynamically and thus the C library must not be linked statically then.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230317/01f3d7ee/attachment-0001.htm>

cthreads. The name says it all: C threads. It uses the C library.

See:

https://www.freepascal.org/docs-html/rtl/cthreads/index.html

You want to say that you don't even know what the units do that you are using ?

You have no idea how scary that is to me...

Michael.

On Fri, Mar 17, 2023 at 4:19?PM Sven Barth via lazarus <

You are right .
Interdependency of libraries should be taken into consideration .

When static linking is not possible , it is necessary to compile the program in question in the
operating system version causing incompatibility with the other version of the operating system
where the program is compiled and working successfully .

Another point to consider and study is the procedures , conventions and practices used in
the generation of Linux distributions .

Mehmet Erol Sanliturk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230317/1c2724d0/attachment.htm>

Ok, my code does in fact NOT use threads but that is a standard uses clause that gets inserted in all new projects created in Lazarus...

Anyway, on the Ubuntu 22.04 machine I now commented out cthreads and rebuilt the application, then copied the binary over to the Ubuntu 20.04 system where it previously did not run.

Result: It does no longer throw this error!

Thanks a lot for the suggestion!

Regards, Sven

No, I wanted to say how could I know which *units use* the c library that triggers the failure in order to do what they are doing, which I am fairly certain I do know...

Sven Barth wrote

Depending on the used units static linking is simply not an option. E.g. the database units load the database libraries dynamically and thus the C library must not be linked statically then.

glibc officially highly discourages static linking anyway.

As a sidenote, with gcc it is easy to cherry pick which libraries will be linked statically and which dynamically, but from what i can tell FPC doesn't seem to provide such an option - there is only an all or nothing approach as FPC generates its own linker scripts. It'd be useful if there was a way to explicitly specify (e.g. via command line options) which libraries are meant to be linked statically (and/or the opposite) regardless of $linklib usage (as libraries can come through unit you depend on indirectly - e.g. i might want to statically link SDL but not X11 or glibc).

Kostas

when I try to run it: videosplitcmb: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by videosplitcmb)

There was a discussion and related bug report on this issue:

https://forum.lazarus.freepascal.org/index.php/topic,58888.0.html https://gitlab.com/freepascal.org/fpc/projects/-/issues/3