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

Не знаю на счёт легковесности, но может libc++ от создателей шланга?

Вот что-то похожее:

https://github.com/msharov/ustl

stlport?

libc++ от создателей шланга

а его можно как-то раздобыть отдельно от шланга?

https://github.com/msharov/ustl

это не реализация stl. файлы, классы и неймспейсы неправильно называются.

stlport?

это знаю. ищу другие варианты, чтобы иметь возможность сравнить.

Может stlport подойдет?

он пока что единственный кандидат и есть. хочу узнать, есть ли другие подходящие варианты.

Ну вот libc++ уже посоветовали. А какой смысл всего этого? Ты рантайм стандартной библиотеки хочешь статически прилинковать к проприетарщине? Так линкуй, какие проблемы?

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.

Ну вот libc++ уже посоветовали. А какой смысл всего этого? Ты рантайм стандартной библиотеки хочешь статически прилинковать к проприетарщине?

почему сразу к проприетарщине? к опенсурсщине.

Так линкуй, какие проблемы?

вот эти

Ну так а какие конкретно проблемы если линкуешь с -shared-libgcc -static-libstdc++?

программа не запускается на линуксах с более старой версией glibc, вне зависимости от того static или shared (причины разные, результат один).

поставить любой линукс с старым glibc?

-static-libstdc++

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

поставить любой линукс с старым glibc?

я не контролирую версию линуксов и glibc на сборочных машинах (использую drone.io), и я хочу иметь возможность скомпилировать свой проект на локалхосте, без виртуалок.

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

Это линкует внутрь твоей программы libstdc++, который завязан на тот glibc, который ты укажешь в опциях линковки дальше.

И, кстати, линкуется не весь рантайм libstdc++, а только те объектники из него, которые используются.

Это линкует внутрь твоей программы libstdc++, который завязан на тот glibc, который ты укажешь в опциях линковки дальше.

Нет.

П.С. с помощью debootstrap можно за несколько минут получить все необходимое для сборки под старый glibc и выше.

Нет

Не нет, а да. Так устроена линковка в юниксах, причем, как статическая, так и динамическая. Берется первое определение символа из указанных библиотек, причем библиотеки обрабатываются в порядке их перечисления.

Не нет, а да.

Возьми и проверь, чтоб убедится, что ты не прав.

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

Ты путаешь поведение ld.so и линковщика.

Ты путаешь поведение ld.so и линковщика.

Я НЕ путаю поведение ld.so и линковщика, это ты не в теме. Ещё раз повторяю: порядок библиотек в строке вызова редактора связей решает. Это тебе не оффтопик.

Вот тебе популярное объяснение в качестве ликбеза: http://stackoverflow.com/a/26281074/2935339

А он отдельно и поставляется. Собирается cmake'ом. Ну а в случае gcc просто его либы нужно будет ручками задать и попросить не юзать stdlib.

http://libcxx.llvm.org/

Ради эксперимента сейчас собрал его при помощи gcc.

[100%] Linking CXX shared library libc++.so
[100%] Built target cxx

Ну и взял оч старый gcc, всё-таки libc++ хочет c++11

CMake Error at CMakeLists.txt:200 (message):
  C++11 is required but the compiler does not support -std=c++11

Я НЕ путаю поведение ld.so и линковщика, это ты не в теме. Ещё раз повторяю: порядок библиотек в строке вызова редактора связей решает. Это тебе не оффтопик.

Тогда ты просто вообще не в курсе, что такое версионинг символов. Если libstdc++ использует memcpy@GLIBC_2.15, то никакой порядок линковки ничего не изменит. И перед тем как повышать голос, послушай умных людей и проверь на практике.

Тогда ты просто вообще не в курсе, что такое версионинг символов. Если libstdc++ использует memcpy@GLIBC_2.15

Это уже другой вопрос, который никак не опровергает того, что я написал. Конфигурируй и собирай libstdc++ с той libc, которая тебе нужна.

И перед тем как повышать голос, послушай умных людей и проверь на практике.

Анонимного клоуна что ли? Да отсюда видно, что ты заметался как таракан.

Это линкует внутрь твоей программы libstdc++, который завязан на тот glibc, который ты укажешь в опциях линковки дальше.
Конфигурируй и собирай libstdc++ с той libc, которая тебе нужна.

Окай.

Да отсюда видно, что ты заметался как таракан.

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

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

писец какие проблемы вкомпилить libstdc++.a в программу?

писец какие проблемы вкомпилить libstdc++.a в программу?

ЕМНИП, это сломает обработку исключений, если программа будет использовать динамические библиотеки.

Больше магии и мистики.

Больше магии и мистики.

Меньше комплексов - больше конструктива.

https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

Ну и взял оч старый gcc, всё-таки libc++ хочет c++11

это, скорее всего, не проблема, т.к. на всех сборочных линуксах c++11 имеется. но да, пока что это недостаток в сравнении с stlport.

Это линкует внутрь твоей программы libstdc++, который завязан на тот glibc, который ты укажешь в опциях линковки дальше.

я линкуюсь с системным glibc. именно из-за этого и проблема с libstdc++. мне казалось, это сразу должно быть понятно.

писец какие проблемы вкомпилить libstdc++.a в программу?

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

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

Нет, это сразу совершенно не понятно. Сразу впечатление такое, что тебя чем-то не устраивает лицензия. А если лицензия тебя устраивает, то совершенно не понятно чем для тебя тот же libc++ будет лучше libstdc++.

нет, лицензия меня устраивает. мне лично совершенно непонятно, что непонятно _тебе_. будет ли libc++ лучше или нет — я не уверен. но вот stlport точно будет, потому что его можно использовать в «режиме» header-only, и не иметь вообще никаких проблем с линковкой.

Ну да, STLport - единственная на моей памяти header-only реализация STL. Этим она и была всегда ценна (правда, безнадежно устарела уже). Но тогда не понятно почему ты сразу не спросил про header-only STL, а написал про какие-то лицензии и какую-то мутную систему сборки.

почему ты сразу не спросил про header-only STL

это не обязательное условие, но это преимущество. и да, я просто забыл про это написать.

а написал про какие-то лицензии

потому что лицензии - это тоже важно.

и какую-то мутную систему сборки.

потому что люди лезут с тупыми вопросами типа «а зачем а почему».

Не, ну это действительно интересный вопрос как ты с помощью этой системы сборки надеешься собрать ту же libc++, если libstdc++ с её помощью собрать как требуется нельзя.

Не, ну это действительно интересный вопрос как ты с помощью этой системы сборки надеешься собрать ту же libc++, если libstdc++ с её помощью собрать как требуется нельзя.

насколько я понимаю, libc++ собрать можно элементарно, т.к. это отдельный проект, у него есть отдельная система сборки на cmake.

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

если что, я пока не вижу ни одного преимущества libc++ над stlport, поэтому собирать его не собираюсь.

libstdc++ собирается как часть glibc, и отодрать ее никак невозможно, я неправ?

Она собирается как часть GCC, но вполне отдельно: http://preshing.com/images/cross-gcc-steps.png

http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/

Собственно, если ты делаешь кросс-компиляцию для старых систем, то как ещё её по-хорошему делать? Разве что только все остальные библиотеки туда добавить, создав подобие SDK.

Она собирается как часть GCC, но вполне отдельно

выбери что-то одно.

Разве что только все остальные библиотеки туда добавить, создав подобие SDK.

все так и сделано — по сути у меня собственный linux-sdk.

libstdc++ собирается как часть gcc, от glibc никак вообще не зависит. Она вообще-то может собираться при помощи mingw, она есть на маках и фрях, где нет glibc. То есть тебе проще взять любой дистр со старинной glibc и с его помощью собрать себе пакет с gcc. Я бы взял debootstrap, с его помощью поставил wheezy или ещё что-то постарше, стянул бы src пакет с новеньким gcc и пересобрал его.

Кстати вполне себе можно соорудить при помощи debootstrap и apt-build. Можно ещё даже с помощью portage соорудить не Генту, а всего лишь маленький sdk.

libstdc++ собирается как часть gcc, от glibc никак вообще не зависит.

да, сорри, попутал этот момент.

Она вообще-то может собираться при помощи mingw, она есть на маках и фрях, где нет glibc.

вот только мне надо это на линуксе. на других платформах нет этих проблем.

То есть тебе проще взять любой дистр со старинной glibc и с его помощью собрать себе пакет с gcc. Я бы взял debootstrap, с его помощью поставил wheezy или ещё что-то постарше, стянул бы src пакет с новеньким gcc и пересобрал его.

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

Кстати вполне себе можно соорудить при помощи debootstrap и apt-build. Можно ещё даже с помощью portage соорудить не Генту, а всего лишь маленький sdk.

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

перечитал еще раз. ты предлагаешь собрать gcc со старинным glibc. херня какая-то. нафига такое кому-то может быть нужно?

ps: тема отмечена как решенная, можешь со своими советами проходить мимо — они вообще не в кассу.

перечитал еще раз. ты предлагаешь собрать gcc со старинным glibc. херня какая-то. нафига такое кому-то может быть нужно?

Ну так ведь именно этого ты и хочешь динамически линкуясь с glibc и используя старый ABI! Если тебе нужно чтобы твоя софтина на старинных платформах использовала новейшую реализацию libc, то тебе придется таскать её с собой (как вариант - линковать статически).

православный путь — собираться своим тулчейном (то что ты по оффтопной привычке называешь linux sdk).

если интересуешься некрофилией (stlport) — у apache тоже была stdcxx.

если без хождения по граблям никак — символы вполне можно победить: https://davidgow.net/hacks/bingcc.html

Ну так ведь именно этого ты и хочешь динамически линкуясь с glibc и используя старый ABI! Если тебе нужно чтобы твоя софтина на старинных платформах использовала новейшую реализацию libc, то тебе придется таскать её с собой (как вариант - линковать статически).

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

православный путь — собираться своим тулчейном (то что ты по оффтопной привычке называешь linux sdk).

тулчейн и sdk — это разные вещи. мой «linux-sdk» не содержит тулчейна, а назвал я его так просто процитировав asaw.

и да, технически - я мог бы туда и свой тулчейн всобачить, но пока что не было таковой необходимости, и надеюсь что не возникнет.

если без хождения по граблям никак — символы вполне можно победить: https://davidgow.net/hacks/bingcc.html

читай собственный линк: bingcc doesn't touch libstdc++ at all, just libc, so while it's great for simple C programs, it's not quite ideal for big C++ monstrosities;

у меня используется подобный враппер, и решает все это для сишных и C++ программ, но без STL. использование bingcc ничего не даст.

но пока что не было таковой необходимости, и надеюсь что не возникнет.

этот путь православен ещё со времён массовой миграции с gcc-2.95 на gcc-3.0. а gcc прославился тем, что может сломать abi даже внутри одной мажорной версии.

читай собственный линк

libstdc++ вполне себе статически линкуется практически на всех актуальных платформах. проблема в версиях символов libc (не только glibc, *bsd тоже этим страдают).

этот путь православен ещё со времён массовой миграции с gcc-2.95 на gcc-3.0. а gcc прославился тем, что может сломать abi даже внутри одной мажорной версии.

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

libstdc++ вполне себе статически линкуется практически на всех актуальных платформах. проблема в версиях символов libc (не только glibc, *bsd тоже этим страдают).

угу, и я об этом осведомлен не хуже тебя. именно эту проблему пытаюсь решать. но на мой взгляд, гораздо проще взять stlport, чем заниматься трахомудием с libstdc++. и в моем случае проблема только с линуксом. на остальных поддерживаемых платформах эта проблема решена системными тулчейнами (OSX, Android).