Компилятор PCC (http://pcc.ludd.ltu.se/) (Portable C Compiler), развиваемый с целью создания распространяемой под лицензий BSD альтернативы Си-компилятора из состава GCC, доведен (http://marc.info/?l=pcc-list&m=129631476315932&w=2) до состояния при котором удалось произвести сборку FreeBSD-CURRENT на платформе amd64, без внесения каких-либо правок. Более того, по заявлению (http://marc.info/?l=pcc-list&m=129631476315932&w=2) ключевого разработчика, состояние PCC достаточно стабильно и можно планировать скорый выпуск релиза PCC 1.0.
PCC распространяется в рамках лицензии BSD и нацелен на создание полноценного компилятора для языка Си, полностью совместимого со стандартом C99 и частично совместимого с GCC. PCC является в значительной степени переработанным вариантом компилятора Portable C Compiler, разработанного S. C. Johnson в конце 70-х годов прошлого века. Основным разработчиком проекта является Anders Magnusson из команды NetBSD.
Процесс компиляции осуществляется в нескольк...URL: http://marc.info/?l=pcc-list&m=129631476315932&w=2
Новость: https://www.opennet.ru/opennews/art.shtml?num=29433
вот и всё...
ну да яблоко допилит и закроет, и ололо все опять на gcc
>ну да яблоко допилит и закроетТам и так в каждом файле:
Copyright(C) Caldera International Inc. 2001-2002. All rights reserved.
А в лицензии:
* All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed or owned by Caldera
* International, Inc.
Да, Caldera это теперь SCO - патентный тролль.
> Да, Caldera это теперь SCO — патентный тролль.неа, калдера — это калдера, а ско — это ско. про то, что надо упоминать ско, в заголовках ни буквы нет. а калдеру можно — она всё равно тапки откинула.
>неа, калдера — это калдера, а ско — это ско. про то, что надо упоминать ско, в заголовках ни буквы нет. а калдеру можно — она всё равно тапки откинула.Не в этом дело. Такая лицензия несвободна и гпл-несовместима. Подобный пункт даже из бсд-лицензии убрали уже очень давно. Так что проталкивание этого компилятора - чисто маркетинговый шаг против СПО, идя на который бсд-сообщество забывает даже о своей мнимой свободе.
> Такая лицензия несвободнаспорный вопрос.
> и гпл-несовместима.
а тут — да.
> ну да яблоко допилит и закроет, и ололо все опять на gccЯблоко не всемогуще - они могут зажимать clang/llvm, т.к. у них все разработчики оного. Но при чем тут PCC? В общем паранойя хороша в меру :)
Мне кажется не очень жизнеспособна эта вещь, в реале мало кто будет пользоваться, так что будем ждать яблокомпилер вот это будет достойная замена gcc, а пока gcc наше всё
> Мне кажется не очень жизнеспособна эта вещь, в реале мало кто будет
> пользоваться, так что будем ждать яблокомпилер вот это будет достойная замена
> gcc, а пока gcc наше всёУ него своя ниша. После перехода на него NetBSD теперь можно собрать на любой другой UNIX-образной системе в которой есть стандартный shell для любой другой архитектуры (как минимум из 57 поддерживаемых NetBSD). А gcc всё равно нужно бутстрапить...
> Мне кажется не очень жизнеспособна эта вещь, в реале мало кто будет
> пользоваться, так что будем ждать яблокомпилер вот это будет достойная замена
> gcc, а пока gcc наше всёКто знает, кто знает. PCC легче портировать между как программными, так и аппаратными платформами, чем LLVM (не говоря о GCC). Так что для ОС, ориентирующихся на портабельность, PCC очень даже привлекателен.
А мы-то все думали почему portable, а оказывается вот оно что)
> А мы-то все думали почему portable, а оказывается вот оно что)Многие, как показывает практика, не знают, как расшифровывается PHP, а ведь это заметно более известный продукт... Приходится объяснять на пальцах. :)
> Многие, как показывает практика, не знают, как расшифровывается PHP, а ведь это
> заметно более известный продукт... Приходится объяснять на пальцах. :)personal home page.
Может, Pretty Home Pages?
> Может, Pretty Home Pages?да там, по-моему, и сам автор уже толком не помнит. но что-то в этом районе.
>> Может, Pretty Home Pages?
> да там, по-моему, и сам автор уже толком не помнит. но что-то
> в этом районе./me пошёл убивацца
Изначально он был Personal Home Page. Потом было решено провести своего рода ребрендинг, во избежание уничижительных ассоциаций, и оно стало PHP Hypertext Processor.
>> Изначально он был Personal Home Page. Потом было решено провести своего рода
>> ребрендинг, во избежание уничижительных ассоциаций, и оно стало PHP Hypertext Processor.
> как будто если гуано назвать «конфета», оно станет сладким.Не то чтобы PHP был гуано, скорее просто сработал эффект привычного инструмента: сначала простенькую задачу выполняют посредством адекватного инструмента (а для персональной странички он в самый раз), потом возникает задача посложнее — кое-как PHP справляется и с ней, попутно его допиливают; потом человек растёт, уже из института выпускается, и вот работодатель ставит перед ним уже серьёзную задачу, и свежевыпустившийся товарисч принимается её решать посредством того, что знает лучше всего — PHP...
> Не то чтобы PHP был гуанодействительно, почему «был»?
> скорее просто сработал эффект привычного инструмента:
и нерабочего мозга. а также массированного пиара.
для хомепаги вообще можно взять что угодно, хоть bash; это никак не причина писать на баше большие порталы (хоть и возможно, чо).
проблема большинства похапэшников в другом:
а) они считают, что умеют программировать;
б) они считают, что похапэ пригоден для чего-то большего, чем приветмир.
> проблема большинства похапэшников в другом:
> а) они считают, что умеют программировать;К сожалению, да. :(
> б) они считают, что похапэ пригоден для чего-то большего, чем приветмир.
Сейчас-то уже пригоден, хотя вывешивать в инет мне до сих пор боязно. По крайней мере после ухода их главного по безопасности несколько лет назад со словами «ЭТО починить нельзя».
> Сейчас-то уже пригоденда нет, он до сих пор не пригоден. хотя бы в силу убогости самого языка. который подпирают со всех сторон костылями, конечно, но — наследственность…
похапэ для более-менее большого проекта — это то, что здесь вордфильтр не пропустит. чуть-чуть лучше, чем gw-basic, но не на много.
и тем не менее это никак не изменяет факт, что из этого утверждения:
>PCC легче портировать между как программными, так и аппаратными платформами, чем LLVM (не говоря о GCC). Так что для ОС, ориентирующихся на портабельность, PCC очень даже привлекателен.наибольшее количество аппаратно-программных поддерживает именно... кто? :D
NetBSD)
впервые про этот компилятор слышу :D
> Мне кажется не очень жизнеспособна эта вещь, в реале мало кто будет
> пользоваться, так что будем ждать яблокомпилер вот это будет достойная замена
> gcc, а пока gcc наше всёкстати. а зачем, собственно, нужна "замена gcc"?
>> Мне кажется не очень жизнеспособна эта вещь, в реале мало кто будет
>> пользоваться, так что будем ждать яблокомпилер вот это будет достойная замена
>> gcc, а пока gcc наше всё
> кстати. а зачем, собственно, нужна "замена gcc"?Соображений несколько:
1. Архитектура GCC довольно сложна и запутана. По сообщениям агентства ОБС, в давние времена доходило до специального запутывания кода, дабы злобные пропиетарщики не утащили к себе (GPL появилась позже GCC).
2. Регулярные попытки изменить оную архитектуру нередко приводят к необходимости убирать поддержку тех или иных архитектур, поддерживать которые не хватает сил. (см. release notes) С другой стороны, при разработке GCC так или иначе приходится принимать те или иные архитектурные решения, которые связаны чисто с приоритетами для конкретных задач - а ведь эти приоритеты отнюдь не разделяются всеми людьми на свете.
3. GCC распространяется под некошерной для многих проектов лицензией (вопрос о том, хорошо это или плохо, предлагаю оставить за кадром, здесь просто перечисление причин).
4. Развитие GCC довольно жёстко контролируется GNU, как следствие, инновациям там пробиваться сложнее. (см., например, историю создания egcs)
собственно, никто же не мешает сделать форк GCC и пилить куда угодно (egcs, ага).то, что код в GCC весьма сложный — это факт; однако же другой компилятор с сопоставимыми ТТХ вряд ли будет сильно проще. а если ТТХ не сопоставимы — то это уже не «замена», а так, очередной компилятор просто.
опять же: с чего бы у «замены» хватало сил на 100500 архитектур? выкидывают-то архитектуры в основном не потому, что оно больше никак не лезет в код, а потому, что некому ними заниматься (сиречь, они нафиг не нужны никому, кроме, может быть, трёх с половиной инвалидов). точно такая же ситуация будет и у «замены».
то есть, по сути, любая попытка сделать «замену GCC» превратится в попытку «написать ту же самую GCC, но с нуля, с Такой-То-Лицензией и печеньками». бессмысленная трата сил, по-моему.
и касательно темы: pcc вообще с GCC соревноваться не собирается, это игроки совершенно разного масштаба. и ничего против pcc я не имею — наоборот, только рад, что его допиливают.
(я надеюсь, мы тут друг друга верно поняли, и под GCC подразумевали GNU Compiler Collection?)
> собственно, никто же не мешает сделать форк GCC и пилить куда угодно
> (egcs, ага).Можно. Но, опять же, сложно. Если архитектура изначально слишком запутанная, проще сделать своё, чем форкать. Freeswitch, например, таким образом появился.
> то, что код в GCC весьма сложный — это факт; однако же
> другой компилятор с сопоставимыми ТТХ вряд ли будет сильно проще. а
> если ТТХ не сопоставимы — то это уже не «замена», а
> так, очередной компилятор просто.Ну вот тот же LLVM играет в той же лиге (насколько убедительно на на данный момент - другой вопрос). Сравните хотя бы объём строк кода на ключевых участках. Строго говоря, по фичам LLVM даже богаче GCC. Последний берёт скорее текущим уровнем портированности, а также, косвенно, наличием привязки к GNU toolchain во многих проектах, для которых GCC - не просто набор компиляторов.
> опять же: с чего бы у «замены» хватало сил на 100500 архитектур?
Вполне возможно, что за счёт более грамотной внутренней организации проекта поддерживать дополнительные архитектуры будет проще. Что мы, собственно, и имеем в некоторых случаях.
> выкидывают-то архитектуры в основном не потому, что оно больше никак не
> лезет в код, а потому, что некому ними заниматься (сиречь, они
> нафиг не нужны никому, кроме, может быть, трёх с половиной инвалидов).
> точно такая же ситуация будет и у «замены».Может, и нужны, только вот пилить ещё и GCC помимо своего проекта зачастую накладно. Почему? - см. выше про сложность.
> то есть, по сути, любая попытка сделать «замену GCC» превратится в попытку
> «написать ту же самую GCC, но с нуля, с Такой-То-Лицензией и
> печеньками». бессмысленная трата сил, по-моему.Не "ту же самую". LLVM тот же изначально позиционировался иначе (ключевой момент в буковках VM). Это уже как следствие он начал конкурировать с GCC.
Что же касается PCC - тут мне сложнее сказать, близко в нём я не ковырялся. То, что видел, выглядело достаточно читаемым, и задел у него есть — но за рамки Си и Фортрана (и то под вопросом) он, вроде, лезть не собирается.
Ну а насчёт бессмысленности траты сил из-за лицензионного вопроса - фор хум хау. Предлагаю на эту тему не спорить, а просто остаться каждый при своём мнении. :)
> и касательно темы: pcc вообще с GCC соревноваться не собирается, это игроки
> совершенно разного масштаба. и ничего против pcc я не имею —
> наоборот, только рад, что его допиливают.Полностью согласен. Это примерно как универсальная отвёртка со сменными насадками, и простая отвёртка под конкретный размер. Если основная работа проходит с определённым типом винтов, второе предпочтительнее как минимум за счёт сочетания эргономики и.надёжности...
> (я надеюсь, мы тут друг друга верно поняли, и под GCC подразумевали
> GNU Compiler Collection?)Верно.
добавлю: мне ещё нравятся расширения компилятора C в GCC. поэтому мои проекты, например, к GCC хорошо привязаны.
PCC в базовой системе — та вещь, которую ждут. Во-первых, это возможность отказаться от GCC 4.2.1 в базовой системе и перенести выбор нужной версии GCC для компиляции приложений на Коллекцию портов.
Во-вторых, он очень маленький по сравнению с GCC и тулчейном. А значит пересборка системы из обновлённых исходников будет занимать заметно меньше времени.
>Во-вторых, он очень маленький по сравнению с GCC и тулчейном. А значит пересборка системы из обновлённых исходников будет занимать заметно меньше времени.абсолютно спорная взаимосвязь.
если такая взаимосвязь вообще есть.
GCC и тулчейн собирается примерно полчаса. Сборка всей системы и ядра [amd64] занимает около полутора часов на среднем офисном компе.
и что бы это должно доказать? я прям в недоумении.
где сравнение типа "pcc сам собирается за 5 минут, а всю систему собирает за 30 минут"?
я почему то уверен, что результат будет таков "pcc сам собирается за 5(!!?) минут, а всю систему собирает за сутки". и вот почему - ни сикэша, ни возможности параллельной сборки по сети,...меньше кода - это и меньше функциональности. чудес не бывает.
про возможности оптимизации вообще молчу http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.htmlзы:
не знаю что там за система такая, но лично мой world собирается чуть меньше чем за сутки.
и это на i5 с 4гб озу с MAKEOPTS="-j6 -s". да, у меня чуть более 2000 поржежей.
но самое интересное - я бы подождал и ещё пол-часика, если бы в результате получил ещё более быстрые и маложрущие проги.
другими словами - процесс компиляции не самоцель. целью является результат.
world в FreeBSD — это базовая система без пакетов приложений из Коллекции портов.
ну значит наткнулись на разные понятия одного слова.
в генте базовая система это system, а всё остальное - world.
в любом случае гцц 4.6 я уже использую, тк только с этой версии есть нативная поддержка моего проца i5.
> ну значит наткнулись на разные понятия одного слова.
> в генте базовая система это system, а всё остальное - world.
> в любом случае гцц 4.6 я уже использую, тк только с этой
> версии есть нативная поддержка моего проца i5.Это не нативная поддержка. Поддерживался он исправно и раньше. Просто в GCC появилась возможность "привязать" программу к i5, возможно, выгадав где-то пару тактов за счёт сильно специфических оптимизаций касаемо длины конвеера и пр.
не вводите народ в заблуждение.
это и есть поддержка данных процов.
и эти "2 такта" как-то уж очень не плохо сказались на общей производительности моей системы.
зыж:
а вообще (с 4.4 кажется) я просто ставлю -march=native и компилятор сам определяет текущую платформу. но поддержка i5/i7 появилась в 4.6 при сотрудничестве с интел.
> не вводите народ в заблуждение.
> это и есть поддержка данных процов.То есть код, сгенерированный старыми версиями GCC, не должен работать на i5? Странно, почему же тогда он работает на моём ThinkPad X201i с i5, на котором я сейчас пишу эти буковки?
> и эти "2 такта" как-то уж очень не плохо сказались на общей
> производительности моей системы.Хм. Можно циферки? Чтобы не получилось как с золотыми проводами... :)
> зыж:
> а вообще (с 4.4 кажется) я просто ставлю -march=native и компилятор сам
> определяет текущую платформу. но поддержка i5/i7 появилась в 4.6 при сотрудничестве
> с интел.Это не поддержка процессоров, а принудительное учитывание их особенностей. Не более и не менее.
> Это не поддержка процессоров, а принудительное учитывание их особенностей. Не более и
> не менее.э… а что тогда такое «поддержка процессора»? O_O
>> Это не поддержка процессоров, а принудительное учитывание их особенностей. Не более и
>> не менее.
> э… а что тогда такое «поддержка процессора»? O_OКогда сгенерированный компилятором код работает (и работает корректно) на этом процессоре, разумеется.
мой N-цатый опенврт рад этому определению.
Дело не только в процессоре но и в котроллере винчестера и самом винчестере ... винт наверно RPM 5000?На нормальной машине 30 минут делов с небольшими правками make.conf типа:
NO_FORTRAN=true
NO_I4B=true
NO_KERBEROS=true
NO_LPR=true
NO_SHAREDOCS=true
NO_GAMES=yes
WITHOUT_GAMES=yes
WITHOUT_INET6=yes
WITHOUT_INET6_SUPPORT=yes
WITHOUT_IPV6=yes
NO_INET6=true
NO_INFO=true
NO_PROFILE=yes
WITHOUT_PROFILE=yes
WITHOUT_X11=YES
NO_X11=YES
X11BASE=${LOCALBASE}
NO_GUI="true"
NO_X="true"
BSDуны такие бздуны, хлебом не корми дай только поизобретать велосипед, попереписывать и без того открытое по своей самой открытой лицензией.
>и без того открытое по своей самой открытой лицензией.Так лицензия BSD - это вовсе не про открытость и свободу пользователей. Это про возможность взять и закрыть код, т.е. про возможность лишить пользователей их свободы.
Приведи пример как это можно сделать. Головой бы думал перед тем как бред писать.
Лицензия BSD позволяет использовать код на своё усмотрение, в том числе добавить его в свой закрытый проект без необходимости открывать исходники(вот поэтому Apple и Microsoft так любят эту лицензию - ведь она позволяет поживится нахаляву чужим кодом, без всяких ограничений). Именно поэтому и была в своё время создана GPL - она запрещает закрывать взятый код.
Хватит уже этой мантры! Достало. Брать - да. Закрывать - нет.
> Хватит уже этой мантры! Достало. Брать - да. Закрывать - нет.конечно. зачем закрывать, если можно просто не открывать? вот интересно: кто-нибудь верит, что если бы KHTML был под BSD, мы бы сейчас имели исходники WebKit?
> что если бы KHTML был под BSD, мы бы сейчас имели
> исходники WebKit?Я совершенно уверен в том, что мы бы имели как минимум исходники KHTML. И никакой Apple никак бы не смог их "закрыть", как утверждают здесь некоторые долбодятлы.
> Я совершенно уверен в том, что мы бы имели как минимум исходники
> KHTML. И никакой Apple никак бы не смог их "закрыть", как
> утверждают здесь некоторые долбодятлы.ага. и WebKit, который превосходит KHTML по всем параметрам, но закрытый. как-то слабо такая перспектива впечатляет.
По сути всё правильно говорите, другое дело, что формулировка "закрывать код" тут несовсем подходит.
> По сути всё правильно говорите, другое дело, что формулировка "закрывать код" тут
> несовсем подходит.я такого не говорил, но когда такое читаю, то понимаю однозначно: "закрыть улучшеный силами проприетарщиков код". при "неотдавании" в том числе закрывается и улучшеный код оригинала, а не только дописки. как-то так.
>> Я совершенно уверен в том, что мы бы имели как минимум исходники
>> KHTML. И никакой Apple никак бы не смог их "закрыть", как
>> утверждают здесь некоторые долбодятлы.
> ага. и WebKit, который превосходит KHTML по всем параметрам, но закрытый. как-то
> слабо такая перспектива впечатляет.Ну вот есть сейчас WebKit и KHTML. Это как-то исправило ситуацию в KDE c его глюкастым konqueror? Да никак это не повлияло на KHTML, и никак ему не помогло. И на WebKit перейти не могут, потому как кеды завязаны сильно на KHTML. Ну что скажите, сильно в данном случае помогла GPL исходному проекту KHTML?
> могут, потому как кеды завязаны сильно на KHTML. Ну что скажите,
> сильно в данном случае помогла GPL исходному проекту KHTML?это интимные проблемы кедов, пусть их кедеры и решают. лично я вижу отличный движок WebKit, который можно использовать в куче проектов. и никому нафиг не нужный KHTML, который пока от кедов оторвёшь — борода до Канады дорастёт. профиты для KHTML — сомнительны. профиты для некедеров — налицо. так и работает опенсорц: большинство получают профиты, не успевшие вовремя адаптироваться остаются со старой версией.
в итоге — ситуация явно лучше, чем если бы был только KHTML, который вне кедов неюзабелен.
>ага. и WebKit, который превосходит KHTML по всем параметрам, но закрытый. как-то слабо такая перспектива впечатляетБыло: KHTML
Стало: KHTML + Webkit.Ну нужно быть очень умным, чтобы понять, что стало больше, чем было. Даже если Apple закрывает WebKit, оригинальный KHTML никуда не денется. Поэтому никакого закрывания и тем более воровства, как некоторые тут умудряются это называть, здесь нет и в помине. Это - высшая форма добродетели - делиться, не требуя ничего взамен. БЕСКОРЫСТНО. Пациентам с GNU головного мозга этого, увы, не понять.
> Было: KHTML
> Стало: KHTML + Webkit.только пациентам с BSD головного мозга, увы, не понять, что если бы KHTML был под BSDL — то так бы и остался один KHTML. и проприетарный WebKit у яблока.
впрочем, бздуны на что угодно согласны, лишь бы только не GPL. хоть на проприетарщину.
>> Хватит уже этой мантры! Достало. Брать - да. Закрывать - нет.
> конечно. зачем закрывать, если можно просто не открывать? вот интересно: кто-нибудь верит,
> что если бы KHTML был под BSD, мы бы сейчас имели
> исходники WebKit?KHTML, насколько помнится, под LGPL, не?
> KHTML, насколько помнится, под LGPL, не?а это без разницы в данном случае.
ну сафари работает отлично. а вот в "кустарщине" нет браузера чтобы разок да не упал :).
> ну сафари работает отлично. а вот в «кустарщине» нет браузера чтобы разок
> да не упал :).а при чём тут брофзеры? я про движок, вообще-то. который, например, отлично и без падений работает в моих программах: я на нём все морды делаю; быстро, удобно, кастомизируемо. вдобавок я ещё получил на халяву встроеный скриптовый язык. два в одном, аднака.
>на халявуКлючевое слово во всей этой, и подобной демагогии.
>>на халяву
> Ключевое слово во всей этой, и подобной демагогии.ты бы читать учился, что ли. ну, то есть, не только читать, но ещё и смысл написанного понимать. чтение по ключевым словам может выставить тебя дураком — вот как сейчас это вышло.
> Хватит уже этой мантры! Достало. Брать - да. Закрывать - нет.Не путайте смену статуса для открытого кода с открытого на закрытый и закрытие кода, основанного на открытом коде. Если запатчить GPL-код, патч придется открывать, а если запатчить BSD-код - открывать патч не нужно.
Да на здоровье! С какого перепою я должен с человека стрясать ЕГО патчи? Захочет - сам отдаст. Но МОЙ код как был открытым так открытым и остается.
Капитан Очевидность просил передать, что возможость использовать код в закрытом проекте и возможность сделать код закрытым - разные вещи. В связи с этим просил считать поступившую вам ранее просьбу думать головой актуальной.
Допустим есть проект под BSD лицензией и есть "сообщество", которое пилит этот проект.
Потом появляется одна богатая фирма, берет проект, немного улучшает его, закрывает исходники и на свои бабки раскручивает его рекламируя везде.
Далее фирма предлагает пользоваться улучшенным "продуктом" бесплатно - пользователи довольны и об изначальном открытом проекте забывают.
Как результат - стагнация открытого проекта.
Что мы и имеем на примере FreeBSD :)А вот GPL вынуждает фирму к возвращению улучшений в родительский проект.
Как результат - развитие и процветание открытого проекта.
Что мы и имеем на примере Linux.
> Как результат - стагнация открытого проекта.
> Что мы и имеем на примере FreeBSD :)Уважаемый тролль-1, какой такой коммерческий продукт раскручивался и рекламировался некой богатой фирмой? А, еще я так понимаю он был суперраскручен и всем известен, ведь в результате этого произошла "стагнация" FreeBSD. Назовите сей чудный коммерческий продукт. :)
SolarisВаш К.О
> SolarisИ в чем конкретно? Вы вспомнили Berkeley Software Distribution и 2.9BSD on VAX? :)
FreeBSD появился в 1993 году предшественник 386BSD
Solaris появился в 1992 году предшественник SunOS
> Solaris появился в 1992 году предшественник SunOSНе совсем так. SunOS - BSD Unix, a Solaris - System V.
http://upload.wikimedia.org/wikipedia/commons/5/50/Unix_hist...
http://en.wikipedia.org/wiki/Unix
И.. эта коммерческая фирма, заинтересованная в минимизации затрат, возвращает часть собственного кода в BSD проект. Так, что и волки сыты и.. Примеры сами найдете.
"пользователи довольны и забывают" -- это скорее более верно в отношении линукса, где не принято упоминать крутость от наличия блоба nVidia и различных firmware, и идеи "свободы и открытости" кода на расстоянии ближе километра друг от друга.
> где не принято упоминать крутость от наличия блоба nVidia и различныху меня стоит блоб nVidia. я крут.
>Как результат - стагнация открытого проекта.
>Что мы и имеем на примере FreeBSDНаблюдаю эту стагнацию 15 лет. Все стагнирует и стагнирует :)
> Допустим есть проект под BSD лицензией и есть "сообщество", которое пилит этот
> проект.
> Потом появляется одна богатая фирма, берет проект, немного улучшает его, закрывает исходники
> и на свои бабки раскручивает его рекламируя везде.
> Далее фирма предлагает пользоваться улучшенным "продуктом" бесплатно - пользователи довольны
> и об изначальном открытом проекте забывают.Сие есть чушь, BSD это не public domain, раскручивая своё будь добр указать, откуда пришёл основной код. С кодом под BSD можно делать всё что угодно, кроме как присваивать.
это если наследственный код распространяешь в исходниках.
а если нет, если только блобом - то и не нать. стыдно не знать, товарищ.
Читайте лицензию до полного BSD просветления!
Независимо от формы распространения продукта, производного от БЗД, вы обязаны ссылаться на авторов исходного продукта, что обычно указывается в списке продуктов от "третьих сторон".
прочитал, мужик.
вот если свою прогу открываю, то должен в исходниках указать - где, что, когда.
а вот если не открываю - то только в редми одну строчку - заюзал я тут код васи пупкина (какого васи, какой код, какой версии - не обязательно)
Допустим есть проект под GPL лицензией и есть "сообщество", которое пилит этот проект.Проект называется MySQL.
Потом появляется одна богатая фирма, берет проект, немного улучшает его,
Фирма называется Sun Microsystems, Inc.
>закрывает исходники и на свои бабки раскручивает его рекламируя везде.
>Далее фирма предлагает пользоваться улучшенным "продуктом" бесплатно - пользователи довольны и об изначальном открытом проекте забывают.Теперь это Oracle.
> Как результат - стагнация открытого проекта.
MySQL стагнирует.
> Что мы и имеем на примере FreeBSD :)
FreeBSD за последние четыре года взошла на десктопы и предложила ZFS для промышленных систем хранения данных.
> А вот GPL вынуждает фирму к возвращению улучшений в родительский проект.
То-то я смотрю, что Btrfs до сих пор не умеет RAID-5. Всё Oracle виновата — не хочет бурными темпами её улучшать.
> Как результат - развитие и процветание открытого проекта.
Угу. ZFSv28 в FreeBSD -CURRENT.
> Что мы и имеем на примере Linux.
GNU/Linux в последние три года не развивается более чем полностью. Его держат на плаву только сторонние десктопные приложения, которые давно портированы на FreeBSD.
> Допустим есть проект под GPL лицензией и есть "сообщество", которое пилит этот
> проект.
> Проект называется MySQL.
> Потом появляется одна богатая фирма, берет проект, немного улучшает его,
> Фирма называется Sun Microsystems, Inc.Она же не просто так появилась, самые умные из того самого сообщества получили за овеществленные и неовеществленные наработки сообщества около 800 миллионов долларов США, которые положили себе в карман. С остальным сообществом кто-то при этом поделился?
И сразу-же после продажи- эти ловкачи стали вопить что SUN должна чего-то кому-то открыть...иначе они..они...форкнут проект...
э-э-э, не нервничайте так. нервные клетки не восстанавливаются.
зыж
интересно, а чегой-то мастдайный тролль так за оракл распереживался?...
> Она же не просто так появилась, самые умные из того самого сообщества получили за
> овеществленные и неовеществленные наработки сообщества около 800 миллионов долларов США,
> которые положили себе в карман. С остальным сообществом кто-то при этом поделился?Верно выше сказали, про любителей халявы. А с какой стати они должны были делиться, если сам и заработали, своим собственным умом?
> GNU/Linux в последние три года не развивается более чем полностью. Его держат на плаву только сторонние десктопные приложения, которые давно портированы на FreeBSD.У меня впечатление, что держат его на плаву блобы от Адобе и Скайпа.
> У меня впечатление, что держат его на плаву блобы от Адобе и
> Скайпа.а у меня их нет. ЧЯДНТ?
> а у меня их нет. ЧЯДНТ?Очевидно, Вы не пользуетесь ни скайпом, ни flash плеером ;)
> Приведи пример как это можно сделать. Головой бы думал перед тем как
> бред писать.Ну идите, получите у жунипера или майкрософта сорсы свободной платформы, и измените что-нить в их фирмварях. Что, вы ратуете за свободу вендора зажать и не делиться? А, ну вендоры воздадут, факт. Вон например армовские нетбуки и планшеты на тегре. Нвидия там попользовала свою свободу зажимать и не делиться, не дав ни спеков, ни сорсов дров, как обычно. И решила за всех, что они будут жрать на этой платформе только вполне конкретные версии ядер. Кстати, линуксных, если что. Что ж нвидия так своих соратников радеющих за свободу прокатила, не сделав для них дрова под ARM вообще? И как, вы будете радеть за свободу нвидии ... с голой жопой вместо дров, да? :)
$ du -h -d 0 /lib/firmware/
30M /lib/firmware/
> BSDуны такие бздуны, хлебом не корми дай только поизобретать велосипед, попереписывать
> и без того открытое по своей самой открытой лицензией.ничего плохого в ещё одном неплохом компиляторе не вижу, например.
что лучше - иметь два недопиленных компилятора или один допиленный?
> что лучше - иметь два недопиленных компилятора или один допиленный?лучше -- два допиленых. что, собственно, и наблюдаем.
отставание по тестам = недопиленность. gcc тоже есть куда пилить, оптимизации там разные хитрые, разобраться с -О3, какие там "оптимизации" когда во вред, а когда во благо и т.д.
> отставание по тестам = недопиленность. gcc тоже есть куда пилить, оптимизации там
> разные хитрые, разобраться с -О3, какие там "оптимизации" когда во вред,
> а когда во благо и т.д.Отставание мизерное на самом деле. Оптимизации можно и в PCC крутить, речь шла о наиболее отлаженных настройках, которые по умолчанию. Вы разве не знаете, часом, почему все нормальные ОС собираются с -O2? ;) И потенциал у PCC сейчас больше. Как минимум за счёт его "заточенности".
> Вы разве не
> знаете, часом, почему все нормальные ОС собираются с -O2? ;)традиция?
>> Вы разве не
>> знаете, часом, почему все нормальные ОС собираются с -O2? ;)
> традиция?Потому что это наиоблее отлаженный режим оптимизированной кодогенерации. Я понимаю, на свете много наивных людей, считающих, что компиляторы не ошибаются... К сожалению, ошибаются. Бывают случаи, что сторонний софт приходится вообще под -O0 собирать принудительно. Потому что иначе у него едет крыша, стоит ему попасть в условия, отличающиеся от условий тестов разработчиков.
это от недостатка знаний. вот в моём гентушном make.conf
CFLAGS="-O2 -march=native -ftree-vectorize -pipe -ftree-parallelize-loops"зы:
к чему я это всё написал? да к тому, что О2 - это далеко не все возможные оптимизации. это только один из старейших флагов.
вот список http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html того многообразия, который пока и не снился остальным.
> это от недостатка знаний. вот в моём гентушном make.conf
> CFLAGS="-O2 -march=native -ftree-vectorize -pipe -ftree-parallelize-loops"
> зы:
> к чему я это всё написал? да к тому, что О2 -
> это далеко не все возможные оптимизации. это только один из старейших
> флагов.
> вот список http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html того многообразия,
> который пока и не снился остальным.Для непонятливых: под ошибками кодогенерации понимаются не ляпы оптимизации как таковой, а генерация _некорректного_ кода (вплоть до invalid opcode). А перечисленные вами флаги оптимизации — это как раз костыли. Вы машину покупаете для того, чтобы на ней ехать, или чтобы доводить до ума? Не, поковыряться, побаловаться — оно, конечно, занятно. Но для реальной работы нужны отлаженные решения. А с отлаженностью как раз и возникают проблемы (зачастую неочевидные, так как срабатывают лишь в каких-то определённых ситуациях), и в среднем тем большие, чем больше применено нестандартных опций оптимизации.
для ещё более непонятливых:
>Отставание мизерное на самом деле. Оптимизации можно и в PCC крутить, речь шла о наиболее отлаженных настройках, которые по умолчанию.чтобы что-то там можно было крутить, это что-то должно быть в наличии, а его пока нет.
а вот это отдельно прокоментирую:
>А перечисленные вами флаги оптимизации — это как раз костыли. Вы машину покупаете для того, чтобы на ней ехать, или чтобы доводить до ума?я машину купил с такими вот костылями:
# cat /proc/cpuinfo | grep flags
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat dts tpr_shadow vnmi flexpriority ept vpidчто самое интересное - эти костыли я хочу заюзать.
>[оверквотинг удален]
> я машину купил с такими вот костылями:
> # cat /proc/cpuinfo | grep flags
> flags : fpu vme de pse tsc msr pae mce cx8
> apic sep mtrr pge mca cmov pat pse36 clflush dts acpi
> mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp
> lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
> pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr
> pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat dts tpr_shadow vnmi
> flexpriority ept vpid
> что самое интересное - эти костыли я хочу заюзать.Поздравляю. А вы в курсе, например, что MMX, SSE и иже с ними в обычных программах нафиг не сдались? Обычный код состоит сплошь из ветвлений (в т.ч. циклов), вызовов функций, выделении и освобождении памяти, записи значений в память... Самые частые арифметические операции — сложение, умножение и вычитание, причём над индивидуальными переменными. А все эти SIMD предназначены для сильно специфических мест.
Ну а что такое ACPI, MTRR, APIC и так далее — гугль вам в руки; к оптимизации они вообще отношения не имеют.
у меня уже очень стойкое чувство, что я много где более в курсе чем вы. :D
ха! да это даже не смешно - тут весь мир обсуждает почему флоатингпоинт вычисления на 64-битах требуют sse2, а на 32-х почему-то по старинке.
и уж тем более не мог предположить, что кто-то ещё не в курсе что:
>SSE2 extends MMX instructions to operate on XMM registers, allowing the programmer to completely avoid the eight 64-bit MMX registers "aliased" on the original IA-32 floating point register stack.ps:
надо срочно интелю и амд рассказать что они не нужны. а то ребята как-то не в курсе.
а ребята из огрызка вообще оборзели - их макось на проц без поддержки ссе3 уже вообще не ставится.
>[оверквотинг удален]
> флоатингпоинт вычисления на 64-битах требуют sse2, а на 32-х почему-то по
> старинке.
> и уж тем более не мог предположить, что кто-то ещё не в
> курсе что:
>>SSE2 extends MMX instructions to operate on XMM registers, allowing the programmer to completely avoid the eight 64-bit MMX registers "aliased" on the original IA-32 floating point register stack.
> ps:
> надо срочно интелю и амд рассказать что они не нужны. а то
> ребята как-то не в курсе.
> а ребята из огрызка вообще оборзели - их макось на проц без
> поддержки ссе3 уже вообще не ставится.Вы таки невнимательно читали. Ещё раз вернитесь и прочитайте мой коммент. Особенно слова вроде "обычных" и "специфических мест".
да нет! :D
я всё правильно прочитал. и какими бы специфическими эти задачи не были, но они используются в системе, где установлено >2000 портежей.
и я не собираюсь от них отказыватся. тем более терять в производительности.
вот для примера пакеты с поддержкой sse
# equery h sse
* Searching for USE flag sse ...
[IP-] [ ] app-cdr/dvd95-1.6_p0:0
[IP-] [ ] dev-libs/DirectFB-1.4.5:0
[IP-] [ ] kde-base/kdelibs-4.5.5:4.5
[IP-] [ ] kde-base/ksplash-4.5.5:4.5
[I-O] [ ] media-gfx/blender-9999:2.5
[IP-] [ ] media-gfx/gimp-2.6.11:2
[IP-] [ ] media-libs/babl-0.1.2:0
[IP-] [ ] media-libs/flac-1.2.1-r3:0
[IP-] [ ] media-libs/gegl-0.1.2:0
[IP-] [ ] media-libs/libvpx-0.9.5:0
[IP-] [ ] media-libs/opencv-2.1.0:0
[IP-] [ ] media-libs/qimageblitz-0.0.6:0
[IP-] [ ] media-libs/speex-1.2_rc1:0
[IP-] [ ] media-sound/ardour-2.8.7:0
[IP-] [ ] media-sound/jack-audio-connection-kit-0.118.0:0
[IP-] [ ] media-sound/mpg123-1.13.1:0
[IP-] [ ] media-video/mplayer-1.0_rc4_p20101219:0
[IP-] [ ] media-video/transcode-1.1.5-r2:0
[IP-] [ ] media-video/vlc-1.1.6:0
[IP-] [ ] sci-libs/fftw-3.2.2-r1:3.0
> да нет! :D
> я всё правильно прочитал. и какими бы специфическими эти задачи не были,
> но они используются в системе, где установлено >2000 портежей.
> и я не собираюсь от них отказыватся. тем более терять в производительности.Да никто и не просит от них отказываться. Просто программы, алгоритмы которых _реально_ оптимизируемы с помощью того же SSE, обходятся и без этих ключей — такие узкие места выписываются на ассемблере, который позволяет получить полную отдачу от SIMD. Более того, нормальная программа сама будет использовать нужный вариант реализации алгоритма, в зависимости от процессора, на котором работает; более халтурно сделанные "зашивают" это знание в себя при компиляции.
Чуть не забыл: ICC умеет неплохо распознавать некоторые паттерны, которые поддаются оптимизации посредством SIMD; однако полностью полагаться на компилятор в этом вопросе всё равно не стоит.
ну это вообще слив. при чём двойной:
1) чтобы использовать возможности проца мне нужен только ассемблер и никаких готовых библиотек на языке С/с++. с таким же успехом можно предложить всё на асме писать. при чём я даже соглашусь - в идеальном мире с идеальными программистами так бы и было. но не будет в этой реальности.
2) icc конечно исправит недостатки сабжа, угу.
более полный фэйл мог бы случится только в утверждении - оптимизации вообще не нужны.зы:
а ведь это был разговор только об особенностях проца.
и мы даже ещё близко не подобрались к таким плюшкам, как openmp - http://ru.wikipedia.org/wiki/OpenMP - который поддерживается гцц начиная с 4.2 и т.д.
> 1) чтобы использовать возможности проца мне нужен только ассемблер и никаких готовых
> библиотек на языке С/с++. с таким же успехом можно предложить всё
> на асме писать. при чём я даже соглашусь - в идеальном
> мире с идеальными программистами так бы и было. но не будет
> в этой реальности.
> 2) icc конечно исправит недостатки сабжа, угу.
> более полный фэйл мог бы случится только в утверждении - оптимизации вообще
> не нужны.Может быть, я действительно тупее паровоза, но идею обоих ваших выражений я не понял.
> зы:
> а ведь это был разговор только об особенностях проца.
> и мы даже ещё близко не подобрались к таким плюшкам, как openmp
> - http://ru.wikipedia.org/wiki/OpenMP - который поддерживается гцц начиная с 4.2 и т.д.OpenMP — это совсем другой разговор, как и всё многопоточное программирование.
> полную отдачу от SIMD. Более того, нормальная программа сама будет использовать
> нужный вариант реализации алгоритма, в зависимости от процессора, на котором работает;
> более халтурно сделанные "зашивают" это знание в себя при компиляции.чую запашок проприетарщика.
>> полную отдачу от SIMD. Более того, нормальная программа сама будет использовать
>> нужный вариант реализации алгоритма, в зависимости от процессора, на котором работает;
>> более халтурно сделанные "зашивают" это знание в себя при компиляции.
> чую запашок проприетарщика.Да-да, разработчики MPlayer — такие пропиетарщики...
> Да-да, разработчики MPlayer — такие пропиетарщики...то-то у меня mplayer детектирует камень и собирает специально под него оптимизированый код.
>> Да-да, разработчики MPlayer — такие пропиетарщики...
> то-то у меня mplayer детектирует камень и собирает специально под него оптимизированый
> код.Ему можно сказать и чтобы использовал автодетект в рантайме.
> Ему можно сказать и чтобы использовал автодетект в рантайме.можно. потому что пользователи can not into building from sources. и для этих несчастных пришлось пилить нафиг никому больше не нужный код. (нет, я не гентушник)
>> Ему можно сказать и чтобы использовал автодетект в рантайме.
> можно. потому что пользователи can not into building from sources. и для
> этих несчастных пришлось пилить нафиг никому больше не нужный код. (нет,
> я не гентушник)Такой автодетект ничего не стоит: при запуске указатели на функции определить, например, и всё. Главная сложность — это как раз реализация алгоритмов, но их-то всё равно надо реализовывать, в любом случае. :)
> Такой автодетект ничего не стоитничего не стоит только то, чего нет. а автодетект стоит как минимум:
а) написания кода детекта;
б) векторизации вызовов функций (indirect call вместо direct call).
>> Такой автодетект ничего не стоит
> ничего не стоит только то, чего нет. а автодетект стоит как минимум:
> а) написания кода детекта;cpuid и ветка if'ов в случае x86; на других архитектурах что-то своё тоже есть. Это на самом деле не сложно, плюс в инете есть куча уже готовых решений.
> б) векторизации вызовов функций (indirect call вместо direct call).
В Си (и асме, разумеется) накладных расходов может и не быть, так как для Си принципиальной разницы нет: напишете вы
myfunc(a, b, c);
или(*myfunc)(a, b, c);
В крайнем случае — одно дополнительное безусловное (т.е., не перезагружающее конвеер) разыменование указателя, время совершения которого — величина пренебрежимо малая, и не только на современных процессорах с их гигантскими кэшами. Ведь основное время проводится внутри этих функций.
тем не менее нельзя сказать, что это "ничего не стоит".а разница есть. хотя бы в том, что interprocedural optimization накроется медным тазом.
> тем не менее нельзя сказать, что это "ничего не стоит".
> а разница есть. хотя бы в том, что interprocedural optimization накроется медным
> тазом.GCC не трогает ассемблерные конструкции (которые, как уже говорилось, и составляют ядро таких функций). Поэтому ни о какой оптимизации в этих функциях речи и так быть не может.
> GCC не трогает ассемблерные конструкции (которые, как уже говорилось, и составляют ядро
> таких функций). Поэтому ни о какой оптимизации в этих функциях речи
> и так быть не может.то есть, что такое «interprocedural optimization» ты не знаешь. зачем тогда говоришь?
>> GCC не трогает ассемблерные конструкции (которые, как уже говорилось, и составляют ядро
>> таких функций). Поэтому ни о какой оптимизации в этих функциях речи
>> и так быть не может.
> то есть, что такое «interprocedural optimization» ты не знаешь. зачем тогда говоришь?Это вы не знаете, раз спорите. Повторяю ещё раз: то, что находится в виде ассемблерных вставок (или просто отдельных ассемблерных файлов) GCC НЕ оптимизирует. Поэтому никакие поддающиеся оптимизации паттерны он в них тоже выискивать не будет. Оптимизатор попросту игнорирует этот код. Так понятно?
ну хватит, хватит уже расписываться в незнании. все, кому надо, поняли, что про interprocedural optimization вы прочли у меня в каменте впервые.
> ну хватит, хватит уже расписываться в незнании. все, кому надо, поняли, что
> про interprocedural optimization вы прочли у меня в каменте впервые.Я про них прочёл первый раз в анонсе GCC (уже и не вспомню, какой версии). А вот где вы про них прочли, я не знаю. Сходите, почитайте сами, что ли, что это такое, и почему в данных условиях о них говорить всё равно не приходится. Надоело всё разжёвывать.
тогда может разработчик mplayer'а объяснит сии флаги в его коде:media-video/mplayer-1.0_rc4_p20101219:
...
+ + sse : fast floating point optimization for PentiumIII+ class chips
+ + sse2 : faster floating point optimization for SSE2 capable chips
+ + ssse3 : faster floating point optimization for SSSE3 capable chips (Intel Core 2 and later chips)???
зы:
и заодно - почему они не работают в ppc
ззы:
2anonymous - неужели вы не видите, что этот собеседник обычный популистский трепач?
> 2anonymous - неужели вы не видите, что этот собеседник обычный популистский трепач?а мне скучно, и вот в данное конкретное время по техническим причинам делать особо нечего. развлекаюсь.
понятно.
а я вот вначале повёлся на "около-компиляторные" разговоры. потом смотрю - ну полный же 0.
>[оверквотинг удален]
> ...
> + + sse
> : fast floating
> point optimization for PentiumIII+ class chips
> + + sse2
> : faster floating point
> optimization for SSE2 capable chips
> + + ssse3
> : faster floating point optimization
> for SSSE3 capable chips (Intel Core 2 and later chips)А что вам тут нужно объяснить?
действительно! :D
в общем с этого всё и начилось - гцц это может, pcc нет
> действительно! :D
> в общем с этого всё и начилось - гцц это может, pcc нетТьфу, это вы с темы на тему так скачете, оказывается. PCC пока только учится, да.
Да пусть и не приснится никогда. Зачем мне все это нужно? Почему бы
компилятору самому не решать, с какими опциями собирать мои исходники?
Раньше на всяких bcc я говорил -O когда надо быстро собрать, -Os когда
мало памяти, или -Ox когда ее нормально -- что еще надо?Единственными опциями оптимизации должны быть:
- режим оптимизации (нет, -O, -Ox, -Os (теперь для редких случаев))
- целевая архитектура
- -pthread-vetoА дальше пусть сам кумекает -- векторизирует, анролит лупы, инлайнит,
параллелит, элиминирует... на кой черт мне об этом думать? Сравнение
компиляторов сведется к времени компиляции и выполнения тестовых
исходников. Да и вообще непонятно мне восхищение зиллионом опций, из
которых всегда используешь одни и те же 3.
>Да пусть и не приснится никогда. Зачем мне все это нужно? Почему бы компилятору самому не решать, с какими опциями собирать мои исходники?ну наверное потому, что он именно это и делает.
вот только этих опций банально не во всех компиляторах особо и есть :D
а опции -O... - это алиас, который разворачивается в что-то типа:
-O2 turns on all optimization flags specified by -O. It also turns on the following optimization flags:-fthread-jumps
-falign-functions -falign-jumps
-falign-loops -falign-labels
-fcaller-saves
-fcrossjumping
-fcse-follow-jumps -fcse-skip-blocks
-fdelete-null-pointer-checks
-fexpensive-optimizations
-fgcse -fgcse-lm
-finline-small-functions
-findirect-inlining
-fipa-sra
-foptimize-sibling-calls
-fpartial-inlining
-fpeephole2
-fregmove
-freorder-blocks -freorder-functions
-frerun-cse-after-loop
-fsched-interblock -fsched-spec
-fschedule-insns -fschedule-insns2
-fstrict-aliasing -fstrict-overflow
-ftree-switch-conversion
-ftree-pre
-ftree-vrp
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
опять же, раз мы говорим об компиляторах, то наверное и контингет их использующий должен как минимум быть уровнем выше, чем "продвинутый юзер".
>[оверквотинг удален]
> -fsched-spec
> -fschedule-insns
> -fschedule-insns2
> -fstrict-aliasing -fstrict-overflow
> -ftree-switch-conversion
> -ftree-pre
> -ftree-vrp
> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
> опять же, раз мы говорим об компиляторах, то наверное и контингет их
> использующий должен как минимум быть уровнем выше, чем "продвинутый юзер".Вот ты такой весь гентушниук на оптимизации помешанный... Сутки весь кал (world) пересобираете в 6 потоков??!!! Факин щит, покажите мне пальцем продакшн, в котором процентное соотношение cpu time при компиляции с понтами и плюшками хотя бы за год отыграет сутки этого cpu time на компиляции?!. Что мне нужно я соберу так, как нужно, а остальное просто пусть без дебаг символов, и понеслась, некогда тут.
> Что мне нужно я соберу так, как нужно, а остальное просто
> пусть без дебаг символов, и понеслась, некогда тут.«что, солдат, машина не заводится? отставить, времени нет! поехали, потом заведёшь!»
>> Что мне нужно я соберу так, как нужно, а остальное просто
>> пусть без дебаг символов, и понеслась, некогда тут.
> «что, солдат, машина не заводится? отставить, времени нет! поехали, потом заведёшь!»Да как раз машина заведенная. Только вот если не крикрутить к ней свистелок и перделок - будет 90км/ч ехать, а после затраченных суток на пересборку - 91км/ч. Еще вопросы?
есть такие - вот у фольсвагена двигатель миллионник, а у автоваза 75 тысяч.
ещё вопросы?
Да знаю что алиасы и доку читал. И спеки обоих Интела и АМД
изучал в свое время -- асмом увлекался по молодости. Оставил
это дело я где-то в районе П4. Теперь же, оглядываясь назад,
осознаю две вещи:- То, что я узнал, однозначно пошло мне на пользу в общем
плане развития.
- Изучение очередной (или следующей) аппаратной платформы
займет столько же дохрена времени и сил.Зачем я это рассказываю? Мне *придется* заниматься изучением
платформы, чтобы принять решение о включении-выключении тех
или иных опций. Кроме прочего придется прогонять профайлером
готовую прогу, чтобы понять, правильно ли я все понял. Также
придется на разные платформы, коих сейчас туева хуча, писать
различные вариации в Makefile'е. И все лишь для того, чтобы
мои поделия использовали любой камень в полную силу.А программист, который пишет бакенд на конкретный таргет, и
который знает о нем все (или почти все), который собаку съел
на множестве тест-кейсов, и в курсе где какие опции лучше
включать (прям вплоть до отдельных участков кода), что же он
делает? Он просто их экспортирует, чтобы я (!) их
использовал. Маразм, нет?> опять же, раз мы говорим об компиляторах, то наверное и
> контингет их использующий должен как минимум быть уровнем
> выше, чем "продвинутый юзер".В корне несогласен. Относительно познаний в области
кодогенерации, я могу быть уровнем выше, уровнем ниже, могу
вообще хотеть думать только об архитектуре и реализации. От
этого не должно зависеть качество выходного бинарника.
> ошибаются. Бывают случаи, что сторонний софт приходится вообще под -O0 собирать
> принудительно. Потому что иначе у него едет крыша, стоит ему попасть
> в условия, отличающиеся от условий тестов разработчиков.почему же «сторонний»? свой иногда приходится. зато удобно. на любой багрепорт можно ответить: «поменяйте флаги компилятора, версию компилятора, версию ос, соседей, ориентацию. попробуйте разные сочетания. если не помогло — пишите опять». гарантирует, что в ближайшие сто лет вопрошающий больше не появится: будет занят.
>> ошибаются. Бывают случаи, что сторонний софт приходится вообще под -O0 собирать
>> принудительно. Потому что иначе у него едет крыша, стоит ему попасть
>> в условия, отличающиеся от условий тестов разработчиков.
> почему же «сторонний»? свой иногда приходится.Терминология *BSD: под сторонним понимается тот, что не входит в состав базовой системы, а ставится из портов или ещё как.
> зато удобно. на любой багрепорт
> можно ответить: «поменяйте флаги компилятора, версию компилятора, версию ос, соседей,
> ориентацию. попробуйте разные сочетания. если не помогло — пишите опять». гарантирует,
> что в ближайшие сто лет вопрошающий больше не появится: будет занят.Сборка с хитрыми опциями компилятора в погоне за производительностью — на совести собирающего тоже, ибо сам себе злобный пингвин. Если вы на своём «Мустанге» всю электропроводку поменяете, все проблемы будут в первую очередь на вашей совести, а не производителя автомобиля. Что, разумеется, не отменяет того факта, что если у вас произойдёт пожар из-за брака в проводах, то производитель проводов несёт за этот брак ответственность.
Это у некоторых помутнение такое - непонятно из каких причин считают, что разработчики конкурирующих (или просто рядом стоящих) проектов непременно кинутся пилить GPLную поделку, если их некошерное детище зачморить. Вот и пыжатся в силу своих скромных силёнок донести эту эпохальную мысль до широких масс. Бог в помощь.
Тут, наверное, даже не в лицензии дело. Скорее просто в таких случаях находятся люди, которым не в кайф пилить чужие проекты, а хочется сделать что-то своё. Зачем упрекать их в этом непонятно. Вреда такая деятельность всё равно не приносит, скорее наоборот.
> Скорее просто в таких случаях находятся люди, которым не в кайф пилить чужие проекты,
> а хочется сделать что-то своё. Зачем упрекать их в этом непонятно. Вреда такая
> деятельность всё равно не приносит, скорее наоборот.Приносит. Называется "разбазаривание ресурсов".
Чьих ресурсов? В мире СПО каждый сам решает, что ему делать и если кто-то пишет очередной велосипед, то всё что он разбазаривает -- _своё_ время.
> Чьих ресурсов? В мире СПО каждый сам решает, что ему делать и если кто-то
> пишет очередной велосипед, то всё что он разбазаривает -- _своё_ время.я тебе про эволюцию уже писал - вот именно поэтому опенсорс в такой глубокой жопе, что каждый тянет одеяло на себя, и на что-нибудь приличное для пользователей ресурсов не хватает, потому они и выбирают другое. Вот сразу две соседние новости, про Hadoop и Chromeless, как раз про объединение с целью уменьшения этого самого распыления усилий.
А почему они сравнивают с GCC 4.1.3 когда на дворе уже 4.6?
Это нынче модно так?
Он последний под GPLv2
4.2.4 последний
4.1 они взяли по другим причинам, возможно он просто подошел им по бенчмарку )
> Он последний под GPLv2и после этого говорят, что фанатики — это линуксоиды? а для правоверных бздистов, оказывается, софта под GPLv3 не существует, но они при этом не фанатики. чудны дела твои…
> и после этого говорят, что фанатики — это линуксоиды? а для правоверных
> бздистов, оказывается, софта под GPLv3 не существует, но они при этом
> не фанатики. чудны дела твои…А ты почитай GPLv3 повнимательнее и утихни
> А ты почитай GPLv3 повнимательнее и утихничто, не можешь жить без тивоизации? бывает.
>> А ты почитай GPLv3 повнимательнее и утихни
> что, не можешь жить без тивоизации? бывает.Вот после таких ответов в духе "вы все Гитлеры!" и складывается впечатление, что линуховоды - фанатики.
>>> А ты почитай GPLv3 повнимательнее и утихни
>> что, не можешь жить без тивоизации? бывает.
> Вот после таких ответов в духе «вы все Гитлеры!» и складывается впечатление,
> что линуховоды — фанатики.а это всего лишь было отзеркаливание твоего поста. «чем кумушек считать, трудиться…»
Сплюньте озверин, будьте добры. Его оставили, потому что старшие версии в _базовую_ систему не включишь. В портах пожалста, 4.5, 4.6... Кстати, 4.5 основной. 4.6 - это development. )
> Его оставили, потому что старшие версии в _базовую_
> систему не включишь.и это причина сравнивать с устаревшей версией? ну кто бздоидам виноват, что у них GCC поновее в базу не лезет? они бы ещё с GCC 1.0 сравнили. и гордо говорили, что её-то уж точно обогнали.
хотя, впрочем, сторонники бзд в некоторых областях весьма странные: глядишь — последуют моему совету…
> Сборка groff не производится в виду отсутствия поддержки C++ в pcc.Эммм.. На этом в сущности можно и закончить историю PCC. Нахрен оно кому нужно без C++??? Ещё бы as переписали чес слово...
> Эммм.. На этом в сущности можно и закончить историю PCC. Нахрен оно
> кому нужно без C++??? Ещё бы as переписали чес слово…вот как только туда никому не нужный цпп добавят — так и можно будет закапывать фиговину. а пока — вполне годный си-компилятор.
А как распаковать архив? У всех файлов к имени добавлено ",v".
Сравнивали с gcc 4.1, а последующих версиях как будто разработчики сидели на месте. Было много оптимизаций производительности, поэтому реально сабж остает от актуальной версии нехило. Компиляторы сложная штука и к сожалению в наше время в одиночку не напишешь чего-то на уровне лидеров. Из альтернатив gcc только llvm.
Ну и не будем забывать, что С++ он не компилирует, а чтобы написать компилятор к быдлоплюсам, уйдет не один год.
> Ну и не будем забывать, что С++ он не компилирует, а чтобы
> написать компилятор к быдлоплюсам, уйдет не один год.А он и не собирается C++ компилировать. Читайте внимательно, речь идёт сугубо о Си. Так что всё мимо.
т.е. для крестов всё-равно гнутое держать придётся.
угу, точно мимо. прям свалка недокомпиляторов.
> т.е. для крестов всё-равно гнутое держать придётся.
> угу, точно мимо. прям свалка недокомпиляторов.Большая часть системного софта, от PHP до X.org, написана на Си. Плюсы встречаются по большей части в GUI-приложениях. Чтобы поднять полноценный типичный сервер для Web, C++ совсем не нужен.
т.е. своим клиентам так и скажете - извини, но я антигнутый бой, а следовательно прог на С++ вам не видать.
да не! нафиг! :D
> т.е. своим клиентам так и скажете - извини, но я антигнутый бой,
> а следовательно прог на С++ вам не видать.
> да не! нафиг! :DВы, простите, прикидываетесь или действительно инвалид мозговой деятельности? Никто не мешает собирать плюсовые проги хоть GCC, хоть чем угодно. Просто с базовой системой не будет нужно таскать GNU'тый тулчейн, что позволит стать ей заметно изящнее, компактнее и быстрее. Кому будет надо — поставят пакет gcc-* вместе с прочими.
да вы батенька хамите!
ваша система станет изящней примерно настолько же, насколько и ваши коментарии, а именно на 30% тормознее и тупее.
и это ещё в лучшем случае.
> да вы батенька хамите!
> ваша система станет изящней примерно настолько же, насколько и ваши коментарии, а
> именно на 30% тормознее и тупее.
> и это ещё в лучшем случае.Что ж вы такой нервный-то. Вот статистика по сорцам:
$ find /usr/src/gnu/usr.bin/gcc -type f | wc -l
10842
$ find /usr/src/usr.bin/pcc -type f | wc -l
193
Версии не самые новые, но порядок, думаю, понятен. Теперь посмотрим на количество устанавливаемых файлов:$ sudo DESTDIR=/tmp/gccc make install && find /tmp/gccc -type f | wc -l
35
$ sudo DESTDIR=/tmp/pccc make install && find /tmp/pccc -type f | wc -l
6
Ваши возражения?
> $ sudo DESTDIR=/tmp/gccc make install && find /tmp/gccc -type f | wc
> -l
> 35Виноват, здесь должно быть 29, я по ошибке установил сначала в одно и то же дерево.
считать производительность результирующей программы после компиляции в количестве файлов исходников компилятора - это нужно быть ещё тем умником.
> считать производительность результирующей программы после компиляции в количестве файлов
> исходников компилятора - это нужно быть ещё тем умником.Это относилось к словам про изящность и незагромождённость системы, вообще-то.
изящность - это когда из сырцов получается быстрый, оптимальный и маленький кода.
а не когда инфраструктура его создания ничего из себя не представляет.
никто не заставляет в результирующие сборки включать и компиляторы.
> изящность - это когда из сырцов получается быстрый, оптимальный и маленький кода.Это изящность работы компилятора. Вы читать будете, что вам пишут, или только слова выхватывать? Никто не спорит, что компилятор должен генерировать такой код. PCC к этому уверенно движется, и это хорошо. Если он кому-то такой не нужен — пусть их. Эти люди первые им будут пользоваться и кричать «GCC на свалку!» если (или когда?) PCC в свою очередь перегонит GCC по скорости работы конечного кода. Как говорил один далеко не глупый товарищ, «всё течёт, всё изменяется», и только глупец будет пытаться остановить реку своими словами.
> а не когда инфраструктура его создания ничего из себя не представляет.
> никто не заставляет в результирующие сборки включать и компиляторы.Три «ха-ха». Во-первых, по-вашему, программа непременно должна состоять из нескольких тысяч файлов, жрать кучу ресурсов (сравните, сравните, сколько отъедает памяти и времени ЦП в процессе компиляции GCC и сколько — PCC) и требовать для себя особых условий, только тогда вы её зауважаете? Тогда ни в коем случае не пользуйтесь программами cp, mv, mkdir и так далее, они же очень маленькие и компактные...
Во-вторых, а чем тогда систему собирать? Ставить компилятор из портов? Ну смешно же. Устанавливать эти пакеты, с компилятором и пр., может, и не обязательно, а вот поддерживать — естественная необходимость. Для любого проекта.
>Это изящность работы компилятора.да нет. :D
это изящность работы программы... созданоной компилятором.
>>Это изящность работы компилятора.
> да нет. :D
> это изящность работы программы... созданоной компилятором.Изящность работы программы — это уже её логика работы (внутреннее изящество) и интерфейс к этой логике (внешнее). :)
это большой секрет, но есть программы, которые будучи откомпилированы с определенными флагами (читать - возможностями) работают на порядок лучше и быстрее.
для примера - тут вот вдпау всякие появились.
> это большой секрет, но есть программы, которые будучи откомпилированы с определенными флагами
> (читать - возможностями) работают на порядок лучше и быстрее.
> для примера - тут вот вдпау всякие появились.Про VDPAU в смысле оказываемого эффекта не в курсе. Можно поподробнее?
к павлинуху, плс.
мне лень.
а вот то, что и это pcc не может (и даже в планах нет) - факт.
второй апач на плюсах
> второй апач на плюсахОу. Прозевал, сорри.
Похоже круто облажался. Там pure C. почему так считал.. сам не понимаю. :(
тем более что i3/i5/i7 только в ещё не вышедший 4.6 только встроили:
>Support for Intel Core i3/i5/i7 processors is now available through the -march=corei7 and -mtune=corei7 options.не говоря уже про другие оптимизации - http://gcc.gnu.org/gcc-4.6/changes.html - такие как Link-time optimization improvements и Interprocedural optimization improvements
в общем я желаю удачи всем подобным и интересным проектам, но за скоростью развития гнутого мира они явно не успевают.
по существу даже сабж - это реанимация проекта 30 летней давности.
> тем более что i3/i5/i7 только в ещё не вышедший 4.6 только встроили:
>>Support for Intel Core i3/i5/i7 processors is now available through the -march=corei7 and -mtune=corei7 options.
> не говоря уже про другие оптимизации - http://gcc.gnu.org/gcc-4.6/changes.html - такие
> как Link-time optimization improvements и Interprocedural optimization improvements
> в общем я желаю удачи всем подобным и интересным проектам, но за
> скоростью развития гнутого мира они явно не успевают.Если учесть, сколько чистого времени вложено в разработку GCC (берём только общую и сишную части) и сколько — в PCC, то это ещё вопрос. PCC как раз стремительно догоняет GNU C Compiler по качеству.
> по существу даже сабж - это реанимация проекта 30 летней давности.
А вы знаете, сколько лет собственно языку Си? Тс-с-с, это страшная тайна!..
>Если учесть, сколько чистого времени вложено в разработку GCC (берём только общую и сишную части) и сколько — в PCC, то это ещё вопрос. PCC как раз стремительно догоняет GNU C Compiler по качеству.блажен кто верует.
кстати, а с чего вдруг я должен брать "только общую и сишную части"? нет уж! я возьму всё! :D>А вы знаете, сколько лет собственно языку Си? Тс-с-с, это страшная тайна!..
да, только язык Си не приходится реанимировать.
другими словами - сам язык Си мало похож на зомби из сабжа.
>>Если учесть, сколько чистого времени вложено в разработку GCC (берём только общую и сишную части) и сколько — в PCC, то это ещё вопрос. PCC как раз стремительно догоняет GNU C Compiler по качеству.
> блажен кто верует.
> кстати, а с чего вдруг я должен брать "только общую и сишную
> части"? нет уж! я возьму всё! :DС того, что речь в новости шла только о компиляторе Си. Не надо путать универсальные тулчейны со специлизированными, и упрекать одни в том, что они не являются другими, — это не умнее, чем ругать жирафа за то, что он не бегемот.
>>А вы знаете, сколько лет собственно языку Си? Тс-с-с, это страшная тайна!..
> да, только язык Си не приходится реанимировать.
> другими словами - сам язык Си мало похож на зомби из сабжа.Вы этого "зомби" в глаза-то не видели, а уже рассуждаете. Не стыдно?
с каких это пор сабж стал специализированным тулчейном?
и уж точно не я затеял пиписькомерку этого зомби с мэйстримовым тулчейном в мире С/С++, коим и является по праву гцц.
>Вы этого "зомби" в глаза-то не видели, а уже рассуждаете. Не стыдно?тем более я никогда не предполагал априори недостаток знаний в собеседнике.
наоборот, всегда стараюсь предположить в нём более знающего и интересного собеседника.
но получается как всегда. увы.
> с каких это пор сабж стал специализированным тулчейном?Хотите сказать, что «компилятор C» — это не специализация, по сравнению с «Compiler Collection»?
> и уж точно не я затеял пиписькомерку этого зомби с мэйстримовым тулчейном
> в мире С/С++, коим и является по праву гцц.Поправка: в мире *nix. На винде рулит MS-овский компилятор, а на ряде специфических платформ — тоже другие компиляторы (даже при наличии порта GCC). Так что Си-компилятор из состава GCC тоже не мэйнстрим в полном смысле этого слова. Ну да не суть.
>>Вы этого "зомби" в глаза-то не видели, а уже рассуждаете. Не стыдно?
> тем более я никогда не предполагал априори недостаток знаний в собеседнике.
> наоборот, всегда стараюсь предположить в нём более знающего и интересного собеседника.
> но получается как всегда. увы.Недостаток знаний бывает разный. Вы позволили себе утверждать, что проект, начатый тридцать лет назад, будет обязательно плох. После этого вы позволяете себе упрекать других за то, что к вам относятся с такой же степенью корректности, с какой вы позволяете высказываться себе?
сори что отвлёк.
такого толстого троля я давно не встречал.
на виндах? :D
ну да. там кстати компилятор С/С++ уже как то и не в почёте. там всё больше c#.а вот сборки макоси, iphone/ipod/ipad, android, blackberry и куча мелких платформ (вебос к примеру, уже от хп) плюс различные эмбедед девайсы... применение гцц даже сложно подсчитать.
да уж. ваш популизм ограничен в знаниях.
> на виндах? :D
> ну да. там кстати компилятор С/С++ уже как то и не в
> почёте. там всё больше c#.Кстати, если мне не изменяет память, компиляторы C, C++ и C# имеют много общего у MS. Впрочем, не суть.
> а вот сборки макоси, iphone/ipod/ipad, android, blackberry и куча мелких платформ (вебос
> к примеру, уже от хп) плюс различные эмбедед девайсы... применение гцц
> даже сложно подсчитать.Вы опять-таки невнимательно читали, что вам пишут. Про широту применения GCC никто не спорит, но она всё же несколько уже, чем кажется многим.
> да уж. ваш популизм ограничен в знаниях.
Вы так упорно доказываете своё неумение читать, что ставите в тупик: популисты ведь обычно как раз говорят вещи, понятные даже неучу, а вы не понимаете того, что вам говорят...
>Кстати, если мне не изменяет память, компиляторы C, C++ и C# имеют много общего у MS. Впрочем, не суть.посчему же? суть.
а суть - 90% рынка мобильных (и 100% эмбедед) - это гцц.
а всё остальное - это ваша проприетарная сущность.зы:
это кстати просто факт.
>>Кстати, если мне не изменяет память, компиляторы C, C++ и C# имеют много общего у MS. Впрочем, не суть.
> посчему же? суть.
> а суть - 90% рынка мобильных (и 100% эмбедед) - это гцц.Про embedded врать не надо. В одной подобной беседе уже приходил товарищ, наглядно доказавший, что GCC не всегда и везде рулит.
Что же до остального ещё раз напоминаю, что я лишь поправлял, а не полностью опровергал. Цитирую свои слова, выделяя ключевые для понимания сейчас моменты:
«Поправка: в мире *nix. На винде рулит MS-овский компилятор, а на ряде специфических платформ — тоже другие компиляторы (даже при наличии порта GCC). Так что Си-компилятор из состава GCC тоже не мэйнстрим в полном смысле этого слова.»
> а всё остальное - это ваша проприетарная сущность.Смешной вы.
>Про embedded врать не надо. В одной подобной беседе уже приходил товарищ, наглядно доказавший, что GCC не всегда и везде рулит.так не ври.
простого примера будет достаточно. :D>Смешной вы.
ха! меня греет мысль, что я однозначно и объективно умнее. :D
> ха! меня греет мысль, что я однозначно и объективно умнее. :DЯ Вам сочувствую...
> ...и 100% эмбедед - это гцц.Чушь! Вы очень лихо забыли про iar, keil и прочие специализированные компиляторы. А GCC, например, на ARM - это такой середнячок: вроде и работает, но код генерит довольно посредственного качества.
Вот кто-нибудь может без троллинга и со знанием дела объяснить почему *BSD системы не могут включать в поставку GCC под GPLv3?
без тролинга не получится.
потому что именно по этой причине и не включают.ТЕХНИЧЕСКИХ ПРИЧИН НЕТ.
зы:
а вообще, ну спонсор главный в фрибсд - эпл.
а у них весь бизнес построен на анти-гпл3.
>без тролинга не получится.Да, это печально.
>а вообще, ну спонсор главный в фрибсд - эпл.
Во-первых это не так. Я вообще из всех ключевых разработчиков знаю только Robert'а Watson'а, который работал на огрызок по каким-то грантам. Остальные работают в совершенно других компаниях, причём как раз этим компаниям llvm нафиг не нужен, хотя бы из-за того что многие из них выпускают железяки на ARM, MIPS и т. д.
Во-вторых множество ключевых разработчиков заняты портированием FreeBSD на встраиваемые платформы, где лидером остаётся (и ещё долго останется) GCC. И они почему-то не могут переключиться на GCC под GPLv3. Вот мне и интересно почему, в чём юридические причины?
В-третьих, даже если исключить FreeBSD, то есть NetBSD, OpenBSD и другие. И все они зависли на последней версии GCC под GPLv2.
>а у них весь бизнес построен на анти-гпл3.
А весь бизнес производителей телефонов с Linux не построен на "анти-гпл3"? Ведь им ой как нравится возможность тивоизации и патентного троллинга в GPLv2.
>Я вообще из всех ключевых разработчиков знаю только Robert'а Watson'а, который работал на огрызок по каким-то грантам.а я работал cо Стивом Джобсом. и это не стёб.
>о-вторых множество ключевых разработчиков заняты портированием FreeBSD на встраиваемые платформы, где лидером остаётся (и ещё долго останется) GCC.именно. при этом лицензия не важна. чуть более чем полностью.
они даже код открывают только тогда, когда узнают что (!!!) должны.
>В-третьих, даже если исключить FreeBSD, то есть NetBSD, OpenBSD и другие. И все они зависли на последней версии GCC под GPLv2.так вопрос не в том, что будет ли развиваться gcc.
... и тут я играю уже как бздишнег - вопрос в развитии бсд....
>А весь бизнес производителей телефонов с Linux не построен на "анти-гпл3"?нет конечно.
и (к сожалению) им вообще на это наплевать. аппсторе - да.
нужно играть по правилам. вопрос - чьим?
>>А весь бизнес производителей телефонов с Linux не построен на «анти-гпл3»?
> нет конечно.
> и (к сожалению) им вообще на это наплевать.ORLY? как раз GPLv3 там боятся как огня. потому что накроется красивым тазом тивоизация.
но гуаноед торвальдс, конечно, не даст сотворить такую вопиющую несправедливость, и поэтому Linux никогда не будет под GPLv3. для чего, собственно, в исходниках и указана жёстко версия лицензии. и сейчас действительно сменить её несколько трудно — заколебаешься всех опрашивать.
хотя команде GCC вон удалось — всё потому, что код GCC принадлежит FSF. вот так подлая FSF лишает несчастные корпорации свободы тивоизировать.
>ORLY? как раз GPLv3 там боятся как огня. потому что накроется красивым тазом тивоизация.ну дык кто боится, а кто на 4.6 миго делает.
> ну дык кто боится, а кто на 4.6 миго делает.а при чём тут лицензия GCC? у GCC специально оговорено, что лицензия на компилятор не накладывает лицензионных условий на его выхлоп. а вот если ось станет под v3… вот это уже будет беда. точнее даже — катастрофа. но доблестный торвальдс бдит, так что бояться нечего. он нам так и говорит: зачем слушать всяких фанатиков типа Столмана? тивоизация — это добро!
Там одно время в лицензии был какой-то спорный момент, что-то вроде того, что линкуемые файлы должны были быть под GPL3 или как-то так, что нарушило бы возможность поставки системы под своей лицензией (GCC поставлялся как бы отдельно, ранее это не мешало). В окончательной версии GPL3 этот пункт вроде бы убран, но, похоже, юридическая сторона остается запутанной, и от греха подальше не переходят. Получилос так же, как с держателями патентов, не знаешь, какой фортель они выкинут завтра.
