легковесный STL под линукс под BSD-like

я хочу вместо libstdc++ линковать другую реализацию STL, не прибитую гвоздями к системному (или любому) GLIBC. перечитай тему уже.

Она у тебя в любом случае будет чем-нибудь прибита к ABI той библиотеки, c которой ты соберешь и динамически слинкуешь свою софтину. Даже если это будет результат компиляции header-only библиотеки (потому что она почти наверняка будет использовать что-то системное из libc). Между libstdc++, libc++ и даже stlport в этом плане нет принципиальной разницы.

ты просто не поддерживаешь «достаточно старые» osx и android :)

например, для osx:

/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)

да и линуксы, видимо, тоже достаточно свежи. раз обходишься одним компилятором.

Она у тебя в любом случае будет чем-нибудь прибита к ABI той библиотеки, c которой ты соберешь и динамически слинкуешь свою софтину.

нет. я использую враппер, который через .symver ограничивает использование символов glibc только теми, которые есть в версии 2.7 или около того. но это работает только на этапе компиляции. собрать libstdc++ и libsupc++ через этот враппер мне не удалось. но libsupc++ удалось пропатчить (я приводил линк на описание процесса).

ты просто не поддерживаешь «достаточно старые» osx и android :)

я пока что не поддерживаю STL — у меня в проекте его нет. поэтому мог не сталкиваться с проблемами. но я впервые слышу о подобных проблемах с STL на android и OSX.

android поддерживаю 1.6+, OSX 10.6+.

линуксы поддерживаю практически любые от 2008 и выше. требуется GTK2.12+ и glibc2.7+.

собсно, я исхожу из того, что на маке и андроиде нет проблем с сишечкой. соответственно я не вижу откуда они возьмутся с крестами и stl, потому что ноги-то растут из libc, а не из stl.

Ну так вот чтоб с этим не возиться тебе и предлагают просто скомпилировать всё с нужной ископаемой версией glibc (2.7 или около того: Versions of libstdc++-v3 starting with 3.2.1 require bug fixes present in glibc 2.2.5 and later - так что тебе хватит с запасом) НОВЫМ компилятором, собранным с этой же версией. Ископаемость ни на что не повлияет - линковка то динамическая (макросами можно пренебречь), а ABI будет как раз нужной версии.

osx (как и freebsd, например) заморозил gcc на версии 4.2 (последней работоспособной под gpl2). поэтому 10.6 — это очень «нестарый».

bionic в версии символов-то буквально вчера научился :) до этого отваливался просто так. я, конечно, за деньги под андроид не пишу, но слышал, что там тоже общепринято gnustl_static.

если говорить конкретно о gcc, то 4.8.0 — НОВЫЙ, а 4.8.1 — НЕ СОВСЕМ :)

чувак, если вкратце — я и без советчиков знаю, что надо сделать с libstdc++ чтобы он работал как мне надо. просто я не хочу этот геморрой. поэтому создал данную тему, чтобы найти альтернативный _простой_ выход. можешь не писать мне все это. оно мне тупо не надо.

osx (как и freebsd, например) заморозил gcc на версии 4.2 (последней работоспособной под gpl2). поэтому 10.6 — это очень «нестарый».

уже шланг давно.

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix

bionic в версии символов-то буквально вчера научился :) до этого отваливался просто так. я, конечно, за деньги под андроид не пишу, но слышал, что там тоже общепринято gnustl_static.

ничего не отваливалось, и не отваливается. хз где ты такое слышал.

ты просто не в теме, и не въезжаешь.

Ребята, которые делают LSB SDK, надо думать, тоже. ОК, будь оригинален.

Ребята, которые делают LSB SDK, надо думать, тоже. ОК, будь оригинален.

извини, сгоряча написал, не хотел провоцировать. я потом удалил, и ответил более по-другому, но видимо поздно.

Если тянет на экзотику: https://github.com/pathscale/stdcxx

у меня есть билд-система, которая позволяет собирать мой проект на свежих GCC/G++/GLIBC, ограничивая версию API GLIBC и другие заморочки, таким образом готовый бинарь работает на множестве дистрибутивов линукса, в т.ч. очень старых.

Doin it wrong. Надо брать систему с самой старой glibc, которую требуется поддержать (CentOS 5, например), и собирать на ней. Если при этом нужен новый gcc, есть пакеты

http://linux.web.cern.ch/linux/devtoolset/

libstc++ от тулчейна при этом таскаешь с собой (или линкуешь статически, если бинарник один)

Читай тему, и находи ответы на все что ты написал.

уже несколько раз ответил на этот вопрос в треде. программа не запустится на более старой версии glibc, чем та с которой компиляли этот libstdc++.a

пример не запуска?

простого способа собрать и использовать glibc и libstdc++ ~10 летней давности, да еще и с возможностью кросскомпиляции, я не нашел, и, как мне кажется, это очень большой оверкилл. гораздо проще взять stlport, или что-то аналогичное.

т.е. ты считаешь что stlport не зависит от glib ? free и malloc зависит от glib, не хочешь их использовать тяни за собой и glibc.a, тогда будет у тебя на system call

аноним, ну зачем тебе все это? думаешь, мне интересно тебе что-то объяснять или доказывать?

доказывать что? я вот не понимаю, если ты хочешь пытаться создать переносимое, то берешь все .a архивы и скармливаешь при линковании, получится абсолютно чистый ldd file, без депендов
прыгнуть от glibc у тебя все равно не получится, она разная на всяких разных версиях ос, и косяки могут все равно возникать изза нее

когда поймешь - возвращайся. ответы на твои вопросы уже были дадены как в этой теме, так и в других темах по ссылкам.

Некрофилы должны страдать, потому всё это пустые телодвижения.

Некрофилы должны страдать, потому всё это пустые телодвижения.

Тут дело не в некрофильстве, актуальная версия того же glibc в разных дистрибутивах - разная. Где она самая последняя, а где-то (centos/debian) еще уже несколько лет.

Если это опенсорс, то проще выбросить поддержку Linux-ов десятилетней давности.

когда поймешь - возвращайся. ответы на твои вопросы уже были дадены как в этой теме, так и в других темах по ссылкам.

да я вижу что ты тролль, которого забанили в гугле.
твои ответы в теме - ты все знаешь, как собрать и запустить, но пришел за альтернативными решениями.
в гугле сможешь забить в поиске запрос альтернативы STL ? или за тебя делать? на гитхаб сможешь зайти поискать? или у тебя его тоже забанили?
все твои прыжки от libc ты огребешь и с другими альтернативными «stl»
тебе что бы разобраться в вопросе, для начала надо открыть и посмотреть депенд функций в libstd++ к libc

твои ответы в теме - ты все знаешь, как собрать и запустить, но пришел за альтернативными решениями.

я спрашивал какие есть реализации STL, а не то что ты подумал. завязывай оффтопить.

Если это опенсорс, то проще выбросить поддержку Linux-ов десятилетней давности.

проблема одинакова для линуксов 10-летней давности, и для линуксов 1-летней давности. нет _вообще_ никакой разницы. зачем ее выбрасывать?

Нету в линуксах вообще никакой проблемы. Один и тот же скайп прекрасно рботает как на древней убунте или центосе, так и на современных. Проблемы это ты придумываешь.