LINUX.ORG.RU

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


1

2

нужна реализация STL, чтобы можно было собирать код на C++, использующий STL, используя g++ / glibc, но без libstdc++.

полнота поддержки стандарта — достаточно C++98.

поддержка других осей кроме линукса не нужна, но нужна как минимум собирабельность G++ и шлангом.

кто-нибудь сталкивался? можете что-то посоветовать?

EDIT: кроме очевидного stlport.. он подходит, но интересно нет ли каких-то альтернатив.

EDIT2: убрал объяснение зачем все это нужно, чтобы (попытаться) избежать ненужных советов.

EDIT3: тема отмечена как решенная еще на 1й странице, просьба возждержаться от бесполезного флуда и оффтопа.

EDIT4: убрал теги чтобы отфильтровать фанатиков

★★★★★

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

xaizek ★★★★★ ()

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

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

https://github.com/msharov/ustl

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

stlport?

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

waker ★★★★★ ()
Ответ на: комментарий от andreyu

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

waker ★★★★★ ()

Ну вот 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.

asaw ★★★★★ ()
Ответ на: комментарий от asaw

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

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

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

вот эти

waker ★★★★★ ()
Ответ на: комментарий от asaw

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

waker ★★★★★ ()
Ответ на: комментарий от asaw

-static-libstdc++

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

waker ★★★★★ ()
Ответ на: комментарий от reprimand

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

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

waker ★★★★★ ()
Ответ на: комментарий от waker

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

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

asaw ★★★★★ ()
Ответ на: комментарий от asaw

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

asaw ★★★★★ ()
Ответ на: комментарий от asaw

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

Нет.

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

anonymous ()
Ответ на: комментарий от anonymous

Нет

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

asaw ★★★★★ ()
Ответ на: комментарий от asaw

Не нет, а да.

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

asaw ★★★★★ ()
Ответ на: комментарий от waker

А он отдельно и поставляется. Собирается 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

Gorthauer ★★★★★ ()
Ответ на: комментарий от asaw

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

asaw ★★★★★ ()
Ответ на: комментарий от asaw

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

Окай.

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

asaw ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от Gorthauer

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

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

waker ★★★★★ ()
Ответ на: комментарий от asaw

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

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

waker ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от waker

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

asaw ★★★★★ ()
Ответ на: комментарий от asaw

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

waker ★★★★★ ()
Ответ на: комментарий от waker

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

asaw ★★★★★ ()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от asaw

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

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

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

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

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

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

waker ★★★★★ ()
Ответ на: комментарий от waker

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

asaw ★★★★★ ()
Ответ на: комментарий от asaw

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

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

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

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

waker ★★★★★ ()
Ответ на: комментарий от waker

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

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

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

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

asaw ★★★★★ ()
Ответ на: комментарий от asaw

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

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

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

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

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от waker

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

Gorthauer ★★★★★ ()
Ответ на: комментарий от waker

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

Gorthauer ★★★★★ ()
Ответ на: комментарий от Gorthauer

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

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

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

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

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

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

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

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

waker ★★★★★ ()
Ответ на: комментарий от Gorthauer

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

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

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от waker

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

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

asaw ★★★★★ ()

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

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

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

anonymous ()
Ответ на: комментарий от asaw

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

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

waker ★★★★★ ()
Ответ на: комментарий от anonymous

православный путь — собираться своим тулчейном (то что ты по оффтопной привычке называешь 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 ничего не даст.

waker ★★★★★ ()
Ответ на: комментарий от waker

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

waker ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.