При установке SLE 11 SP4, там «из коробки» Firefox 38. Работает нормально. Из репозитория SLE_11_SP4:Updates можно установить Firefox 45. Он тоже работает нормально. Потом поддержка SLED кончилась, осталась только поддержка SLES, и в SLES не обновляют Firefox. Версия Firefox так и осталась 45. Поэтому я решил компилировать новые версии сам. Я скомпилировал версию 52. Установил, работает. Но есть три вопроса.
Первый вопрос: скомпилированный мной браузер хорошо работает на системах с 4+ Gb RAM и выше. На системах с 2 Гб памяти он работает нестабильно: при загрузке большой страницы (такой как maps.google.ru) он может «упасть»
Сначала я подумал, что проблема в патче, который я наложил, чтобы Firefox скомпилировался с Glibc 2.11. Была заменена одна строчка - неужели глюки из-за этого? Чтобы понять, так ли это, я обновил системный Glibc до 2.12 и попробовал скомпилировать Firefox без патча. Всё равно падает на 2 гигах ОЗУ...
И что интересно - помимо Firefox 52, я также скомпилировал Tor Browser 52, и он-то как раз не падает! Как так?
В поисках решения проблемы, я попробовал компилировать предыдущие версии браузера. Firefox 45 падает (хотя тот же Firefox 45 из репозитория дистрибутива не падает). Мне бы получить SRPM-ку Firefox 45 из SLED_11_SP4:Updates - наверное, там есть некий патч, который исправлет эти падения. Может быть, у кого-нибудь есть эта SRPM-ка? А Tor Browser либо тоже имеет это исправление, либо там просто что-то отключено в about:config
И наконец, самое интересное. Если компилировать браузер вручную, а потом выполнить ./mach package, то будет создал *.tar.gz архив, подобный тому, который выкладывают в http://ftp.mozilla.org/pub. А если зайти в dist/bin и запустить браузер оттуда, то ничего не падает! Это как?! В итоге я скопировал dist/bin в ~/firefox, и это работает. Но немного напрягает, что там внутри 4000 файлов, а через mach их всего 60.
Второй вопрос касается повышения системных требований. Все уже знают, что в Firefox 52 официальные сборки теперь компилируют с PulseAudio без ALSA. Нам сказали примерно следующее: «наконец-то мы прекратили поддержку Windows XP и RHEL5. Теперь нам не надо поддерживать старые звуковые системы, и поэтому мы можем реализовать звук 5.1 в браузере»
У меня возникла проблема не с этим. В Firefox 52 подняли системные требования до Xorg 7.5, который был в RHEL/CentOS 6, потому что прекратили поддержку RHEL5. В SLE 11 версия Xorg чуть меньше - 7.4. Пришлось обновить libxcb с версии 1.1 до 1.4 (вообще в Xorg 7.5 - libxcb 1.5, но опытным путём выяснилось, что 1.4 достаточно), а также libX11 с 1.1 до 1.3. Firefox скомпилировался и заработал.
Возможно ли скомпилировать libxcb 1.13, libX11 1.6.7, и, во время компиляции Firefox, слинковаться с ними статически? Я так понимаю, если я тупо уберу libxcb.so и libX11.so, оставив только libxcb.a и libxcb.a, то Firefox будет использовать именно их. Вот только все остальные зависимости (например GTK) работать без *.so версий этих либ не захотят. Так как тогда?
Лично мне не сложно обновить системные libxcb и libX11. Но мне написал юзер SLE 11 из Колумбии и сказал «Ты прописал зависимости от пакетов таких-то версий, а где их взять?». Похоже что он просто скачал мои RPM-ки вместо того, чтобы подключить репозиторий, потому что в этом случае всё само бы поставилось. И поэтому я задумался над тем, чтобы подцепить эти либы статически, а системные не обновлять. Возможно ли это?
Третий вопрос это обновление до следующих LTS-версий браузера. Там Rust, я вот пердолюсь с тем, чтобы его скомпилировать. Бинарная сборка Rust уже есть, но в OBS-репозитории mozilla бинарную сборку используют только для того, чтобы скомпилировать из исходников. Блин, а чё так сложно?
Вообще, интересные открытия можно сделать, если посмотреть SRPM-пакеты с Firefox-ом из CentOS 5 и 6. Например в пакете с CentOS 5 нашлись чудесные патчи, понижающие минимально необходимую версию GTK с 2.18 до 2.10. Также я оттуда узнал, что хотя в CentOS 5 нет Python 2.7, питон просто компилируется рядом и используется при компиляции. А потом он не нужен. Ну и наконец я оттуда взял патчи для понижения минимально необходимой версии fontconfig. SRPM-ку из CentOS 6 я пока не смотрел, и наверное решение проблемы с зависимостью от Rust и LLVM там есть.
