System library mismatch after Ubuntu dist upgrade

[Mark81]

Sorry for the dumb question, but this is the first time I'm facing this issue.
For almost one year I worked on a project where both the development machine and the target one were running Ubuntu 20.04.

Yesterday, in order to run a specific software, I had to upgrade my dev machine to Ubuntu 21.04.

Now, the new compiled executables of my Qt projects don't run anymore on the target machine due to a library mismatch.
Example:

error while loading shared libraries: libnfc.so.6: cannot open shared object file: No such file or directory

On the target there is /usr/lib/x86_64-linux-gnu/libnfc.so.5.
Ok, I deployed this library to the target, and checked if all libraries are now found:

$ ldd MyProject
./MyProject: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./MyProject)
./MyProject: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./MyProject)
./MyProject: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./MyProject)
	linux-vdso.so.1 (0x00007fff504f4000)
	libyaml-cpp.so.0.6 => /lib/x86_64-linux-gnu/libyaml-cpp.so.0.6 (0x00007f04a250a000)
	libnfc.so.6 => /lib/x86_64-linux-gnu/libnfc.so.6 (0x00007f04a24e2000)
	libQt6Gui.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6Gui.so.6 (0x00007f04a1b86000)
	libQt6Qml.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6Qml.so.6 (0x00007f04a1664000)
	libQt6WebSockets.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6WebSockets.so.6 (0x00007f04a162d000)
	libQt6Network.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6Network.so.6 (0x00007f04a1490000)
	libQt6SerialBus.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6SerialBus.so.6 (0x00007f04a1440000)
	libQt6SerialPort.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6SerialPort.so.6 (0x00007f04a1422000)
	libQt6Sql.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6Sql.so.6 (0x00007f04a13d5000)
	libQt6Core.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6Core.so.6 (0x00007f04a0da7000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f04a0bc5000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f04a0baa000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f04a09b6000)
	libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007f04a07ab000)
	libEGL.so.1 => /lib/x86_64-linux-gnu/libEGL.so.1 (0x00007f04a0796000)
	libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f04a074f000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f04a0612000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f04a060c000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f04a04e1000)
	libQt6DBus.so.6 => /home/user/Qt/6.2.0/gcc_64/lib/libQt6DBus.so.6 (0x00007f04a041a000)
	libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f04a03d8000)
	libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f04a0350000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f04a0334000)
	libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f04a0275000)
	libgthread-2.0.so.0 => /lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f04a026e000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f04a024b000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f04a00fc000)
	libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f04a00af000)
	libicui18n.so.56 => /home/user/Qt/6.2.0/gcc_64/lib/libicui18n.so.56 (0x00007f049fc16000)
	libicuuc.so.56 => /home/user/Qt/6.2.0/gcc_64/lib/libicuuc.so.56 (0x00007f049f85c000)
	libicudata.so.56 => /home/user/Qt/6.2.0/gcc_64/lib/libicudata.so.56 (0x00007f049de79000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f049de6e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f04a2692000)
	libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f049ddb6000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f049dd88000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f049dd7d000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f049dd53000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f049dce0000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f049dc8f000)
	libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f049dc5b000)
	libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f049dc21000)
	libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f049db44000)
	libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f049db13000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f049db0c000)
	libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f049dafd000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f049daf5000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f049daed000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f049da3e000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f049da37000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f049da1b000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f049d9ff000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f049d9d6000)
	liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f049d9b5000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f049d897000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f049d874000)

Here the problems:

$ ./MyProject
./MyProject: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./MyProject)
./MyProject: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./MyProject)
./MyProject: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./MyProject)

My knowledge is not enough to understand how to handle this situation.

[jsulm]

@Mark81 said in System library mismatch after Ubuntu dist upgrade:

My knowledge is not enough to understand how to handle this situation

One way would be to create a virtual machine with Ubuntu 20.04 and build in this virtual machine for your target.

[Mark81]

@jsulm Sorry but this is not an option. I migrated from Windows to Linux just to avoid the use of virtual machines!
I mean, of course I cannot ask my customer to have the exactly same version of my dev machine!
I think this is a common scenario for every deployment... the architecture is the same, the distro is the same, it's just an upgrade behind...

[jsulm]

@Mark81 This is Linux. There are many different Linux distributions with different libraries/versions. An application build on one Linux distribution can fail on another (like in your case). So, packaging and distributing applications for Linux is not an easy job.
There are different ways to achieve this:

• Static linking
• Building and packaging for all Linux distributions you want to support
• Using containers like Flatpack

[Mark81]

@jsulm can I simply collect all the required libraries on the dev machines and put them inside the exec folder? IIRC that is the first place where it search for libraries.

[jsulm]

@Mark81 Well, you can. But it can get complicated as libraries can also depend on other libraries.

[Mark81]

@jsulm sorry, last question:

Building and packaging for all Linux distributions you want to support

Is this possible within the same environment? Like for Qt kits, is it possible to install the previous libraries versions along the newer ones in my dev machine, and then tell Qt Creator to use them?

[jsulm]

@Mark81 That would be cross-compilation. It is possible. You need a sysroot containing the libraries and header files. The sysroot would be /usr content from Ubuntu 20.04. You also would need to install same compiler as in Ubuntu 20.04.
But then again: why do all this if you can simply set-up a virtual machine with Ubuntu 20.04 and build there?

[Mark81]

@jsulm for years I used virtual machines. Now I want to use native tools in the OS, without the annoying stuff of vbox.

[JKSH]

@Mark81 said in System library mismatch after Ubuntu dist upgrade:

I think this is a common scenario for every deployment... the architecture is the same, the distro is the same, it's just an upgrade behind...

• Building on an older version and deploying to a newer version usually works fine.
• Building on a newer version and deploying to an older version can often fail.

The rule of thumb is: Build using the oldest OS that you want your app to support.

cannot ask my customer to have the exactly same version of my dev machine!

Agreed.

You just need your dev machine to be the same as, or older than, your customer's machine.