Жду, когда GCC будет способен собрать ядро FreeBSD, чтобы выкинуть из системы жирнючий LLVM/Clang.

Ты стебёшься?

Жду, когда GCC будет способен собрать ядро FreeBSD

Зачем ждать, собирай и шли патчи на то, что не собирается.

выкинуть из системы жирнючий LLVM/Clang

Если имеется в виду базовая система, то вполне уже можно собирать, используя llvm из портов/пакетов.

А тему для чего создал?

GCC из FreeBSD старательно выпилили несколько лет назад, по лицензионным причинам. iZEN не может этого не знать. Он явно стебётся.

Рассказать, обсудить. Кстати, где публикуются список изменений RC по сравнению с предыдущим релизом?

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

Размер незапакованного патча порядка 57 мегабайт.

Это уже традиция.

Скромно и со вкусом

Размер незапакованного патча порядка 57 мегабайт.

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

Подождали бы 3 дня.

Где смотреть изменения у гцц — не знаю.

Размер незапакованного патча порядка 57 мегабайт. Список изменений я не нашёл

Ничоси, любопытно

Что мешает использовать icc?

Где смотреть изменения у гцц — не знаю.

Добавят новую ссылку внизу https://gcc.gnu.org/gcc-11/changes.html.

Значит надо ждать три дня.

Спасибо.

Не угадал автора по заголовку

https://gcc.gnu.org/gcc-11/changes.html

не знают они где смотреть... да все тут же

В смысле? А до шланга как оно у вас там собиралось? Чёт ты мутки мутишь

ЕМНИП, ядро FreeBSD 11 можно собирать GCC.

Никаких дополнительных критериев ты не указал, поэтому твое желание можно считать удовлетворенным.

PCC же

Изя вроде как по нему ностальгирует.

echo "CC=/usr/local/bin/gcc11 \
CXX=/usr/local/bin/g++11 \
CPP=/usr/local/bin/cpp11" >> /etc/make.conf

Попробуй собрать: cd \usr\src && make cleandir buildworld buildkernel WITHOUT_CLANG=true

— вместе посмеёмся.

Если имеется в виду базовая система, то вполне уже можно собирать, используя llvm из портов/пакетов.

Можно. Но хочется GCC.

Не угадал автора по заголовку

saahriktu ? :-))

Зачем тебе этого хочется?

Пред-минорщина, в пиконовости.

Stop при компиляции мира GCC12-devel:

===> lib/libc_nonshared (obj,all,install)
/usr/local/bin/gcc12  -O2 -pipe -fno-common   -fpic -DPIC -fvisibility=hidden -I/usr/src/lib/libc/iconv -MD  -MF.depend.__stub.o -MT__stub.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong    -c /usr/src/lib/libc_nonshared/__stub.c -o __stub.o
/usr/local/bin/gcc12  -O2 -pipe -fno-common   -fpic -DPIC -fvisibility=hidden -I/usr/src/lib/libc/iconv -MD  -MF.depend.__iconv.o -MT__iconv.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong    -c /usr/src/lib/libc/iconv/__iconv.c -o __iconv.o
In file included from /usr/src/lib/libc/iconv/__iconv.c:33:
/usr/src/lib/libc/iconv/iconv-internal.h:37:52: error: unknown type name '__iconv_bool'
   37 | int     __bsd___iconv_get_list(char ***, size_t *, __iconv_bool);
      |                                                    ^~~~~~~~~~~~
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib/libc_nonshared
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

Stop при компиляции ядра компилятором GCC12-devel:

>>> stage 3.1: building everything
--------------------------------------------------------------
cd /usr/obj/usr/src/amd64.amd64/sys/COMP; MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="/usr/local/bin/gcc12 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="/usr/local/bin/g++12  --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CPP="/usr/local/bin/cpp12 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip" INSTALL="install -U" PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
/usr/local/bin/gcc12 -c -O2 -pipe -frename-registers -fno-strict-aliasing -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genoffset.o -MTgenoffset.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=address -Wno-error=aggressive-loop-optimizations -Wno-error=array-bounds -Wno-error=attributes -Wno-error=cast-qual -Wno-error=enum-compare -Wno-error=maybe-uninitialized -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=overflow -Wno-error=sequence-point -Wno-error=shift-overflow -Wno-error=tautological-compare -Wno-unused-but-set-variable -Wno-error=stringop-overflow -Wno-error=memset-elt-size -Wno-error=packed-not-aligned -Wno-address-of-packed-member -Wno-format-zero-length -fms-extensions -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fms-extensions -std=iso9899:1999 -fcommon /usr/src/sys/kern/genoffset.c
gcc12: error: unrecognized command-line option '-fformat-extensions'; did you mean '-fno-ms-extensions'?
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/COMP
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

vim /usr/src/share/mk/….. && send-pr^W bugs.freebsd.org/reviews.freebsd.org :)

Да.

очень толсто. зачем gcc во фре?

зачем gcc во фре?

А зачем LLVM/Clang, да ещё в нескольких количествах?

> pkg info -x llvm
llvm12-12.0.1

> cc --version
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin

А зачем LLVM/Clang

Потому что это цельный не-GPL тулчейн, что так нравится (и оплачивается) «энтерпрайзу», у которого понимание «свободы» может отличаться от того, что в GPL.

да ещё в нескольких количествах

К тому, что в базовой системе, есть только одно требование - собирать саму же базовую систему; если этой версии недостаточно для сбора определенных портов, ставится нужная. Точно так же в некоторых местах используются различные версии gcc.

К тому, что в базовой системе, есть только одно требование - собирать саму же базовую систему

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

Может надо gcc 4.2 с BSD-патчами использовать, а не бету 12?

Хотя я не пробовал. Но тоже расстроен «внедрением» гадостного clang’а туда.

Я всё никак не могу понять настоящую причину недовольства «гадостным clang»:

1. Какие-то идеологические причины – какие?
2. «Сборка clang занимает большую часть времени сборки world» – pkg install llvm12, и правка src.conf должны помочь.
3. Что-то еще?

Так же, есть возможность найти соответствующие патчи для 4.2 в VCS, и добавить их в порт lang/gccN, но в чём профит?

Если кратко, то clang делается странными людьми, которым их религиозно-нормативные убеждения касательно стандартов важнее здравого смысла, а целевая аудитория - новички, программирующие раз в год.

Уже писал на другом сайте, скопирую сюда:

1. писать компилятор на прикладном с++ вместо системного с
2. компилятор компилируется (сам себя) около суток на обычном компе
3. всякие мелкие педантичные пакости типа запрета unsigned int argc в main (который формально не по стандарту, но по факту не существует систем где оно несовместимо, да и стандарт кажется запрещает int и unsigned int иметь разные представления для положительных чисел) — причём это не варнинг а ошибка, да ещё и неотключаемая
4. включёные по дефолту идиотские варнинги о рекомендации писать (A&&B)||C вместо A&&B||C и ещё какие-то (не помню) — создают впечатление что оно сделано для умственно отсталых

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

Так же, есть возможность найти соответствующие патчи для 4.2 в VCS, и добавить их в порт lang/gccN, но в чём профит?

Ни в чём. gcc 4.2 просто работает, его и надо было оставить. Новые версии (в контексте C) нужны только для всякой экзотики.

А что, до сих пор нельзя?

gcc 4.2 просто работает

А где его теперь взять?

Странный вопрос, как будто его удалили из интернета.

Правильный вопрос такой: как получить систему с gcc 4.2 и с новыми версиями того, что обновлять нужно (например, ядра) FreeBSD. Тут уже разные варианты имеются - либо делать самому, либо уговорить мэйнтейнеров вернуть gcc в главную ветку. Первое кажется проще.

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

всякие мелкие педантичные пакости типа запрета unsigned int argc в main (который формально не по стандарту, но по факту не существует систем где оно несовместимо, да и стандарт кажется запрещает int и unsigned int иметь разные представления для положительных чисел) — причём это не варнинг а ошибка, да ещё и неотключаемая

А зачем кому-то может хотеться объявить unsigned int argc в main?

уговорить мэйнтейнеров вернуть gcc в главную ветку

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

как будто его удалили из интернета

Более того, спасибо vcs, его не удалили даже из freebsd-src.

1. писать компилятор на прикладном с++ вместо системного с

GCC, внезапно, тоже на C++

2. компилятор компилируется (сам себя) около суток на обычном компе

Выбрасывай свой обычный комп и покупай современный.

3. unsigned int argc в main (который формально не по стандарту, но по факту не существует систем где оно несовместимо

Очень сильный аргумент, даже не знаю чем покрыть.

4. создают впечатление что оно сделано для умственно отсталых

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

Затем что сувание signed int туда, где отрицательных чисел в принципе быть не должно - чуть (в данном случае незаметно, да, но всё равно неприятно) уменьшает скорость работы кода (сравни ассемблер для деления на 2 для unsigned и singed), чуть увеличивает вероятность багов (этого видел огромное количество на практике, хотя да не с argc, а с другими переменными, и не в своём коде) и уменьшает общую прозрачность и эстетичность кода.

где отрицательных чисел в принципе быть не должно

Ты ни разу не видел return -1 в main()?

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

Вот те кто путают приоритеты, пусть себе его и включают. А когда компилятор включает его по дефолту, становится ясно, что его целевая аудитория - как раз эти путающие. Для них предложу идею - в формулах вида a*b+c тоже рекомендовать скобки: (a*b)+c.

Вот те кто путают приоритеты, пусть себе его и включают.

Те, кто зубрят все эти приоритеты вместо написания полезного кода должны страдать и выключать это предупреждение. Для большинства программистов оно полезно, поскольку повышает безопасность кодовых баз и избавляет от множества багов, оставленных как раз людьми, которые думают что знают всё от приоритетах в C/C++.

Причём тут return? Речь про argc.

return -1 это стандартный способ вернуть состояние ошибки наверх. Если речь про то, что exit code сам по себе unsigned, то это отдельная тема, но не аналогичная - тут знаковость минус единицы никуда в логику дальнейшего кода не попадает, по факту это возврат максимально возможного кода завершения. А в случае с int argc нельзя даже сделать нормальное size_t i; for(i=1;i<argc;i++) без плохого знаково-беззнакового сравнения. А индекс должен быть size_t.

Ты сейчас выглядишь как двоечник, который еле осилил правила арифметики и думает на осиливших, что они их «зубрят». Если ты программируешь не раз в год, то порядок таких постоянно используемых операций сам собой очень быстро запоминается. Не помнят их только малокомпетентные (либо ввиду неопытности, либо ввиду умственной отсталости) С-программисты.

А в случае с int argc нельзя даже сделать нормальное size_t i; for(i=1;i<argc;i++) без плохого знаково-беззнакового сравнения.

в с++ можно.

size_t i; for(i=1; std::cmp_not_equal(i,argc);i++)

Внезапно:

$ cat t.c
int
main(void)
{
        int a = 1;
        int b = 2;
        int c = 3;

        if (a > 0 && b < 10 || c == 5)
                return (1);

        return (0);
}
$ cc -v
FreeBSD clang version 12.0.1 (git@github.com:llvm/llvm-project.git llvmorg-12.0.1-0-gfed41342a82f)
$ cc -o t t.c
$ cc -Wall -o t t.c
t.c:8:12: warning: '&&' within '||' [-Wlogical-op-parentheses]
        if (a > 0 && b < 10 || c == 5)
            ~~~~~~^~~~~~~~~ ~~

То есть, никакого «по умолчанию».

Смотрим gcc, который «правильный»:

$ gcc11 -v
...
gcc version 11.1.0 (FreeBSD Ports Collection)
$ gcc11 -o t t.c
$ gcc11 -Wall -o t t.c
t.c: In function 'main':
t.c:8:19: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
    8 |         if (a > 0 && b < 10 || c == 5)
      |             ~~~~~~^~~~~~~~~

И до них ллвмовцы добрались? :)

Сравнить то можно и в C (и не только равенство, но и <), но конструкция получается громоздкая. А можно просто написать соответствующий логике переменной тип.