The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Clang vs Gcc: две компиляторных системы в одном дистрибутиве"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Программирование под 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: две компиляторных системы в одном дистрибутиве"  +/
Сообщение от Павел Отредиезemail (?), 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: две компиляторных системы в одном дистрибутиве"  +/
Сообщение от Павел Отредиезemail (?), 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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру