FreeBSD buildworld clang очень долго

Ну сделай pkg install llvm19, например, а потом pkg lock -y llvm19, собери что тебе надо, а потом pkg unlock -y llvm19 && pkg del llvm19.

Не понял каким образом это связано с моим вопросом. Речь про buildworld и про то почему он долго компилирует шланг.

Если что, buildworld никак с pkg не взаимодействует. С помощью кастомных опций можно его заставить использовать внешний компилятор (в т.ч. установленный из pkg, но в целом ему будет всё равно откуда взялся указанный бинарник), но я хочу не убрать компиляцию шланга вообще, а выяснить почему она долгая, при том что кто-то говорит что шланг и gcc собираются примерно за одинаковое время.

Я не сварщик и во фряхе только разбираюсь, но может ccache поможет, если ты постоянно пересобираешь систему?

Я сам freebsd не использую, но могу сказать по поводу разницы между clang и gcc. По умолчанию clang (и llvm) собираются с поддержкой всех возможных платформ и архитектур для кросс компиляции. А gcc наоборот собирается только под одну конкретную архитектуру.

Попробуй выполнить команду

clang -print-targets

-DLLVM_TARGETS_TO_BUILD="X86"

не знаю как на фре, но у меня на линуксе с использованием компилятора gcc clang компилируется в 2 раза дольше чем gcc.

Опять: речь не идёт про пропуск каких-то действий, речь про «почему оно долгое». И я не пересобираю постоянно, но за 10 лет достаточно раз чтобы задаться этим вопросом.

И правда

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    mips       - MIPS (32-bit big endian)
    mips64     - MIPS (64-bit big endian)
    mips64el   - MIPS (64-bit little endian)
    mipsel     - MIPS (32-bit little endian)
    ppc32      - PowerPC 32
    ppc32le    - PowerPC 32 LE
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    riscv32    - 32-bit RISC-V
    riscv64    - 64-bit RISC-V
    sparc      - Sparc
    sparcel    - Sparc LE
    sparcv9    - Sparc V9
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

Зависит от конкретной архитектуры, некоторые небольшие и разницы большой не сделают а некоторые очень тяжелые, например x86 и Aarch64 очень жирные потому что там понаписали кучу оптимизаций и трансформаций в SIMD инструкции и тп. Сколько конкретно сэкономит не скажу, давно не собирал, но рекомендую попробовать.

А опция -DLLVM_TARGETS_TO_BUILD=«X86» выберет и x86 и x86-64? И куда её сувать? Просто аргументом make (наверно она пробросится от фрибсного make верхнего уровня до сборщика компилятора)?

Да, X86 включает оба и 32 и 64 бита потому что внутри это один и тот же бекенд. Опцию надо не в make, а в первый вызов cmake для llvm и для clang. Как это сделать на FreeBSD не знаю, на арче если бы я собирал то вставил бы этот флаг сюда PKGBUILD

Хм, cmake-а в базовой системе фрибсд точно нет, там скорее всего что-то пропатчили чтобы без него собирать.

...убрать ненужное - он станет сильно быстрее собираться...

По идее, да, должен.

А зачем вообще билдворлд? По-секрету?

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

• Компиляй в несколько потоков: make -jN buildworld

• В /etc/src.conf:

WITHOUT_LLVM_TARGET_AARCH64=YES
WITHOUT_LLVM_TARGET_ARM=YES
WITHOUT_LLVM_TARGET_MIPS=YES
WITHOUT_LLVM_TARGET_POWERPC=YES
WITHOUT_LLVM_TARGET_SPARC=YES
WITHOUT_LLVM_TARGET_RISCV=YES

В итоге, должно остаться:

# clang -print-targets

  Registered Targets:
    x86     - 32-bit X86: Pentium-Pro and above
    x86-64  - 64-bit X86: EM64T and AMD64

• Если юзаешь ZFS, то: zfs set=sync=disabled zroot/usr/obj

Не знаю на какой кофеварке ты компиляешь, но на моем стареньком i9-9900k компиляция всей системы с ноля занимает не более часа. А если делаю апдейт, то около минуты (если шланг не пересобирается).

PS: man src.conf, там можно поотключать кучу всего неиспотзуемого.

А ядро за сколько собирается?

А ну и сравнивать -jN бесполезно, оно же от N зависит. Речь про суммарное время всех потоков.

А ядро за сколько собирается?

# make -j20 buildkernel KERNCONF=IRON
...
--------------------------------------------------------------
>>> Kernel build for IRON completed on Sat Oct 25 00:46:48 EEST 2025
--------------------------------------------------------------
>>> Kernel(s)  IRON built in 172 seconds, ncpu: 16, make -j20
--------------------------------------------------------------

А ну и сравнивать -jN бесполезно, оно же от N зависит.

Угу, количество ядер решает… Плюс, кастомный конфиг ядра, с включенными только нужными драйверами и фичами.

А, ну так 172*20 = 3440 - у меня где-то на 30% дольше собирается, и это GENERIC. Так что не надо про кофеварку, всё твоё ускорение исключительно от -j20 (и даже с buildworld: у меня часов 30, у тебя час с чем-то отключённым но в 20 потоков) и вероятно от ssd (у меня /usr/obj на hdd, хотя /usr/src на ssd сейчас да).

с включенными только нужными драйверами

Впрочем выключенные ненужные всё равно компилируются - для модулей. Или ты как-то сделал что даже kldload их не может подгрузить?

Впрочем выключенные ненужные всё равно компилируются - для модулей. Или ты как-то сделал что даже kldload их не может подгрузить?

Если ты просто скопировал GENERIC конфиг и закомментировал там все ненужное, то оно просто не будет билдится и инсталится. Следовательно, kldload его не найдет. Но отключать нужно читая комменты в конфиге. К примеру, если выключить device scbus то cd драйвер не соберется (будет ошибка линковки), ixl не скомпиляется если выключить iflib и т.д.

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

Эм, нет. Во всех случаях когда я с этим сталкивался - через kldload как раз прекрасно подгружалось то что было закомментировано в конфиге. В конфиге настраивается то, что будет статически слинковано в файл /boot/kernel/kernel

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

Проверил, да, ты прав. Чтоб не билдить модули нужно указать переменную NO_MODULES=YES. Подробнее можно прочитать тут: /usr/src/share/examples/etc/make.conf.

Помню, как на AthlonXP 2500+ FreeBSD собиралась буквально за полчаса - за сорок минут. Сейчас на сборку системы FreeBSD 14.3-STABLE на Ryzen 3900X/NVMe SSD требуется порядка 6 часов(!). src.conf оптимизировал донельзя — бесполезно. Это какое-то проклятье с LLVM/Clang произошло. Компилятор ради самого компилятора, а система побоку.