/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

Установить из testing (или unstable, если в testing еще не прилетел).

Обновляйся до wheezy. Иначе никак, ибо извраты с подкладыванием библиотек в локальном home — не нужны. А на wheezy уже давно тепло и хорошо (а мне так вообще милее Sid'а нет).

может не стОит мешать ветки!?
оно тебе написало «не могу найти приплюснутую либу из gcc ветки 4.6»

обновляйся до Wheezy/Sid, и только потом устанавливай.

Обновляйся до Ubuntu 12.04 LTS. Хватит красноглазить с Debian, работать надо ))) А эти сборки ясно у них написано что для Ubuntu.

Дебиан не красноглазый дистрибутив. Он слоупочный.

Debian

Кушай, дружок.

кто там спрашивал про «почему везде gtk на десктопах»?

LD_LIBRARY_PATH на lib/ от gcc новой версии, только и всего. А вообще да: юзаете бинарный дистр - жрите.

кто там спрашивал про «почему везде gtk на десктопах»?

можно подумать «version `GLIBC_2.14' not found» и т.п. чем-то лучше

можно подумать «version `GLIBC_2.14' not found» и т.п. чем-то лучше

нет никакой проблемы собирать свои приложения с GLIBC2.7 ABI. сомневаюсь, что с C++ все так же просто.

нет никакой проблемы собирать свои приложения с GLIBC2.7 ABI.

#include <setjmp.h>
#include <stdio.h>
#include <string.h>

main() {
	long long *p1, *p2;
	memcpy(p1,p2,10000);
	
	jmp_buf buf;
	if(setjmp(buf)==1111) printf("!!\n");
	longjmp(buf,rand());
}

давай список действий, чтоб собрать это с -O2 против GLIBC2.7 с системной GLIBC2.15

сомневаюсь, что с C++ все так же просто.

о «просто» поговорим после ответа на предыдущий вопрос

о «просто» поговорим после ответа на предыдущий вопрос

$ pacman -Qs glibc
local/glibc 2.15-10 (base)
    GNU C Library
$ apgcc -O2 test.c
$ objdump -t a.out | grep GLIBC
00000000       F *UND*  00000000              longjmp@@GLIBC_2.0
00000000       F *UND*  00000000              _setjmp@@GLIBC_2.0
00000000       F *UND*  00000000              memcpy@@GLIBC_2.0
00000000       F *UND*  00000000              puts@@GLIBC_2.0
00000000       F *UND*  00000000              __libc_start_main@@GLIBC_2.0
00000000       F *UND*  00000000              rand@@GLIBC_2.0

зы: apgcc линкуется к минимально возможному, т.к. в этом примере нет вызовов которые появились в >=2.7 — линкуется к ABI 2.0.

Некрофилы должны страдать. Очевидно линуксовый бинарник они собирают на убунте.

apgcc

дохлый костыль из поделки, о котором никто не слышал, которого нет в дистрибутивах, и который выполняет роль препроцессора - отличное «решение», гораздо прямее собрать в chroot

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

тебе шашечки, или ехать?

речь шла о том, что ошибку про GLIBC можно встретить еще чаще, т.к. никто этой тулзой не пользуется

решение не менее прямое, чем чрут

это хак, в отличие от, причем хак без всяких гарантий, что он ничего не поломает с новым glibc

и намного более простое и удобное

только один раз - при первой настройке, потом разницы нет

Можно - используй DEB-SRC. А вообще недоработка, нужно собирать с GCC 4.1.

Можно использовать GLIBC и LIBSTDC++ из другого каталога. Вот например как запускать Steam в старых дистрибутивах Linux, там та же ошибка. http://steamcommunity.com/app/221410/discussions/1/846939071448270483/

опенсорс вообще весь без гарантий. не нравится - никто не принуждает. что сказать-то хотел?

опенсорс вообще весь без гарантий. не нравится - никто не принуждает.

опенсорс бывает разный - качественный (linux, glibc, xorg, vlc etc.), где подобные костыли в принципе не возможны, и поделочный - всякие любительские плееры, аплетики и пр.

первым я пользуюсь и помогаю, второе - хлам, обхожусь без него

что сказать-то хотел?

если ты запамятовал - то всего-лишь, что программа под GTK точно так же может не запустится

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

>> тулза отлично работает, и ей плевать что ты о ней не слышал.

> ошибку про GLIBC можно встретить еще чаще, т.к. никто этой тулзой не пользуется

Что ты имеешь в виду? Неотлаженность утилитки? То что о ней никто не знает и по прежнему компилируют в GCC 4.7, и если кому-то всё-таки понадобится совместимость, он воспользуется chroot, а значит chroot нужен, а утилитка не нужна?

- Мне убунта не нравится, что установить?
- Арч.
- А как же Федора? Арч сложный.
- А Федорой никто не пользуется. Ну что, ставишь арч?

т.е. мой ответ, как сделать просто, тебя не устроил,

не любитель костылей и хаков

ты решил потроллить

это ты чушь написал - я лишь ответил, что опенсорс бывает разный

все понятно, давай досвидания.

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

Что ты имеешь в виду? Неотлаженность утилитки?

эта утилитка - автоматизация хака:

http://www.trevorpounds.com/blog/?p=103

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

эта утилитка - автоматизация хака

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

шансы сломаться — те же самые, что у сборки в чруте. результат ведь одинаковый. а то, что утилой мало кто пользуется — это проблемы тех, кто не пользуется. я пользуюсь, все работает, уже достаточно давно — больше 2 лет. в моем проекте, совместимость гарантируется с glibc2.7 и выше, и проблем не возникало ни разу. гемора на порядок меньше чем с чрутом. поддерживаются все архитектуры (я, правда, собираю только под i686 и x86_64). этими сборками пользуются тысячи пользователей.

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

далее, насчет того кто чем пользуется для сборки «чего-то важного». у тебя есть реальная информация, как _все_ люди собирают бинарники, когда нужна совместимость со старым glibc? они точно не пользуются .symver? почему мы до сих пор не видим ссылок на источники этой информации? почему мы видим по твоей же ссылке в комментах кучу людей в комментах, которые этой фичей явно пользуются?

есть что этому противопоставить?

когда ответишь на это — можно будет говорить дальше.

почему мы видим по твоей же ссылке в комментах кучу людей в комментах

это не ко мне вопрос, почему ты говоришь про себя «мы» и в 12 комментариях (из них 5 принадлежат одному человеку) видишь кучу людей, да еще уверен, что все они пользуются этим методом, кстати последний комментарий от автора статьи:

Trevor Pounds August 31, 2012 at 9:16 am

@Michael: Yep. Building and linking to an older version of libc or using a chroot is a much better, less error prone approach.

и почему ты считаешь что это внезапно может поломаться в новых версиях glibc.

например, потому-что в glibc добавляются символы, специфичные для новых версий, в частности с включенным _FORTIFY_SOURCE (который сейчас по умолчанию), да - apgcc его выключает, но glibc продолжается развиваться, а apgcc?

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

чрут никак не поломается от изменений в glibc

почему мы до сих пор не видим ссылок на источники этой информации?

аргумент из разряда «почему мы не видим доказательств отсутствия бога?», посмотри на то, что раздают oracle, ibm, intel, google, id, valve, ms и т.д., на опенсорсные LibreOffice и Firefox, которые собирают на старых RHEL и т.д. - люди либо явно пишут под что собрали и ставят ограничение, либо собирают против древнего glibc на древней системе, у тебя есть обратные примеры?

glibc продолжается развиваться, а apgcc?

а что ты там хочешь развивать? apgcc просто заменяет при линковке символы подсунутые по-дефолту (из /usr/include) на те, которые у него в табличке прописаны, и выбраны по принципу наименьшего возможного ABI. если оно и сломается — то еще на этапе сборки, но никак не в рантайме.

чрут никак не поломается от изменений в glibc

чрут нет, поломаются программы собранные в чруте, в том же случае, когда поломаются программы собранные через apgcc.

посмотри на то, что раздают oracle, ibm, intel, google, id, valve, ms и т.д., на опенсорсные LibreOffice и Firefox, которые собирают на старых RHEL

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

потому, что есть проблема с обратной совместимостью glibc

какая же?

и всегда есть соблазн решить проблему побыстрее

версионные функции через .symver — это и есть «решение проблемы», которая и не проблема вовсе, а фича. если ты соберешь свой пример в чруте с ABI glibc2.0 — ты можешь сам убедиться, что результат у тебя получится тот же самый, что у меня с apgcc. рассказывай, откуда тут берутся проблемы. иначе они выдуманы тобой, и разговор на этом можно закончить.

но, повторюсь, я не видел, чтоб этот хак использовался для серьезных проектов

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

почему ты говоришь про себя «мы»

считай, что я говорил про тебя и меня (= мы).

@Michael: Yep. Building and linking to an older version of libc or using a chroot is a much better, less error prone approach.

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

apgcc просто заменяет при линковке символы

т.е. ты сам не знаешь как он работает, окай

где пруф что все они собирают на старых RHEL?

найдешь в .comment, если знаешь, что это такое

ты до сегодняшнего дня, к примеру, не знал что я использую «этот хак»

знал

который, правда, ты серьезным проектом не считаешь - но это твои проблемы.

не знал, что написание примитивных плееров так подымает ЧСВ, ладно он хотя бы в тот же debian попал, где десятки тысяч пакетов самого разного качества, было бы чем гордится (кстати я там есть ^_^)

мы видим по твоей же ссылке в комментах кучу людей в комментах, которые этой фичей явно пользуются?

это такой же «пруф», как твои голословные утверждения

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

т.е. ты сам не знаешь как он работает, окай

в подробностях не знаю. поверхностно — он генерирует файл apsymbols.h в котором через .symver прописаны символы минимальной версии, а потом как-то подключает его, и подменяет символы которые используются по-умолчанию. этой информации мне достаточно. влезать в дебри мне не было надобности.

ладно он хотя бы в тот же debian попал

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

кстати я там есть ^_^

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

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

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

но лучшее, что мы можем сделать - не тратить время друг друга

я тебе этот вариант предлагал, но твое трололо все пытается что-то доказать.

все понятно, давай досвидания.

....

твое трололо все пытается что-то доказать.

я три часа бежала за вами, чтоб сказать как вы мне безразличны (C), я позорно сольюсь и сбегу из топика, чтоб больше не провоцировать вас

</wota>