Briefly about the task: it is necessary to use the binaries collected from under the new system on the old system. Both are Gnu / Linux systems.

There were several problems, but almost all of them were solved. Although it does not matter which application to build, for example, I’ll point out exactly what I’m stuck on. It has now reached the assembly of suitable Qt5.6 lib (5.7 requires at least C ++ 11, which causes additional problems).

After the build, I transfer these with the executable file and specify LD_LIBRARY_PATH. No matter how hard I try to collect these, the best I have achieved is to reduce the number of errors to four (of the same type, therefore I specify one line):

/lib/libc.so.6: version 'GLIBC_x.y' not found (required by ./libQt5Core.so.5)

Only libQt5Core.so.5 swears on the version. The maximum required version = 2.9.

The glibc version 2.24 is installed on the new system, and 2.3.6 is installed on the old system.

I ask for help in solving this problem!

  • Use #ifdef sure there are tests for the version of qt - nick_n_a
  • @nick_n_a Thanks for the reply! And you can read more? The question is not in the Qt version, but in the assembly of programs / libraries with the possibility of linking to the old libc.so.6. Here Qt cited an example. - AccumPlus
  • @nick_n_a I can not catch your thought. So I got library version 2.3.3, but when launching the application, the linker asks for at least 2.9. What exactly needs to be specified in define so that the linker does not do this? - AccumPlus
  • one
    I don’t know if the build for the old version of glibc will help you, add to the question: how to do cross-compilation for different glibc. Maybe this will help. - nick_n_a
  • one
    Skype, not to the table will be said, works for many. So I think that you should focus on a few common ones, it's easier to maintain, and the rest can be on a separate contract. - 0andriy

0