Поскольку бинарный файл, создаваемый pyinstaller, зависит только от glibc, то это должен быть правильный подход для сборки его на самой старой из доступных систем, и он должен работать на будущих системах.
В целом, glibc разработан для обеспечения обратной совместимости, поэтому приложения, созданные на основе более старой версии glibc, будут по-прежнему работать с более новым glibc, но не наоборот. Это осуществляется с помощью управления версиями символов, в котором каждому символу, на который вы ссылаетесь, может быть присвоена версия, и в любом случае, когда более новый glibc изменил ABI какой-либо функции, он также будет иметь подпрограмму совместимости со старым открытым ABI. с более старой версией символа, так что приложения, связанные со старой, будут динамически связываться с подпрограммой совместимости, в то время как у вас есть приложение, связанное с более новыми версиями символов, не будет более новых версий в более старом glibc для динамического связывания к.
Хотя другие библиотеки также могут это делать, не многие авторы библиотек беспокоятся об этом, поэтому более новые версии могут просто быть несовместимыми, в то время как разработчики glibc обычно пытаются сохранить совместимость.
Так что да, если конечные двоичные файлы связаны только с glibc или другими библиотеками, которые следуют аналогичной схеме управления версиями символов, чтобы гарантировать, что более старые двоичные файлы будут по-прежнему надлежащим образом связываться с более новыми версиями библиотеки, то вполне допустимо создавать против более старой версии, а затем запустите ее на более новых версиях различных дистрибутивов Linux, и даже в целом на дистрибутивах.
К сожалению, нет хорошего способа заставить компоновщик выбрать более старые версии символов, если он ссылается на более новый glibc, поэтому часто самый простой способ сделать это - внутри Docker или контейнера другого типа, содержащего более старый дистрибутив, который имеет самый старый glibc, с которым вы хотите быть совместимым.