Linux:Deploy LazAplication

[mirce.vladimirov]

Hi,
Under OpenSuSE 15.6 Leap I created a functional aplication for use under Linux but when I copy the binary it reports an errorr :
 

./myLazApp: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./myLazApp) ]

the users computer is a OpenSuSE 15.0
I tried with another user's Centos7 , got the same message.
I guess it will be the same if i try to install it on any other distro, Ubintu, Arch, Mint, etc etc etc...

But...
Lazarus and FPC are also binaries, right ?
To install Lazarus on any Linux you need these rpm's 

• fpc-3.2.2.2.1.x86-64
• fpc-src-3.2.2.2.1.x86-64
• lazarus-3.4.0.x86-64

which also contain binaries, right ? It suppose to work no matter what Linux are you using.
You just download it, install it and it just works.
Well, that's exactly what I would like.

How can i do the same with my binaries ?

[Handoko]

I ever had same issue long ago. That happened because I was running the binary on a several-years-older Linux release. The solution for me was easy, I downloaded and manually rebuild my Lazarus from the source on the machine and using the Lazarus to recompile the program.

I remember there were some discussions about GLIBC issue some months or maybe a year ago. Maybe there you can find some information you need.

[TRon]

as mentioned by Handoko, newer linux version carries a newer linked to incompatible version of the clib and as a result your applications compiled on a system using the newer libc version do not run anymore on older distributions.

There is indeed a complete dedicated thread to that topic (not behind a normal computer so try search yourself, i'll try post it later) but as an alternative there is a experimental workaround in FPCUpdeluxe that allows to link against older libc versions that are compatible with older distributions (it is a special option inside the setup + settings).

So either do as Handoko suggested or you could use the FPCUpDeluxe approach.

[MarkMLl]

I'm a bit uncomfortable discussing specific OS etc. versions, so will defer to anybody who has more appropriate comments.

The problem is that when a unix linker builds a final binary, it resolves all symlinks to point to the ultimate .so (shared object) library.

For some reason, your program is pulling in (g)libc, and that- on the machine doing the compilation- is either a symlink or it is a linker script textfile. Whatever the linker resolves that to on the development system doesn't exist on the target system

Your options amount to one of:

* Find out why your binary is referencing (g)libc, and removing it.

* Set up a VM or Docker container based on the target system, and building in that.

* Update the target system to the same OS used by the development system.

* Run the application in a VM or container on the target system.

* Set up an appropriate symlink.

* Fiddle with LD_LIBRARY_PATH.

That would be my rough order of preference. But in any event I suggest that the best way of attacking this is finding out why (g)libc is being loaded, I've not checked but I don't thing that FPC or the Lazarus IDE link to that directly (which answers another of your questions)

MarkMLl

[mirce.vladimirov]

First of all, thank you for your answers.

Am I getting a wrong picture about this ?

We have something in common, me and FPC/Lazarus developers: We both create binaries, and these binaries are for use on an unknown Linux environment, one can't really know the user's Linux environment.

Difference is that fpc/lazarus binaries work on destination computer, Lazarus Download page only offers choice between DEB's or RPM's, there is no choice to choose older and newer GLIBC. And there is nothing in the README.txt on that.

Lazarus for Linux contains binaries, but WORKS and not complain about glibc or Linux version on your computer.
1.download (3 files: fpc, fpc-source, lazarus)
2.install binaries (i wont build rpm's but copy/paste my binaries instead of install)
3.work, no complains about Linux version or GLIBC

That's what i want for my binaries, do the same like Lazarus package :
download, install, work
download, install, work
download, install, work
....

So I think to myself, if FPC/Lazarus is working the wanted way , without any (or minimal) tricky workarounds then maybe there is hope.

As I said, am I getting a wrong picture about this ?

[mirce.vladimirov]

I did a workaround, for now it's a good one.

1. From the OpenSuSE 15.6 (newer version of OS, higher GLIBC) i targziped-ed the entire /lib64.
2. Copied it to the older OpenSuSE 15.0 into a safe folder called /tmp/safenewfolder
3. In that folder I untargziped it
4. Placed my binaries in the same folder.
6. from a bash script invoke my application like this :

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

1. /tmp/safenewfolder/ld-linux-laz.so --library-path /tmp/safenewfolder ./MyLazApp parameter1 parameter2 parameter3
2.  

This Works.
I dont like it but if there is no elegant solution i wil keep this one and redistribute the /lib64 from my developing machine together with my applications.

[Thaddy]

The most elegant solution is to link as much as you can statically.
That will make your binary larger, but because it depends on less or no external libraries, deployment is much easier. Then again, static linking is more difficult, and not all external libraries are available for static linking. (You basically create everything from source, not for everyone)
Another elegant option you deploy your application is to deploy it in a container, like docker.
And of course, use a package manager or rpm that refers to the dependencies.

[sfeinst]

So I think to myself, if FPC/Lazarus is working the wanted way , without any (or minimal) tricky workarounds then maybe there is hope.

I am not a developer on FPC/Lazarus so I am only guessing, but the most likely answer is that the deb and rpm versions you are using are compiled against an older version of glibc than you are compiling against.

Compile against v1 and it will run on 1 and most likely 2 and later.
Compile against v2, it will not run on 1.

So you would need to compile your app against the older glibc and it would work on those other computers and most likely yours.

Similar issue exists on Windows world if you code against .NET (not Lazarus related but stil...).  Compile against .NET 4 it works on 4 and later.  But compile against 4.8 and it will not run on say 4.2.

[TRon]

Am I getting a wrong picture about this ?

Yes, and no

We have something in common, me and FPC/Lazarus developers: We both create binaries, and these binaries are for use on an unknown Linux environment, one can't really know the user's Linux environment.

The difference is that the .debs and rpm are build on a buildsystem with 'an older' distribution.

Difference is that fpc/lazarus binaries work on destination computer, Lazarus Download page only offers choice between DEB's or RPM's, there is no choice to choose older and newer GLIBC. And there is nothing in the README.txt on that.

That is because it is a design decision from those that develop libc. FPC has no influence on their development whatsoever. In the thread mentioned earlier there was also debate over where to put the blame but the fact of the matter is that it does not matter who is at fault as there simply is need for a solution. And a optimal solution is only possible when the libc developers are done (it is still a work in progress)

As I said, am I getting a wrong picture about this ?

Hopefully I was able to provide enough information to get that answered ?

[Handoko]

That's what i want for my binaries, do the same like Lazarus package :
download, install, work

You mentioned Lazarus package, did you mean the IDE? I have bad news for you. Lazarus does not always work on older Linux versions, especially if the time gap is too long. I tried it in the past. It is not Lazarus or your fault, that is how OS works. Any program that uses library version that is too far from the version when program is developing usually does not work. Do you play computer games, if yes you will know many games that run on WinXP won't run on Win10, and oppositely you usually can't run game build on Win10 era to run on WinXP system.

I did mention I downloaded and manually built Lazarus from the source because the Lazarus binary provided from the download page wouldn't run on my case. Recent versions of Lazarus (you downloaded) have better 'tolerance' because the developer rebuilt it using older library before provide them for public to download. That may sound problem solved, not actually. Once you rebuild your Lazarus on your computer (probably installing a new package), it will re-link with the version of the libraries in your computer. I am not good explaining it in English, hope you can't understand what I said.

In short. if you want your program to be able to run on older versions of the OS/library, you need to compile the program using the older library. But it may not work on the newer system. I have this kind of issue, the program I built years ago using older version of SSL does not work on my current system which uses newer version of SSL.

If you use Ubuntu, I suggest you to install Synaptic Package Manager and GDebi. These tools are good for inspecting/solving incorrect version when installing new program/library.

[robert rozee]

Hi,
Under OpenSuSE 15.6 Leap I created a functional aplication for use under Linux but when I copy the binary it reports an error:

./myLazApp: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./myLazApp) ]

hi Mirce,
    for solutions see this thread (6 pages):
https://forum.lazarus.freepascal.org/index.php/topic,64731.0.html
"FPC 3.2.2 / Lazarus 2.2.6 patch for GLIBC_2.34 versioning issue"

or this thread for a more detailed background (16 pages):
https://forum.lazarus.freepascal.org/index.php/topic,58888.0.html
"/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found"


cheers,
rob   :-)

[TRon]

I did a workaround, for now it's a good one.

Yes that is also possible, e.g. treat it as cross-compiling.

But it is not the (perfect) solution. See the links to the theads which robert rozee posted (thank you robert)