как на старых RHEL'ах использовать C++11?
GCC 4.7.2 есть в Red Hat Developer Toolset 1.1, но раз RHEL не зарегистрирован, то думаю актуальнее будет версия того же самого, но от CentOS: http://people.centos.org/tru/devtools-1.1/
для RHEL его надо покупать или при наличии регистрации он будет доступен автоматически?
Еще я вот это не понял:
Building on Red Hat Enterprise Linux 6 and executing on Red Hat Enterprise Linux 5 will not be supported by this or later releases.
а, кажись понял. билдить на 5 и запускать на 5 и 6 можно, а вот билдить на 6 и запускать на 5 - нельзя
Еще такой вопрос: эквивалентны ли бинарно CentOS и соотвествующей версии RHEL?
То есть нормально ли билдить на центосе и результат разворачивать на RHEL?
То есть нормально ли билдить на центосе и результат разворачивать на RHEL?
То есть нормально ли билдить на центосе и результат разворачивать на RHEL?Нормально, мы для продакшена использовали, пока на большие грабли не наступали.
Но это безотносительно C++11 и этого тулкита - про него кроме написанного ничего не знаю, сам не пробовал и вряд ли буду (C++11 мне к сожалению малоактуален т.к. приходится кроссплатформенно писать, а ни ни на Solaris, ни на AIX, ни на HPUX его ещё многие годы не будет; а линукс у меня пока в меньшинстве).
а, кажись понял. билдить на 5 и запускать на 5 и 6 можно, а вот билдить на 6 и запускать на 5 - нельзясудя по Compatibility Matrix, всё немного сложнее: билдить можно только на 5.6, 5.9 и 6.1+, работать будет на той версии на которой сбилдено + всех более новых (из поддерживаемых). Если у вашего заказчика RHEL не зарегистрирован, то навряд ли он обновлён до 5.6 или 5.9, верно?
для RHEL его надо покупать или при наличии регистрации он будет доступен автоматически?Надо покупать одну из перечисленных тут subsriptions. Причём это всё для разработчиков, а как ставить в продакшен не совсем понятно. Впрочем отсутствие этого продукта в обычных серверных subscriptions как бы намекает что проблемы в случае чего решать будете целиком и полностью сами.
в таком случае проще тащить libc/libc++ с собой (наши орлы в виртуозе так раньше и делали для совсем уж древних хостов),
раз там всё замерло и ничего не обновляется то от ещё одной необновляемой библиотеки хуже уже не будет
раз там всё замерло и ничего не обновляется то от ещё одной необновляемой библиотеки хуже уже не будет
А где вообще есть список вещей, которые ломаются при неиспользовании системного glibc? Ну там, nss какой-нибудь или что там еще.
а хрен его знает, nss можно и свой притащить.
в таком случае проще тащить libc/libc++ с собой (наши орлы в виртуозе так раньше и делали для совсем уж древних хостов),
Так в общем и надо делать, причём в случае libc++ — вообще всегда, как я понимаю. Типа, если ты скомпилил прогу gcc4.6, а запускаешь на линуксе где libc++.so от gcc4.2, то у тебя не будет ловиться std::exception, например.
Так что это, тащи libc++.so с собой (libc вроде должна быть дико совместимой даже до весьма дремучих версий) и выставляй LD_LIBRARY_PATH в своих запускательных скриптах.
Я может быть не понял, но что мешает тебе собирать бинарь статически? nss все равно будет динамический, но если он тебе не нужен, то "проблемы могут и не возникнуть".
> и выставляй LD_LIBRARY_PATH в своих запускательных скриптах.
Линуксоеды такие линусоеды.
Чего только ни придумают, лишь бы не использовать RPATH.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Линуксоеды такие линусоеды.
Чего только ни придумают, лишь бы не использовать RPATH.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Чего только ни придумают, лишь бы не натыкаться на грабли с RPATH.
А что за грабли?
в таком случае проще тащить libc/libc++ с собойПри этом надо еще ссылку на динамический линкер в interpreter section подменять?
Пробовал собирать кроскомпилер gcc, который бы на моем минте 10/федоре 18 собирал бинарь под RHEL используя хедеры и библиотеки с целевой машины, но потерпел фиаско на слишком низкой версии glibc.а что тебе мешает использовать и библиотеки (прежде всего glibc) с целевой машины?
я их и использовал. но для сборки современного gсс нужна современная glibc
вообще странно, ты цитируешь кусок где я говорю
и спрашиваешь, почему я не использовал библиотеки с целевой машины.
кажется настало время выслушать начальника транспортного цеха
используя хедеры и библиотеки с целевой машины
и спрашиваешь, почему я не использовал библиотеки с целевой машины.
кажется настало время выслушать начальника транспортного цеха
Оставить комментарий
elenangel
сабж.Есть одна программа. И в ней хочется использовать новые возможности языка C++. Но внедрять ее придется к клиентам, у которых зачастую стоит RHEL 5.x, еще и не зарегистрированный, то есть без репозиториев. Компилятор там старый.
Пробовал собирать кроскомпилер gcc, который бы на моем минте 10/федоре 18 собирал бинарь под RHEL используя хедеры и библиотеки с целевой машины, но потерпел фиаско на слишком низкой версии glibc.
Кросс собирал по этому мануалу с поправкой на то, что не под соляру, а под другой линукс.
P.S. обычно на площадке внедрения очень тяжело добиться регистрации шапки, обновления шапки, сноса шапки и установки fedora даже если сервер целевой под проект и все это "по политическим причинам".
Хочу узнать насколько реально решить эти "политические причины" техническими средствами.