= Сообщение: 4956 из 10767 ===================================== RU.UNIX.BSD = От : Valentin Nechayev 2:463/68.300 19 Jan 17 10:00:38 Кому : Alex Korchmar 19 Jan 17 10:00:38 Тема : flow-tools FGHI : area://RU.UNIX.BSD?msgid=2:463/68.300+588079a5 На : area://RU.UNIX.BSD?msgid=<1187506715@ddt.demos.su>+f7ab4a44 = Кодировка сообщения определена как: CP1125 ================================= ============================================================================== Hi,
>>>> Alex Korchmar wrote:
AK>>> http://ebb.org/bkuhn/blog/2009/01/27/gcc-exception.html VN>> Hу и какое это имеет отношение? Они долго телились с тем, что в VN>> лицензии AK> они долго придумывали это ненужно, чтоб никто, ненароком, не сумел AK> заработать деньги, показывая на практике у%#$сть оптимизатора gcc.
OK, я понял всю глубину их глубин. Тем не менее, при всей чудесатости подхода, это не влияет на ответ на вопрос, подключается ли libgcc[_s] к какой-то программе, или нет. Только от того, что в этой программе. Похоже, C++ исключения тянут её за собой безусловно, а вот для чистого C надо извратиться, чтобы зацепить какую-то функцию из этих (причём именно в динамическом варианте, а не статическом - например, операции с long long на 32-битных платформах подключаются обычно статически).
Поигрался с clang - ситуация аналогичная - на чистом C libgcc_s не подтягивается, C++ - тянется (во всех моих доступных версиях clang идёт опора на рядом установленный системный gcc комплект - наверно, на свой ещё полностью не перешли). Причём для фряхи она вообще в /lib.
AK> То есть это целиком и полностью вредительская конструкция, прямо вот в AK> стиле microsoft девяностых годов - сам не ам и другим не дам. Hикакой AK> полезной функциональности не несет (кстати ее "оптимизация" ничуть не AK> нарушит gpl ;-) microsoft с тех пор поумнела, а гнусь окончательно AK> о%$!ела.
Hу насчёт MS я б поспорил... а гнусь таки стала образцом, даже если её напрямую не используешь.
-netch-
... Полная дизассемблятина.
--- * Origin: Dark side of coredump (2:463/68.300)
