The OpenNET Project / Index page

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




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! sidtver, 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, процессирование шаблонов, ассемблер и т.п. две системы очень быстро станут несовместимыми.

  • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! Аноним, 15:06 , 08-Окт-20 (1)
    Все держу только на gcc и шланги с llvm выпилены напрочь. Но на сколько я знаю, ссылки на библиотечные функции прописаны у эльфов, у меня нет под рукой апы сделаной шлангом но мне что-то подсказывает что там обычный эльф.
  • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! Аноним, 16:54 , 08-Окт-20 (2)
    >   В отсутствии стандартов на манглирование, хедеры стандартных библиотек, механизм EH, процессирование шаблонов, ассемблер

    если abi/api не нарушено, то какая разница какой там листинг ассемблера и хедеры/сорцы? А как обрабатывать шаблоны уж точно прописывается в стандарте.

    > и т.п. две системы очень быстро станут несовместимыми.

    когда винду успели пересобрать под icc и mingw?

    • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! Аноним, 17:15 , 08-Окт-20 (3) +1

      > когда винду успели пересобрать под icc и mingw?

      Речь то о том что апа под libc.so собранная gcc уже не будет работать и наоборот. Вообще, вообще, чем дальше тем больше такая вероятность. Взять софт из прошлого например и сразу видим кто умел писать, а кто начитался модных "статеек" и всяких торговцев буквами про "современные и прорывные" в те времена технологии.

      • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! Аноним, 17:44 , 08-Окт-20 (4)
        > Речь то о том что апа под libc.so собранная gcc уже не будет работать и наоборот.

        что значит "аппа под libc"? Это типа когда программист решает использовать функцию которая есть только в реализации clang, но нет в стандарте и соответственно нет в других компиляторах, которые следуют стандарту?

        Если софт только в бинарном виде, то подкладываешь нужную либу, если софт в исходниках, то пересобираешь gcc и он прилинкует свои либы сам или заменяешь нестандартные функции на нормальную реализацию и снова собираешь gcc

        • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! Аноним, 18:01 , 08-Окт-20 (5)

          > что значит "аппа под libc"? Это типа когда программист решает использовать функцию

          Я не буду ничего утверждать т.к доподленно мне нафиг не нужно разбираться в этом, т.к не пользуюсь. Вот инетерсно было бы узнать как там гнутый функционал, есть ли, можно ли на него расчитывать в той реализации от шланга ? Хотя, наверное реализуют, иначе вообще зачем он был бы нужен если только вредит.

          • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! Аноним, 18:11 , 08-Окт-20 (6)
            > Вот инетерсно было бы узнать как там гнутый функционал, есть ли, можно ли на него расчитывать в той реализации от шланга

            на весь наверно нельзя, особенно специфичные , но уже очень много перетащили в clang (ядро вроде как начало собираться даже)

            > т.к доподленно мне нафиг не нужно разбираться в этом, т.к не пользуюсь.

            тогда в чем вопрос? Мэнтейнеры в большинстве случаев в состоянии сделать как надо и не будет у вас кучи экземпляров.

      • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! Павел Отредиез, 18:16 , 08-Окт-20 (7)
        >> когда винду успели пересобрать под icc и mingw?
        > Речь то о том что апа под libc.so собранная gcc уже не
        > будет работать и наоборот. Вообще, вообще, чем дальше тем больше такая
        > вероятность. Взять софт из прошлого например и сразу видим кто умел
        > писать, а кто начитался модных "статеек" и всяких торговцев буквами про
        > "современные и прорывные" в те времена технологии.

        Если две разные реализации libc, то их so должны отличаться в названии, приложение слинкуется с нужной.
        И почему апа под clang libc.so собранная gcc  не будет работать? Что этому мешает? Тот же эльф, хочешь и линкуйся.

        • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! sidtver, 22:07 , 08-Окт-20 (9)
          > Если две разные реализации 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++-библиотека.


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

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

            • Clang vs Gcc: две компиляторных системы в одном дистрибутиве, !*! sidtver, 22:28 , 08-Окт-20 (14)
              > Я не говорил, что собирать с одной, а исполнять с другой. Я
              > хотел сказать, что на этапе сборки можно линковаться с чем угодно
              > (конечно используя соответствующие хидеры) , и с тем и выполнять.

              Рассматриваю такую ситуацию
                libY уже установлена в дистрибутиве (это какая-нибудь lipthread, libz или что-нибудь еще), пакет с libY уже кто-собрал и он загружен что-то типа "apt install ...")

              Затем собирается X, которой требуется libY (и еще cто пятьсот библиотек), но чтобы собрать с помощью clang - это что получается нужно пересобрать эти сто пятьсот библиотек, что не только потребует кучу времени вместо загрузки пакетов, так еще и сама по себе порой нетривиальная задача (много ли разработчиков готовы ковыряться в сборке кучи разных проектов, согласовать версию, продраться через системы сборки, ведь создать дистрибутив насколько понимаю задача очень и очень не простая)?

              P.S. Иногда приходиться и ковыряться, но именно что иногда. Речь про то, что как штатное решение это не годится.


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



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

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