Привет! Как некоторые знают, если я собираю софт, который собираюсь кому-нибудь дать, я собираю его не в домашней системе, а в билд-ферме на основе CentOS 5 или 6. Например я собрал Dosbox-daum, который запускается в десятках дистрибутивов Linux разных версий. Ради любопытства, я попробовал поднять билд-ферму на SLES 10. У меня возникли вопросы, на которые я хочу услышать от вас, мудрых людей, ответа.
Вопрос первый. В CentOS 5 и 6 можно установить компилятор GCC 4.8 (CentOS 5) или GCC 7 (CentOS 6). Для SLES 10 тоже есть репозиторий с GCC. Я заглянул в него и огорчился: дефолтный GCC 4.1. Зато есть более-менее новый binutils 2.29.1, и на том спасибо.
Я заглянул в соседний каталог (SLE 11) и скачал SRPM-ку GCC 4.8.5. Собралось без проблем - пришлось только добавить "--disable-nls" из-за какой-то проблемы со сборкой, которую я не захотел решать.
И вот что я получил со свежесобранным компилятором:
DEBUG: configure:17666: /usr/bin/gcc-4.8 -std=gnu99 -shared -Wl,-z,defs -Wl,--gc-sections -lpthread -Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -o libconftest.so -Wl
DEBUG: gcc-4.8: error: unrecognized command line option '-Wl'
Полный лог, если кому-нибудь интересно. Как такое могло случиться?
Второй вопрос. Когда я пользуюсь CentOS 5 или 6 в качестве билд-фермы, готовые бинарники не требуют свежего C++ Runtime (библиотека libstdc++.so.6). Как так вообще? Я беру openSUSE Leap 42.2, компилирую программу, пробую запустить в Ubuntu 8.04 - получаю «nothing provides STDCXX_some.version». Я беру CentOS 5, компилирую программу в GCC 4.8, и запускаю в системе с GCC 4.2. Работает!
Как так вообще?! Я решил посмотреть состав пакета с GCC из репозитория devtoolset. Там вместо libstdc++.so.6 даже не симлинк, а текстовый файл 20 символов! Финальная линковка программы осуществляется со старым C++ Runtime! Как это вообще работает?! GCC видит, что программа использует C++11, но в системном C++ Runtime этого нет, и кладёт всё недостающее в бинарь?
В SLES 10 я вот как сделал. Установил libstdc++48-devel. YAST мне говорит «Давай я тебе удалю libstdc++41 и установлю вместо него libstdc++48». Я сказал «нет». «Но тут же зависимость прописана» «Игноруруй» «Ну ок». Таким образом, установились только хедеры. Это будет работать?
Объясните: это с каждой софтиной такое можно провернуть? Для примера, Firefox 52 теперь хочет XCB-SHM вместо X11-SHM. Нужны libxcb 1.4 и libX11 1.3. Допустим, у меня libxcb 1.1. Не беда - я могу установить новые хедеры! И что - Firefox соберётся, и даже работать будет? Но программе действительно нужны отсутствующие функции, тогда как в хедерах перечислены только их названия. Где компилятор их возьмёт - родит что ли?
// Вдогонку к моей предыдущей теме. Firefox собрался, спасибо!
Или вот например, я собирал PCSX2 в CentOS 5 компилятором GCC 4.8. Понадобился OpenGL 3. В системе - Mesa 6.5.1, выпущенная задолго до OpenGL 3. Я просто зашёл на сайт http://khronos.org/ и скачал последние хедеры. Положил их в /usr/include/GL, и программа собралась. Я запустил её на современной системе, и всё работало.
Вопрос третий. Я собираю какую-нибудь программу в CentOS 5. Программа умеет всякие полупрозрачности окон, используя для этого libXcomposite.
Все мы помним вирусную популярность Ubuntu 6.06 и то, как эта система затмила популярность других линуксов. Мандрива вон даже обанкротилась. Одна из поразивших нас тогда вещей были 3D-эффекты рабочего стола.
Сайт NVIDIA радует нас инфой о том, что:
If the Composite extension is enabled on an X server older than X11R6.9.0, then GLX will be disabled. You can force GLX on while Composite is enabled on pre-X11R6.9.0 X servers with the
AllowGLXWithCompositeX configuration option. However, GLX will not render correctly in this environment. Upgrading your X server to X11R6.9.0 or newer is recommended.In X servers prior to X.Org 7.1, Xv cannot draw into pixmaps that have been redirected offscreen and will draw directly onto the screen instead. For some programs you can work around this issue by using an alternative video driver. For example, «mplayer -vo x11» will work correctly, as will «xine -V xshm». If you must use Xv with an older server, you can also disable the compositing manager and re-enable it when you are finished.
On X.Org 7.1 and higher, the driver will properly redirect video into offscreen pixmaps. Note that the Xv adaptors will ignore the sync-to-vblank option when drawing into a redirected window.
Убунта 6.06 базировалась как раз на Xorg 6.9, а CentOS 5 - на Xorg 7.1. Если я буду собирать софт в CentOS 5, а потом запускать в Ubuntu 16.04, проявятся ли эти вышеобозначенные баги композитинга и Xv? Иначе говоря - «всплывут» ли баги старых версий библиотек, если скомпилировать прогу с ними, а запускать с новыми библиотеками?
