Clang vs Gcc: две компиляторных системы в одном дистрибутиве

Компилятор - это помимо собственно фронтенда/оптимизаций/кодогенератора еще binutils, библиотеки runtime-поддержки и стандартные библиотеки. У gcc - это, например, gas/ld, glibc, libstdc++. По мере своего развития длительное время компилятор clang использовал binutils и библиотеки от компилятора gcc. Но разработчики clang последовательно движутся к полной замкнутости своего проекта. У них есть свой ассемблер (llvm-as), они активно развивают свой линкер, сделали свой аналог libstdc++ с названием libc++ и разрабатывают свой аналог glibc с названием libc. Наличие стандарта C/C++ должно гарантировать компиляцию программ обоими компиляторами, но никак не гарантирует совпадение хедеров из двух разных реализаций библиотек. (Например, errno может быть переменной, а может быть макросом, раскрывающимся в вызов функции и т.д. и т.п.) У двух независимо-разрабатываемых библиотек неизбежно будут библиотеки без бинарной совместимости.
Рассмотрим теперь версию linux-дистрибутива, который собран некоторой версией компилятора 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 будут фактически давать разные варианты, при компиляции разными компиляторами.

Значит, ли это что linux-дистрибутив фактически превращается в объединение двух дистрибутивов, когда все программы/библиотеки должны быть собраны в двух экземплярах: с помощью gcc и с помощью clang'а?

P.S. Пару лет назад разработчики gcc поменяли алгоритм манглирования C++ имен. У разработчиков clang на полгода перестал "работать" компилятор. Но тогда у них была зависимость от gcc. Они не были довольны изменениями. С другой стороны компилятор clang создает ассемблер, который в общем случае не может ассемблировать gas. В отсутствии стандартов на манглирование, хедеры стандартных библиотек, механизм EH, процессирование шаблонов, ассемблер и т.п. две системы очень быстро станут несовместимыми.

paul_st, :) В одном дистрибутиве вы можете установить и использовать хоть все компилляторы и интерпретаторы мира.
Просто будет одна большая помойка в файловой системе.

Зачем всю тему сводить к моим желаниям/нежеланиям?
> вы можете установить и использовать
Если установка ведется стандартными средствами, то
> помойку
по сути спроектировали разработчики дистрибутивов?

У меня вопрос про принципиальное устройство дистрибутивов в ближайшем будущем, если/когда разработчики clang перейдут целиком и полностью на libc/libc++. Количество проектов, использующих clang/llvm растет. Например, rust использует в качестве бэкенда llvm, значит, rust использует механизм EH (exception handling) из llvm, значит это (скоро будет) libc++. Часть браузера firefox написана на rust. И вот уже часть firefox'a скомпилирована и слинкована с libc++. Вам не нравится firefox? Но это не единственный значимый проект использующий llvm.

Вот и получается. Будет один дистрибутив полностью собранный gcc, и другой - полностью собранный clang? Или в рамках одного дистрибутива будет штатный способ от самих разработчиков дистрибутивов одновременно использования проектов/библиотек, собранных gcc или clang?

"paul_st" написал:

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

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

caspar написал:

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

Это "штатное" решение или приложение само должно озаботиться наличием конфигов?

Кроме того

(libY собрана gcc и слинкована с glibc)
libY -> glibc

(X собрана clang'ом и слинкована с libc, кроме того она использует libY)
X -> libc
-> libY

Запускаем X, работает динамический загрузчик. Далее X использует f1 из libc, libY использует f1 из glibc. По правилам (текущим) линковки глобальный символ f1 должен быть взят один раз. И X и libY начнут использовать f1 из одной библиотеки.

Вот и получается нужна два экземпляра дистрибутива, один собран gcc, другой - clang'ом, и при запуске приложения выбирается один из комплектов в "автоматическом" режиме?

"paul_st" написал:

Вот и получается нужна два экземпляра дистрибутива, один собран gcc, другой - clang'ом, и при запуске приложения выбирается один из комплектов в "автоматическом" режиме?

это ты приводишь няма-фантазию сферического коня в яблоках вакууме.
В реальности же шланг ещё эпохально далёк от того, чтобы полностью "опакетить" дистрибутив целиком. Я полный нуб в ссьях и прочих плюсах, я тот крестьянин который "хрен растит на всю страну" - я собираю свой велосипед руками и буквально в упор вижу нутро что гесесе что шланга, что прочих растов с рептилиями и бобовыми, так вот скажу тебе "от сохи" - этого ещё долго не будет(если вообще когда-то будет).
Причин тут легион, но если попытаться их просто структурировать то имеем несколько неразрешимых на сегодня противоречий в человечестве(да-да, это не инженерная проблема, а философско-социальная, уходящая корнями в истории боёв на поле Курукшетра и крестовых походов за святым граалем).
Первое, но не главное ты уже описал более-менее. Стандарты. Но стандарты просто языка это ещё пол-беды, добавь к ним еще единообразные, не противоречиво описанные и документированные стандарты сборки. А теперь на секунду представь всего одну команду смузихлёбов не до конца гендерно определившихся, которые посчитали "а и так сойдёт" и создавших мезон... но ведь в мире же не бывает всё просто, им на встречу вышла команда стареющих хипстерюг (в стадии активной деменции) с темой "а перепишем ка перл с нуля, чтоб с пеламутромыми пуговками..". А над этой эпичной схваткой, как орлы Гендальфа, гордо и независимо парят гендерно-нейтральные но радикально идейные и непримиримые(практически как моджахеды, только круче) дизайнеры гнома и пилители вайланда... Простую расходную пехоту, пишущую что-то типа zstd4 или librsvg, или ffmpeg, или opencv, или тот же керберосс, которым нужно стратегически определяться в своей идентичности и приверженности той или иной команде.
А где-то, в высоких горах Асгарда, тайными тропами, под снежными зарядами и горными обвалими, героически прячут тело жирное гордо пробираются, мечтая вырвать сердце у ненавистной венды и таки заполучить мировое господство светлые эльфы пейсатели кутей, впрочем не брезгующие прибегать к помощи рептилий из глубоких недр Тартара, имеющих на своих знамёнах изображение древнего Змия Зелёного, причем, Этот то самый Змий, совершенно по змеиному готов обслуживать каждую команду, щедро снабжая стороны и оружием и провиантом, но таки оставляющий за собой право последнего решающего слова - "как я скажу, так и будет"... про орков, любителей пыхпыха я уж вообще помолчу, тем без разницы, на какого хозяина работать - да хоть на трёх сразу! А спятивший "волшебник" из красной башни - Потеринг? Мечтающий засунуть свои кривые руки в каждое вот-это-всё? А любители паранойи из ПАМа-СЕлюков и АПарморов? Их то куда девать?
И вот этот вот весь зоопарк нужно как-то контролировать в рамках единообразно работающей системы(ака дистрибутив), но ведь и это не вся соль, главное то тут как раз не война остро-конечников с тупо-конечниками, а простой деревенский Мага, или Петро, или МарьИванна из Кукуевки, которым глубоко плевать на всё вот это, им нужна одна большая кнопка во весь экран "детка! заделай ка мне хорошо", да такая, чтоб работала всегда, без глюков, сбоев и потери инфы, и как она будет называться - Федора или Петровна, это по большому счёту никого не волнует. Именно по этим вот причинам майкрософт вот уже двадцать лет таскает с собой костыли ещё от вынь98 и не особо торопится их закапывать.
Так что взлетит ли шланг или нет - дело только в бабосах, по другому такие вещи просто не взлетают.

Да clang не торт. Собирал с ним gentoo, но дрова nvidia никак вставать не хотели на такую систему у меня. :( В тоже время BSD с ним очень дружит насколько я знаю. *CRAZY*

shtoom, :) BSD - это целая обкуренная вселенная, где глюки давно стали привидениями.

Wolfenberg, Похоже на то. ;) На самом деле там проблема в CFLAGS. GCC теперь не знает об оптимизации -march=native, a clang не знает о -march=haswell к примеру и если nvidia-drivers указать конкретный CFLAGS, а так же прописать, что он собирается GCC, то установить можно. *DRINK*
Добавлено: 14.10.2020 15:36:04

Оставлю на память тут.

cat /etc/portage/make.conf

cat /etc/portage/package.env

cat /etc/portage/env/gcc

cat /etc/portage/package.use/llvm

"shtoom" написал:

GCC теперь не знает об оптимизации -march=native, a clang не знает о -march=haswell к примеру

А эти два компиллятора никогда не знали о существовании друг друга.
Это равносильно потугам подружить Oracle DB с Fox Pro...

"paul_st" написал:

"помойку" по сути спроектировали разработчики дистрибутивов?

Из двух зол выбирают меньшее... А из "помойки" как правило только нужное либо лучшее...
Эти правила работают как на Бомжах(и не только) роющихся в реальной мусорке/помойке, так и на пользователях операционных систем.

Есть исключение, но это больные люди - как люди с Мусорки превращавшие свой дом в хламьевник, заполняя его до потолка не нужным хламом, так и люди которые не могут навести порядок в операционной системе ставящие по 3-4 антивируса, яндекс/амиго браузеры и прочий софт который навязывается при установке, все доступные наборы программ и т.д. которые никогда не будут использоваться.

Поэтому никто не будет в здравом уме ставить все пакеты входящие в дистрибутив.
Вы ставите только то, что Вам нужно для работы. Остальное доставляется по мере необходимости.

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

Но с опытом приходит наработанный алгоритм, когда за несколько команд в командной строке Вы сможете разворачивать все что Вам необходимо для создания полноценного рабочего места.