https://opennet.me/openforum/vsluhforumID9/10333.html Компилятор - это помимо собственно фронтенда/оптимизаций/кодогенератора еще binutils, библиотеки runtime-поддержки и стандартные библиотеки. У gcc - это, например, gas/ld, glibc, libstdc++. По мере своего развития длительное время компилятор clang использовал binutils и библиотеки от компилятора gcc. Но разработчики clang последовательно движутся к полной замкнутости своего проекта. У них есть свой ассемблер (llvm-as), они активно развивают свой линкер, сделали свой аналог libstdc++ с названием libc++ и разрабатывают свой аналог glibc с названием libc. Наличие стандарта C/C++ должно гарантировать компиляцию программ обоими компиляторами, но никак не гарантирует совпадение хедеров из двух разных реализаций библиотек. (Например, errno может быть переменной, а может быть макросом, раскрывающимся в вызов функции и т.д. и т.п.) У двух независимо-разрабатываемых библиотек неизбежно будут библиотеки без бинарной совместимости.<br> Рассмотрим теперь Unux-дистрибутив, который собран некоторой версией компилятора gcc. https://opennet.me/openforum/vsluhforumID9/10333.html#16 Thu, 08 Oct 2020 20:11:37 GMT firefox/rust/llvm<br>python/numba/llvm<br>Mesa/llvm<br>...<br><br>llvm сам по себе становится частью многих и многих проектов, при этом долгое время clang/llvm использовали glibc/libstdc++, но теперь у них появляется автономность от gcc: libc/libc++<br><br>И дело здесь не в elf'е, который по сути стандарт, поэтому соблюдаемый всеми. Дело в бинарной (возможность динамической линковки) совместимости/несовместимости библиотек, о чем в частности и говорится в нижеследующих постах<br>https://www.opennet.ru/openforum/vsluhforumID9/10333.html#9<br>https://www.opennet.ru/openforum/vsluhforumID9/10333.html#14<br> https://opennet.me/openforum/vsluhforumID9/10333.html#15 Thu, 08 Oct 2020 19:40:17 GMT &gt; Есть binutils-config, который управляет симлинками на используемую системную версию. <br>&gt; Её можно переключать, также как и компилятор по-умолчанию (gcc-config). Но компилятор <br>&gt; и линкер можно задать переменными окружения вроде CC и LD.<br><br>Чтобы не дублировать, просто сошлюсь на посты #9 и #14, приведенные чуть выше<br>https://www.opennet.ru/openforum/vsluhforumID9/10333.html#9<br>https://www.opennet.ru/openforum/vsluhforumID9/10333.html#14<br><br>На мой взгляд binutils-config - это про удобство что-то собрать одним компилятором и запустить потом все, собранное одним компилятором. Но исходный вопрос не про это.<br><br> https://opennet.me/openforum/vsluhforumID9/10333.html#14 Thu, 08 Oct 2020 19:28:52 GMT &gt; Я не говорил, что собирать с одной, а исполнять с другой. Я <br>&gt; хотел сказать, что на этапе сборки можно линковаться с чем угодно <br>&gt; (конечно используя соответствующие хидеры) , и с тем и выполнять.<br><br>Рассматриваю такую ситуацию<br> libY уже установлена в дистрибутиве (это какая-нибудь lipthread, libz или что-нибудь еще), пакет с libY уже кто-собрал и он загружен что-то типа "apt install ...")<br><br>Затем собирается X, которой требуется libY (и еще cто пятьсот библиотек), но чтобы собрать с помощью clang - это что получается нужно пересобрать эти сто пятьсот библиотек, что не только потребует кучу времени вместо загрузки пакетов, так еще и сама по себе порой нетривиальная задача (много ли разработчиков готовы ковыряться в сборке кучи разных проектов, согласовать версию, продраться через системы сборки, ведь создать дистрибутив насколько понимаю задача очень и очень не простая)?<br><br>P.S. Иногда приходиться и ковыряться, но именно что иногда. Речь про то, что как штатное решение это не годится.<br><br><br> https://opennet.me/openforum/vsluhforumID9/10333.html#13 Thu, 08 Oct 2020 19:25:20 GMT Ещё можно выставить вот эти, но вроде это излишне, и можно спокойно использовать гнутые<br><br>AR="llvm-ar"<br>NM="llvm-nm"<br>RANLIB="llvm-ranlib"<br> https://opennet.me/openforum/vsluhforumID9/10333.html#12 Thu, 08 Oct 2020 19:22:59 GMT Есть binutils-config, который управляет симлинками на используемую системную версию. Её можно переключать, также как и компилятор по-умолчанию (gcc-config). Но компилятор и линкер можно задать переменными окружения вроде CC и LD.<br> https://opennet.me/openforum/vsluhforumID9/10333.html#11 Thu, 08 Oct 2020 19:19:41 GMT &gt;[оверквотинг удален]<br>&gt; Запускаем X, работает динамический загрузчик. Далее X использует f1 из libc, libY <br>&gt; использует f1 из glibc. По правилам (текущим) линковки глобальный символ f1 <br>&gt; должен быть взят один раз. И X и libY начнут использовать <br>&gt; f1 из одной библиотеки.<br>&gt; Что касается api и стандарта C/C++.<br>&gt; Есть по стандарту errno. Но в одной библиотеке это переменная (кажется так <br>&gt; было в старых версиях glibc), а в другой - макрос, раскрывающейся <br>&gt; в вызов функции. Соответственно, уже нельзя компилировать с одной C-библиотекой, а <br>&gt; запускать с другой.<br>&gt; Возможно с C-библиотекой ситуация значительно проще. Но есть еще C++-библиотека.<br><br>Я не говорил, что собирать с одной, а исполнять с другой. Я хотел сказать, что на этапе сборки можно линковаться с чем угодно (конечно используя соответствующие хидеры) , и с тем и выполнять. <br><br><br><br> https://opennet.me/openforum/vsluhforumID9/10333.html#10 Thu, 08 Oct 2020 19:14:00 GMT &gt; binutils <br>&gt; правда придётся вручную переключать<br><br> Если правильно понимаю, то фактически ручное переключение означает, что есть несколько (небольших) кусочков дистрибутива, т.е. библиотеки, собранные разными компиляторными системами. И ручное переключение и требуется для того, чтобы библиотеки при запуске собирались из одного кусочка. Но обычное штатное использование не особо подразумевает ручное управление.<br> Вот и получается нужна два экземпляра дистрибутива, один собран gcc, другой - clang'ом, и при запуске приложения выбирается один из комплектов в "автоматическом" режиме?<br> https://opennet.me/openforum/vsluhforumID9/10333.html#9 Thu, 08 Oct 2020 19:07:58 GMT &gt; Если две разные реализации libc, то их so должны отличаться в названии, <br>&gt; приложение слинкуется с нужной.<br>&gt; И почему апа под clang libc.so собранная gcc не будет работать? <br>&gt; Что этому мешает? Тот же эльф, хочешь и линкуйся.<br><br>(libY собрана gcc и слинкована с glibc)<br>libY -&gt; glibc<br><br>(X собрана clang'ом и слинкована с libc, кроме того она использует libY)<br>X -&gt; libc<br> -&gt; libY<br><br>Запускаем X, работает динамический загрузчик. Далее X использует f1 из libc, libY использует f1 из glibc. По правилам (текущим) линковки глобальный символ f1 должен быть взят один раз. И X и libY начнут использовать f1 из одной библиотеки. <br><br>Что касается api и стандарта C/C++.<br>Есть по стандарту errno. Но в одной библиотеке это переменная (кажется так было в старых версиях glibc), а в другой - макрос, раскрывающейся в вызов функции. Соответственно, уже нельзя компилировать с одной C-библиотекой, а запускать с другой.<br><br>Возможно с C-библиотекой ситуация значительно проще. Но есть еще C++-библиотека.<br><br> <br><br><br> https://opennet.me/openforum/vsluhforumID9/10333.html#8 Thu, 08 Oct 2020 16:05:59 GMT У меня штук 20 разных компиляторов с разными либами стоит, гента. Можно любой системны пакет собрать произвольным системным компилятором любой версии, binutils правда придётся вручную переключать (зачем использовать не последнюю версию?), переключение шланг/гцц вообще без проблем переменной окружения. Проблем не замечал, но я массово и не собираю шлангом -- он всегда хуже при ближайшем рассмотрении (что-то простое он может соптимизировать лучше). Или собрать какой-нибудь пакет и все зависимости с другой libc или вообще для другой архитектуры. В частности, собираю софт для венды, когда я проверял, он потом работал в 7, 8 и 10 на системной libc (без cygwin).<br>