The OpenNET Project / Index page

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

Релиз набора компиляторов LLVM 7.0

19.09.2018 22:35

После шести месяцев разработки сформирован релиз проекта LLVM 7.0 (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.

Из новых возможностей LLVM 7.0 отмечается возможность мультиверсионирования функций в Clang, улучшение поддержки предкомпилированных заголовков PCH в clang-cl, предварительная поддержка формата отладочной информации DWARF v5, начальная поддержка NVIDIA PTX для ускорения вычислений в OpenMP 4.5, поддержка OpenCL C++, поддержка MSan, X-Ray и libFuzzer во FreeBSD, начальная поддержка UBSan, X-Ray и libFuzzer в OpenBSD, реализация проверки неявных преобразований в UBSan, решение многих проблем с совместимостью в компоновщике lld, новые инструменты llvm-exegesis, llvm-mca и diagtool, дополнительные оптимизации и средства диагностики.

Улучшения в Clang 7.0:

  • В UBSan (Undefined Behavior Sanitizer), детекторе неопределенного поведения, добавлен режим проверки неявных преобразований ("-fsanitize=implicit-conversion"), который пока ограничен выявлением неявных усечений целых значений;
  • Доступна экспериментальная поддержка отладочной информации в формате DWARF v5 (включается "-gdwarf-5 -O0"), в том числе новых таблиц ".debug_names";
  • Добавлена поддержка мультиверсионирования функций, техники для включения в результирующий исполняемый файл нескольких реализаций функции, использующих разные специализированные расширенные наборы инструкций. Разные варианты функций определяются при помощи атрибута "target", реализация которого совместима с GCC. Например, выражение '__attribute__((target("arch=atom")))' позволяет определить отдельный вариант функции, который будет использован на процессорах Atom. Мультиверсионирование пока доступно только для исполняемых файлов ELF и для архитектур x86 и x86-64;
  • В clang-cl, альтернативном интерфейсе командной строки, обеспечивающем совместимость на уровне опций с компилятором cl.exe из состава Visual Studio, значительно улучшена поддержка предкомпилированных заголовочных файлов в формате PCH. При использовании файла PCH теперь не генерируются inline-методы, которые уже присутствуют в объектах, собранных вместе с PCH-файлом, что позволяет ускорить сборку с применением PCH примерно на 30%. Также добавлена возможность использования предкомпилированных заголовков для заголовочного файла stdafx.h, предлагаемого по умолчанию в Visual Studio;
  • Исполняемый файл компилятора и библиотеки теперь включают только номер значительной версии, т.е. вместо исполняемого файла clang-7.0 предлагается clang-7;
  • В состав включена вспомогательная утилита diagtool для манипуляции со средствами диагностики clang, например, для определения иерархии предупреждений и оценки какие из элементов этой иерархии включены по умолчанию или применяются для конкретного вызова компилятора;
  • Добавлены новые диагностические опции "-Wc++98-compat-extra-semi", "-Wextra-semi", "-Wself-assign" и "-Wself-assign-field";
  • Добавлены новые флаги компилятора: "-fstrict-float-cast-overflow" и "-fno-strict-float-cast-overflow" для управления поведением при преобразовании вещественного значения в целое; "-fforce-emit-vtables" и "-fno-force-emit-vtables" для включения/выключения обязательного inline-развёртывания функций с использованием vtables; "-mcrc" и "-mno-crc" для управления применением MIPS инструкций CRC (Cyclic Redundancy Check); "-mvirt" и "-mno-virt" для управления применением MIPS-расширений виртуализации; "-mginv" и "-mno-ginv" для для управления применением MIPS инструкций GINV (Global INValidate);
  • Расширены возможности, связанные с поддержкой OpenCL, OpenMP и CUDA. В том числе в OpenCL реализовано расширение cles_khr_int64 и добавлена опция "-cl-uniform-work-group-size" для применения дополнительной оптимизации на этапе компиляции. Началась реализация поддержки OpenCL C++, добавлены флаги "-std/-cl-std=c++" и поддержка ключевых слов. Добавлена возможность использования OpenMP 4.5 для ускорения вычислений за счёт выноса операций (offloading) на чипы с поддержкой псевдоязыка NVIDIA PTX (Parallel Thread Execution);
  • В статический анализатор добавлен новый режим проверки MmapWriteExec для определения попыток маппинга страниц памяти одновременно для записи и исполнения;
  • В linter clang-tidy добавлена большая порция новых проверок. Добавлена возможность сохранения результатов в формате JSON для интеграции с внешними системами анализа кода. В состав включены новые модули abseil (для проверки библиотеки Abseil), portability и zircon (для проверки ядра ОС Fuchsia).

Основные новшества LLVM 7.0:

  • В компоновщике LLD обеспечена готовая для повсеместного использования поддержка форматов ELF (Unix), COFF (Windows) и MinGW. Например, lld/ELF пригоден для компоновки всех компонентов FreeBSD для архитектур AMD64 и ARMv7, и будет применяться в качестве компоновщика по умолчанию в следующей версии FreeBSD. lld/COFF уже применяется для формирования официальных сборок Chrome и Firefox. Форматы Mach-O (macOS) и WebAssembly пока остаются в категории экспериментальных;
  • В UBsan, инструментарии X-Ray и библиотеке libFuzzer реализована начальная поддержка OpenBSD (x86 и x86_64);
  • В MSan (x86_64), инструментарии X-Ray и libFuzzer (x86 и x86_64) обеспечена поддержка FreeBSD;
  • Из установочного пакета для Windows исключены компоненты для интеграции с Visual Studio, которые вынесены в отдельное расширение "LLVM Compiler Toolchain Visual Studio", размещённое в каталоге приложений Visual Studio Marketplace;
  • Добавлена новая утилита llvm-exegesis для автоматического измерения производительности выполнения машинных инструкций;
  • Добавлена новая утилита llvm-mca для прогнозирования производительности машинного кода для указанного CPU;
  • Проведена оптимизация преобразования вещественных чисел в значения других типов;
  • Реализована возможность профилирования кода, оптимизированного при помощи JIT, при помощи утилиты perf;
  • Внесены многочисленные улучшения в бэкенды для архитектур X86, AArch64, ARM, SystemZ, Hexagon, MIPS и PowerPC.


  1. Главная ссылка к новости (http://lists.llvm.org/pipermai...)
  2. OpenNews: Релиз набора компиляторов LLVM 6.0
  3. OpenNews: В знак несогласия с новым кодексом поведения LLVM покинул один из ведущих разработчиков
  4. OpenNews: Открыт код C++ компилятора Zapcc
  5. OpenNews: Релиз набора компиляторов GCC 8
  6. OpenNews: Создатель LLVM и Swift уходит из компании Apple
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49299-llvm
Ключевые слова: llvm, clang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, nc (ok), 23:38, 19/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Интересно, а есть у них какие нибудь интересные языковые расширения наподобие https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html ?
     
     
  • 2.3, SashaMelnikov (ok), 00:13, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    подойдет?  http://clang.llvm.org/docs/LanguageExtensions.html

    но у llvm есть более полезные фичи: например модули для C взамен #include
    http://clang.llvm.org/docs/Modules.html

    но лучше просто сходите сами и походите по ссылкам (если еще не)
    http://clang.llvm.org/docs/index.html

     
     
  • 3.11, Аноним (11), 00:36, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >есть более полезные фичи: например модули для C взамен #include

    Горбатого только могила исправит.

     
     
  • 4.14, Аноним (14), 00:52, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ?
     
     
  • 5.30, A.Stahl (ok), 07:23, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это, вероятней всего, питонист выражает своё "фе" по отношению к Си.
     
     
  • 6.31, myhand (ok), 08:27, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Детка, CPython - написан на C, a С API - часть стандарта языка.  Это знает любой питонист.
     
  • 6.53, Аноним (53), 14:34, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это, вероятней всего, питонист выражает своё "фе" по отношению к Си.

    "Фе", потому что сделали похожим на питон, пусть и без второй главной фишки модулей - отдельных неймспейсов?
    Это A!
    A-Aстахальная логика.

    Осталось тебе нам c умным (и уверенным! Это важно!) видом поведать, почему сишный #include на самом деле не жуткий костль из древних времен, а очень классная фича и все кто не согласен - являются латентными питонистами!


     
     
  • 7.73, Акакжев (?), 16:11, 26/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    #include не костыль. Это осталось от ассемблера.

    Очень полезная штука. Что бы при компиляции процессор впустую не простаивал, надо один и тот же файл обработать по 100 раз (лениво увернулся от помидоров с precompiled headers).

     
  • 3.37, captcha 20168 (?), 10:19, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > модули для C взамен #include

    грязные извращенцы

     
     
  • 4.58, Аноним (58), 15:49, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А помоему давно назрела тема. Сколько можно буквы гонять туда сюда по парсеру.
    Только время зря терять. Кофе переводить. Давать фору другим языкам вроде JavaScript.
     
     
  • 5.61, Аноним (61), 17:50, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Сколько можно буквы гонять туда сюда по парсеру. Только время зря терять.

    Ви так говорите, как будто это является боттлнеком при компиляции

     

  • 1.2, h31 (ok), 00:08, 20/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Насколько реально использовать Clang в качестве альтернативы MinGW под венду? Есть у кого-нибудь опыт?
     
     
  • 2.4, SashaMelnikov (ok), 00:21, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    есть статьи про то как собирают хром под windows, в справке llvm есть инструкции как настроить VS.

    https://llvm.org/docs/GettingStartedVS.html

     
     
  • 3.7, Аноним (11), 00:29, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тормозила тоже переползает на шланг.
    https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instruc
    >And as of bug 1483835, local Windows builds use clang-cl by default.
     
     
  • 4.24, Столман (?), 04:46, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ничего плохого в переползании на Clang с MSVC
     
     
  • 5.28, пох (?), 07:05, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    We still depend on a VS installation for its headers, libraries, and some auxiliary build tools.

    ничего хорошего в переползании ради переползания.
    особенно когда вся отладка так и идет в visual debugger.

    ну чего вы хотите от альтернативно-одаренных...

     
     
  • 6.32, Аноним (32), 09:37, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > ничего хорошего в переползании ради переползания.

    Буст производительности не считается?

     
     
  • 7.34, пох (?), 09:59, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> ничего хорошего в переползании ради переползания.
    > Буст производительности не считается?

    а он был?

     
  • 6.36, Аноним (36), 10:05, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так сначала нужно переехать хотя-бы на компилятор, потом можно будет смотреть за отказ от всего vs, по идее логично.
     
     
  • 7.55, AnonPlus (?), 15:05, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Он хочет одним большим прыжком. А в таких огромных проектах лучше есть слона по частям.
     
  • 7.59, Аноним (58), 15:50, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > так сначала нужно переехать хотя-бы на компилятор, потом можно будет смотреть за отказ от всего vs, по идее логично.

    потом отладчик, а потом и операционная система, а потом и весь мир ... мухахахаха

     
  • 2.5, Аноним (11), 00:24, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    У Гугла есть. Они собираются всю свою мультиплатформу на шланг перевести.
    Хром уже
    http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html
    На очереди NDK для ведра и эмуль.
     
  • 2.6, SashaMelnikov (ok), 00:26, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    но как по мне, проще настроить кросс компиляцию с таргетом в windows чем использовать windows для этого.
     
     
  • 3.9, Аноним (11), 00:33, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Без тестирования результатов компиляции? Желательно автоматического.
    Халтурненько.
     
     
  • 4.42, Annoynymous (ok), 11:15, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А компилятор VS ещё и сам протестирует? Вот до чего техника дошла!
     
     
  • 5.49, Аноним (49), 13:58, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >А компилятор VS

    билд-агент. Освойте уже CI/CD.
    Год то на календаре никак не 2005.
    Пора из пещер вылезать.

    >протестирует

    А после кроскомпиляции на лине вы где будете exe-шник запускать?

     
     
  • 6.52, Annoynymous (ok), 14:07, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > билд-агент. Освойте уже CI/CD.

    Баззворды детектед.

    > Год то на календаре никак не 2005.
    > Пора из пещер вылезать.

    Да-да, у нас новый модный агил, вы ничего не понимаете в разработке. Обходимся без компилятора, одними билд-агентами.

    > А после кроскомпиляции на лине вы где будете exe-шник запускать?

    На винде. // К.О.

    Только не надо задавать глупых вопросов вида «если у вас есть винда для отладки, почему бы на ней же и не собрать», да?

    А то год-то на календаре никак не 2005.

     
  • 3.19, h31 (ok), 01:46, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я не для себя спрашиваю, это друг попросил^W^W^W ищу, что бы можно было посоветовать вендоюзерам для сборки сишных программ. Потому что ставить целую вижуал студию для сборки и потом разбираться, как в неё загрузить проект очень геморно.
     
     
  • 4.25, Аноним (25), 04:53, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну тут скорее вопрос в системе сборки. Сомневаюсь, что современные системы сборки поддерживают вариант сборики при помощи Clang под Винду. Придется колхозить свои велосипеды, либо ждать, пока подтянутся разработчики систем сборки.

    Хотя, поскольку Гугл уже полгода использует Clang для своего браузера, сразу видно, что он готов для продакшена.

     
     
  • 5.69, Александр (??), 10:56, 22/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Все (или почти все) системы сборки, которые юзаются под линуксом, вполне себе робят на винде. Из опробованного: cmake, scons, premake, qmake, autogen (или как там его правильно). В принципе, достаточно поставить msys2, а там всё это (и не только) есть.
     
     
  • 6.70, Александр (??), 10:59, 22/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >autogen (или как там его правильно)

    autotools точнее.

     
  • 4.26, qrKot (?), 06:17, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> для сборки сишных программ
    >> ставить целую вижуал студию для сборки и потом разбираться, как в неё загрузить проект очень геморно

    Посоветуйте им не собирать сишные программы.

     
     
  • 5.29, пох (?), 07:06, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Посоветуйте им не собирать сишные программы.

    никогда и ни под какую платформу.

     
  • 4.39, nobody (??), 10:37, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем это делать? Что мешает собирать из командной строки с помощью cl.exe + make/cmake?
     
     
  • 5.40, nobody (??), 10:41, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И "целую вижуал студию" для этого ставить не надо. Есть такая штука, как Build Tools for VS. Там только утилиты командной строки без всякой VS
     
  • 5.41, нах (?), 10:43, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Зачем это делать? Что мешает собирать из командной строки с помощью cl.exe
    > + make/cmake?

    неумение пользоваться ни тем, ни другим - мы можем только "загружать проект".

     
  • 5.56, h31 (ok), 15:13, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Зачем это делать? Что мешает собирать из командной строки с помощью cl.exe
    > + make/cmake?

    Никто не мешает. Только вот для MinGW есть неплохие IDEшки. Qt Creator, Clion. Видел, что даже Code::Blocks пользовались. Под "собирать" я имел в виду не просто компиляцию, а разработку в целом, с отладчиком и всеми делами.

    Почему спрашиваю - потому что я не нашёл свежих, стабильно работающих и легко устанавливаемых сборок MinGW. Везде чего-то не хватает.

     
     
  • 6.65, nobody (??), 09:32, 21/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > не нашёл свежих, стабильно работающих и легко устанавливаемых сборок MinGW

    https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting&

     
  • 6.72, Аноним (72), 17:20, 22/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кажется парочку лет назад в блогах МС побегали восторженные статьи - используйте wsl и gcc оттуда. Теперь всё это прекрасно интегрируется и не нужен mingw. Опять у них на 180 градусов всё поменялось?
     
  • 3.64, A.Stahl (ok), 09:01, 21/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, ок.


     
  • 3.71, mimocrocodile (?), 14:45, 22/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В mingw довольная скудная поддержка windows API, например, для COM надо использовать C интерфейсы.
     

  • 1.27, Аноним (27), 06:32, 20/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    >__attribute__((target("arch=atom")))  

    копируют фичи из ржавчины, молодцы. Глядишь, лет через 10 дорастут до модулей))

     
     
  • 2.50, Аноним (49), 14:00, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Модуле в расте - самая слабая часть языка.
    Настолько, что в новой редакции - Rust 2018
    Мозила будет систему модулей перепиливать,
    а "extern" вообще выкинет.
     

  • 1.33, Аноним (32), 09:40, 20/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Всегда удивляло, почему в ReleaseNotes никогда не попадают изменения в бэкенде AMDGPU. Ох уж эти ленивые AMD-шники.
     
     
  • 2.35, пох (?), 10:00, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Всегда удивляло, почему в ReleaseNotes никогда не попадают изменения в бэкенде AMDGPU.

    у эпла, видимо, не амде в и-шмяке.

     

  • 1.38, Евгений (??), 10:24, 20/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    День добрый.
    Кто-нибудь может по-русски написать, как с помощью clang упростить создание собственного компилятора собственного языка?
     
     
  • 2.43, Аноним (43), 11:30, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Понятия не имею, но если бы мне было нужно я бы на github поискал новые языки на llvm бекенде, таких много делают и почти всегда забрасывают, но там можно подглядеть код, позаимствовать структуру проекта и понять как кто конфигурирует сборку проект. Все интересно записывать, т.е. самому себе написать доку, можно даже по-русски :)
     
  • 2.44, mandms (?), 11:34, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а вот
    https://www.google.com/search?q=llvm+%D1%81%D0%BE%D0&

    первые 5 ссылок, включая видео, хорошие


    если будут конкретные вопросы, тогда окажется что у вас реальная деятельность

     
  • 2.46, trolleybus (?), 12:28, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот пример собственного авторства с lex+yacc+llvm: https://github.com/hyst329/helen-llvm
    Советую посмотреть только на архитектуру, а не на сам код (там есть практически нечитаемые вещи)
     
  • 2.47, Andrey Mitrofanov (?), 13:32, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > День добрый.
    > Кто-нибудь может по-русски написать, как с помощью clang упростить создание собственного
    > компилятора собственного языка?

    Отдел маркетинга Эппле?...   Если сумма их заинтересует.

     
  • 2.51, Аноним (49), 14:02, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Кто-нибудь может по-русски написать, как с помощью clang упростить создание собственного компилятора собственного языка?

    Извините, Евгений, но по твоему вопросу создается впечатление,
    что ты слишком туп для этого.
    Ничего личного.

     
     
  • 3.60, Аноним (58), 15:54, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дело не в тупости. Эти ребята хипстеры. В ротик положи и разжуй.
    Может быть проще вам просто заказать компилятор. МНогие тут готовы написать.
    Какой суммой Вы распологаете для этих целей?

    ЗЫ Либо это хобби и ради этого ты профукиваешь выходные и понимаешь как это работает либо ты заказываешь это у специалиста по компиляторам. Я вот знаю одного в Самсунге сейчас работает. Писал в свое время отечественный Сиплюсплюс а сейчас лекции читает.

     

  • 1.45, iZEN (ok), 12:15, 20/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Например, lld/ELF пригоден для компоновки всех компонентов FreeBSD для архитектур AMD64 и ARMv7, и будет применяться в качестве компоновщика по умолчанию в следующей версии FreeBSD.

    Походу FreeBSD 12 [amd64], [arm32] выйдет без GCC в составе системы и GNU linker.

    Но в сорцах всё равно всё это останется - для [powerpc64] других компиляторов не завезли.

     
     
  • 2.48, Andrey Mitrofanov (?), 13:45, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Например, lld/ELF пригоден для компоновки всех компонентов FreeBSD для архитектур AMD64 и ARMv7, и будет применяться в качестве компоновщика по умолчанию в следующей версии FreeBSD.
    > Походу FreeBSD 12 [amd64], [arm32] выйдет без GCC в составе системы и
    > GNU linker.

    —̶Д̶ж̶в̶а̶ ̶г̶о— Восемь лет ждал!
    http://www.opennet.dev/openforum/vsluhforumID3/68588.html#53

    Всё никак не дождусь, когда же теперь уже Эппле будет "базовую систему" шатать на компиляторе.

    Доколе!123

    > Но в сорцах всё равно всё это останется - для [powerpc64] других
    > компиляторов не завезли.

    Это такие, "11 ports fail to build", мелочи[I]!
    //https://wiki.freebsd.org/GPLinBase

    ..."Ждём FreeBSD 10+" Team. Основатель.

     
     
  • 3.54, Аноним (53), 14:45, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Например, lld/ELF пригоден для компоновки всех компонентов FreeBSD для архитектур AMD64 и ARMv7, и будет применяться в качестве компоновщика по умолчанию в следующей версии FreeBSD.
    >> Походу FreeBSD 12 [amd64], [arm32] выйдет без GCC в составе системы и
    >> GNU linker.
    > —̶Д̶ж̶в̶а̶ ̶г̶о— Восемь лет ждал!

    https://www.freebsd.org/releases/10.0R/relnotes.html
    > 20.01.2014
    > GCC and GNU libstdc++ are no longer built by default

    Где-то в криокамере? Верю[I]![/I]

    > Это такие, "11 ports fail to build", мелочи[I]!

    из 35 тысяч? Конечно мелочи:

    Calculated hourly:
    Port count 35202
    Broken 52
    Deprecated 305
    Ignore 302
    Forbidden 5
    Restricted 162

    new fortnight 135
    new month 3012


     
     
  • 4.57, Andrey Mitrofanov (?), 15:25, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>>> Например, lld/ELF пригоден для компоновки всех компонентов FreeBSD > Где-то в криокамере? Верю[I]![/I]

    Не, /10.0R/relnotes.html ничего не сообщают об окончательном и бисповоротном выкидываниии всего и всякого GNU и GPL "из базы".


    >> —̶Д̶ж̶в̶а̶ ̶г̶о— Восемь лет ждал!

    Вот коллега иЗен возлагает вполне обоснованные надежды на R12.  На выкидывание чего-то окуда-то, да.

    Так что, не раньше /12.0R/relnotes.html, да.  Но как бы не позже бы...

    >> Это такие, "11 ports fail to build", мелочи[I]!
    > из 35 тысяч? Конечно мелочи:

    А я так надеялся, то это 11 "архитектур"....

    Впрочем, и amd64 без GNU as "опять" не собирается:
    https://bugs.freebsd.org/205250
    , хотя про слово "skein" [crypto/skein/amd64] они вроде предурперждали.

    Они все
      . https://www.bsdcan.org/2017/schedule/attachments/437_BSDCan2017-FreeBSDToolCha
    гонят какую-то непонятную пургу.

    Когда, я спрашиваю... [I]Доколе!?...[/I]  они уже самостийно и ннезалежно перестанут пользовать ненависный GNU ?..

     
  • 4.62, пох (?), 19:12, 20/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > GCC and GNU libstdc++ are no longer built by default

    это, конечно, прекрасно, что гну-выкидыш не собирается "by default", но смешно то, что ld от него не только "by default", но без него нельзя собрать base system. И в 12 тоже (пока в нее не втянули распоследнюю версию и не перенесли сборку на нее)
    А вот если сделать WITHOUT_LLD - ни одно животное не пострадает.


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

     
     
  • 5.63, Аноним (53), 00:20, 21/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> GCC and GNU libstdc++ are no longer built by default
    > это, конечно, прекрасно, что гну-выкидыш не собирается "by default", но смешно то, что ld от него не только "by default", но без него
    > нельзя собрать base system. И в 12 тоже (пока в нее

    Вылезайте из криокамеры:



    % whereis ld
    ld: /usr/bin/ld /usr/share/man/en.UTF-8/man1/ld.1.gz
    % grep LD /etc/src.conf              
    WITH_LLD_IS_LD=yes
    % ld -v
    LLD 6.0.1 (FreeBSD 326565-1100002) (compatible with GNU linkers)


     
     
  • 6.66, Аноним (66), 10:14, 21/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а что у нас грит uname -srm?
     
     
  • 7.68, Аноним (53), 12:45, 21/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а что у нас грит uname -srm?

    % uname -srm                                                                                                  
    FreeBSD 11.2-STABLE amd64

    А git log говорит



    commit bbd7307a2c2c719e7e0c1195bce66f37e1c05c85
    Author: emaste <emaste@FreeBSD.org>
    Date:   Thu May 18 17:40:30 2017 +0000

        MFC LLD changes and enable LLD as /usr/bin/ld on arm64 by default
    ..
        LLVM's LLD linker is now included in the base system, and is enabled by
        default for arm64 and capable of linking world and kernel. Thus, avoid
        automatically setting CROSS_BINUTILS_PREFIX and requiring the binutils
        port if WITH_LLD_IS_LD is true.


     
  • 5.67, Аноним (66), 10:15, 21/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    нормально он движется. то вы с линухом давно плотненько не сталкивались...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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