Вариант для распечатки		Пред. тема | След. тема
Форум Программирование под UNIX (Компиляция)
Изначальное сообщение		[ Отслеживать ]

"Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
Сообщение от sidtver (ok), 08-Окт-20, 13:50
Компилятор - это помимо собственно фронтенда/оптимизаций/кодогенератора еще binutils, библиотеки runtime-поддержки и стандартные библиотеки. У gcc - это, например, gas/ld, glibc, libstdc++. По мере своего развития длительное время компилятор clang использовал binutils и библиотеки от компилятора gcc. Но разработчики clang последовательно движутся к полной замкнутости своего проекта. У них есть свой ассемблер (llvm-as), они активно развивают свой линкер, сделали свой аналог libstdc++ с названием libc++ и разрабатывают свой аналог glibc с названием libc. Наличие стандарта C/C++ должно гарантировать компиляцию программ обоими компиляторами, но никак не гарантирует совпадение хедеров из двух разных реализаций библиотек. (Например, errno может быть переменной, а может быть макросом, раскрывающимся в вызов функции и т.д. и т.п.) У двух независимо-разрабатываемых библиотек неизбежно будут библиотеки без бинарной совместимости.   Рассмотрим теперь Unux-дистрибутив, который собран некоторой версией компилятора gcc. В частности, в дистрибутиве будут glibc, libstdc++. Все остальные библиотеки/программы общего назначения будут собраны и слинкованы с glibc/libstdc++. В дистрибутиве также будет компилятор clang. Но компилятор clang при компиляции программ будет линковать их с libc/libc++. Допустим, теперь некоторое приложение X собрано из исходников с помощью clang'а. При этом приложению X нужна библиотека Y, которая есть в дистрибутиве, но собрана с помощью gcc. Тогда X при запуске требует (динамической) линковки с libc/libc++, а Y - glibc/libstdc++. Но гарантий бинарной совместимости libc/libc++ и glibc/libstdc++ нет. Более тонкая ситуация может быть из-за того, что хедеры библиотеки Y будут фактически давать разные варианты, при компиляции разными компиляторами.   Значит, ли это что дистрибутив фактически превращается в объединение двух дистрибутивов, когда все программы/библиотеки должны быть собраны в двух экземплярах: с помощью gcc и с помощью clang'а? P.S. Пару лет назад разработчики gcc поменяли алгоритм манглирования C++ имен. У разработчиков clang на полгода перестал "работать" компилятор. Но тогда у них была зависимость от gcc. Они не были довольны изменениями. С другой стороны компилятор clang создает ассемблер, который в общем случае не может ассемблировать gas. В отсутствии стандартов на манглирование, хедеры стандартных библиотек, механизм EH, процессирование шаблонов, ассемблер и т.п. две системы очень быстро станут несовместимыми.
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
Сообщение от Аноним (-), 08-Окт-20, 15:06
Все держу только на gcc и шланги с llvm выпилены напрочь. Но на сколько я знаю, ссылки на библиотечные функции прописаны у эльфов, у меня нет под рукой апы сделаной шлангом но мне что-то подсказывает что там обычный эльф.
Ответить | Правка | Наверх | Cообщить модератору

	16. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от sidtver (ok), 08-Окт-20, 23:11
	firefox/rust/llvm python/numba/llvm Mesa/llvm ... llvm сам по себе становится частью многих и многих проектов, при этом долгое время clang/llvm использовали glibc/libstdc++, но теперь у них появляется автономность от gcc: libc/libc++ И дело здесь не в elf'е, который по сути стандарт, поэтому соблюдаемый всеми. Дело в бинарной (возможность динамической линковки) совместимости/несовместимости библиотек, о чем в частности и говорится в нижеследующих постах https://www.opennet.dev/openforum/vsluhforumID9/10333.html#9 https://www.opennet.dev/openforum/vsluhforumID9/10333.html#14
	Ответить | Правка | Наверх | Cообщить модератору

2. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
Сообщение от Аноним (2), 08-Окт-20, 16:54
>   В отсутствии стандартов на манглирование, хедеры стандартных библиотек, механизм EH, процессирование шаблонов, ассемблер если abi/api не нарушено, то какая разница какой там листинг ассемблера и хедеры/сорцы? А как обрабатывать шаблоны уж точно прописывается в стандарте. > и т.п. две системы очень быстро станут несовместимыми. когда винду успели пересобрать под icc и mingw?
Ответить | Правка | Наверх | Cообщить модератору

	3. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+1 +/–
	Сообщение от Аноним (-), 08-Окт-20, 17:15
	> когда винду успели пересобрать под icc и mingw? Речь то о том что апа под libc.so собранная gcc уже не будет работать и наоборот. Вообще, вообще, чем дальше тем больше такая вероятность. Взять софт из прошлого например и сразу видим кто умел писать, а кто начитался модных "статеек" и всяких торговцев буквами про "современные и прорывные" в те времена технологии.
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от Аноним (2), 08-Окт-20, 17:44
	> Речь то о том что апа под libc.so собранная gcc уже не будет работать и наоборот. что значит "аппа под libc"? Это типа когда программист решает использовать функцию которая есть только в реализации clang, но нет в стандарте и соответственно нет в других компиляторах, которые следуют стандарту? Если софт только в бинарном виде, то подкладываешь нужную либу, если софт в исходниках, то пересобираешь gcc и он прилинкует свои либы сам или заменяешь нестандартные функции на нормальную реализацию и снова собираешь gcc
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от Аноним (5), 08-Окт-20, 18:01
	> что значит "аппа под libc"? Это типа когда программист решает использовать функцию Я не буду ничего утверждать т.к доподленно мне нафиг не нужно разбираться в этом, т.к не пользуюсь. Вот инетерсно было бы узнать как там гнутый функционал, есть ли, можно ли на него расчитывать в той реализации от шланга ? Хотя, наверное реализуют, иначе вообще зачем он был бы нужен если только вредит.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от Аноним (2), 08-Окт-20, 18:11
	> Вот инетерсно было бы узнать как там гнутый функционал, есть ли, можно ли на него расчитывать в той реализации от шланга на весь наверно нельзя, особенно специфичные , но уже очень много перетащили в clang (ядро вроде как начало собираться даже) > т.к доподленно мне нафиг не нужно разбираться в этом, т.к не пользуюсь. тогда в чем вопрос? Мэнтейнеры в большинстве случаев в состоянии сделать как надо и не будет у вас кучи экземпляров.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от Павел Отредиез (?), 08-Окт-20, 18:16
	>> когда винду успели пересобрать под icc и mingw? > Речь то о том что апа под libc.so собранная gcc уже не > будет работать и наоборот. Вообще, вообще, чем дальше тем больше такая > вероятность. Взять софт из прошлого например и сразу видим кто умел > писать, а кто начитался модных "статеек" и всяких торговцев буквами про > "современные и прорывные" в те времена технологии. Если две разные реализации libc, то их so должны отличаться в названии, приложение слинкуется с нужной. И почему апа под clang libc.so собранная gcc  не будет работать? Что этому мешает? Тот же эльф, хочешь и линкуйся.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	9. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от sidtver (ok), 08-Окт-20, 22:07
	> Если две разные реализации libc, то их so должны отличаться в названии, > приложение слинкуется с нужной. > И почему апа под clang libc.so собранная gcc  не будет работать? > Что этому мешает? Тот же эльф, хочешь и линкуйся. (libY собрана gcc и слинкована с glibc) libY -> glibc (X собрана clang'ом и слинкована с libc, кроме того она использует libY) X -> libc   -> libY Запускаем X, работает динамический загрузчик. Далее X использует f1 из libc, libY использует f1 из glibc. По правилам (текущим) линковки глобальный символ f1 должен быть взят один раз. И X и libY начнут использовать f1 из одной библиотеки. Что касается api и стандарта C/C++. Есть по стандарту errno. Но в одной библиотеке это переменная (кажется так было в старых версиях glibc), а в другой - макрос, раскрывающейся в вызов функции. Соответственно, уже нельзя компилировать с одной C-библиотекой, а запускать с другой. Возможно с C-библиотекой ситуация значительно проще. Но есть еще C++-библиотека.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от Павел Отредиез (?), 08-Окт-20, 22:19
	>[оверквотинг удален] > Запускаем X, работает динамический загрузчик. Далее X использует f1 из libc, libY > использует f1 из glibc. По правилам (текущим) линковки глобальный символ f1 > должен быть взят один раз. И X и libY начнут использовать > f1 из одной библиотеки. > Что касается api и стандарта C/C++. > Есть по стандарту errno. Но в одной библиотеке это переменная (кажется так > было в старых версиях glibc), а в другой - макрос, раскрывающейся > в вызов функции. Соответственно, уже нельзя компилировать с одной C-библиотекой, а > запускать с другой. > Возможно с C-библиотекой ситуация значительно проще. Но есть еще C++-библиотека. Я не говорил, что собирать с одной, а исполнять с другой. Я хотел сказать, что на этапе сборки можно линковаться с чем угодно (конечно используя соответствующие хидеры) , и с тем и выполнять.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от sidtver (ok), 08-Окт-20, 22:28
	> Я не говорил, что собирать с одной, а исполнять с другой. Я > хотел сказать, что на этапе сборки можно линковаться с чем угодно > (конечно используя соответствующие хидеры) , и с тем и выполнять. Рассматриваю такую ситуацию   libY уже установлена в дистрибутиве (это какая-нибудь lipthread, libz или что-нибудь еще), пакет с libY уже кто-собрал и он загружен что-то типа "apt install ...") Затем собирается X, которой требуется libY (и еще cто пятьсот библиотек), но чтобы собрать с помощью clang - это что получается нужно пересобрать эти сто пятьсот библиотек, что не только потребует кучу времени вместо загрузки пакетов, так еще и сама по себе порой нетривиальная задача (много ли разработчиков готовы ковыряться в сборке кучи разных проектов, согласовать версию, продраться через системы сборки, ведь создать дистрибутив насколько понимаю задача очень и очень не простая)? P.S. Иногда приходиться и ковыряться, но именно что иногда. Речь про то, что как штатное решение это не годится.
	Ответить | Правка | Наверх | Cообщить модератору

8. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
Сообщение от Аноним (8), 08-Окт-20, 19:05
У меня штук 20 разных компиляторов с разными либами стоит, гента. Можно любой системны пакет собрать произвольным системным компилятором любой версии, binutils правда придётся вручную переключать (зачем использовать не последнюю версию?), переключение шланг/гцц вообще без проблем переменной окружения. Проблем не замечал, но я массово и не собираю шлангом -- он всегда хуже при ближайшем рассмотрении (что-то простое он может соптимизировать лучше). Или собрать какой-нибудь пакет и все зависимости с другой libc или вообще для другой архитектуры. В частности, собираю софт для венды, когда я проверял, он потом работал в 7, 8 и 10 на системной libc (без cygwin).
Ответить | Правка | Наверх | Cообщить модератору

	10. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от sidtver (ok), 08-Окт-20, 22:14
	> binutils > правда придётся вручную переключать   Если правильно понимаю, то фактически ручное переключение означает, что есть несколько (небольших) кусочков дистрибутива, т.е. библиотеки, собранные разными компиляторными системами. И ручное переключение и требуется для того, чтобы библиотеки при запуске собирались из одного кусочка. Но обычное штатное использование не особо подразумевает ручное управление.   Вот и получается нужна два экземпляра дистрибутива, один собран gcc, другой - clang'ом, и при запуске приложения выбирается один из комплектов в "автоматическом" режиме?
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от Аноним (8), 08-Окт-20, 22:22
	Есть binutils-config, который управляет симлинками на используемую системную версию. Её можно переключать, также как и компилятор по-умолчанию (gcc-config). Но компилятор и линкер можно задать переменными окружения вроде CC и LD.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от Аноним (8), 08-Окт-20, 22:25
	Ещё можно выставить вот эти, но вроде это излишне, и можно спокойно использовать гнутые AR="llvm-ar" NM="llvm-nm" RANLIB="llvm-ranlib"
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Clang vs Gcc: две компиляторных системы в одном дистрибутиве"	+/–
	Сообщение от sidtver (ok), 08-Окт-20, 22:40
	> Есть binutils-config, который управляет симлинками на используемую системную версию. > Её можно переключать, также как и компилятор по-умолчанию (gcc-config). Но компилятор > и линкер можно задать переменными окружения вроде CC и LD. Чтобы не дублировать, просто сошлюсь на посты #9 и #14, приведенные чуть выше https://www.opennet.dev/openforum/vsluhforumID9/10333.html#9 https://www.opennet.dev/openforum/vsluhforumID9/10333.html#14 На мой взгляд binutils-config - это про удобство что-то собрать одним компилятором и запустить потом все, собранное одним компилятором. Но исходный вопрос не про это.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема