Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет Misha Verbitsky ([info]tiphareth)
@ 2019-11-28 11:34:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Настроение: sick
Музыка:Amon Duul - Die Losung
Entry tags:gentoo, linux

LLVM: internal compiler error: Segmentation fault
Запишу, чтобы не забыть, потому что не первый раз уже.
LLVM при попытке его откомпилировать вылетает с
internal compiler error: Segmentation fault
от версии компилятора (пробовал gcc 7 и 8)
и версии LLVM (пробовал 6, 7, 8) это не зависит,
и практически не гуглится, кроме баг-репортов.

Лечится так:
NINJAOPTS="-j1" emerge -av1 llvm

(дефолт "-j4" у меня).

Компилируется эта хуйня, кстати, часа 2.
Но без нее нельзя запустить mesa, без которой
не работают иксы.

Привет


(Читать комментарии) - (Добавить комментарий)


[info]id0
2019-11-28 18:44 (ссылка)
Миша, что у тебя за видео и покажи юз флаги, пожалуйста.
потому что я живу на невидии и на интеле без зависимостей от ллвм,
если я правильно помню, это зависимость от радеона и компайлера
шадыров, там ещё АоС скоро завезут, может он отдельно от ллвм будет.
В любом случае, как помню, можно даже с радеоном жить без ллвм
[ebuild U ] media-libs/mesa-19.3.0_rc4::gentoo [19.2.0_rc2::gentoo] USE="X classic dri3 egl gallium gbm gles2 osmesa -d3d9 -debug -gles1 (-libglvnd) -llvm -lm-sensors% -opencl -pax_kernel (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -wayland -xa -xvmc (-lm_sensors%)" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="i965 intel (-freedreno) -i915 -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" 11,515 KiB

(Ответить) (Ветвь дискуссии)


[info]tiphareth
2019-11-28 20:40 (ссылка)
USE="-bindist mmx sse sse2 xvmc cvs -pulseaudio acpi jpeg ncurses offensive mp3 mpeg pdf perl png python quicktime readline recode sdl spell svg tetex tiff truetype usb X xml xv x86 -gnome kpathsea sqlite -gstreamer gimp scanner -fortran scrobbler tk device-mapper mad -qt3support -kde -udisks -policykit -consolekit -acl -libnotify -bluetooth gcj -introspection bidi apulse -gpm icu webkit pcre16 printsupport qt5 minizip sqlite -qt4 tk -geolocation -geoloc gstreamer -libproxy nvidia xvmc tools -pam"

видео nvidia

>живу на невидии и на интеле без зависимостей от ллвм

equery d mesa
* These packages depend on mesa:
app-office/libreoffice-6.0.6.2 (media-libs/mesa[egl])
dev-qt/qtgui-5.12.5 (egl ? media-libs/mesa[egl])
(eglfs ? media-libs/mesa[gbm])
(gles2 ? media-libs/mesa[gles2])
media-libs/glfw-3.2.1 (wayland ? media-libs/mesa[egl,wayland])
media-libs/gst-plugins-bad-1.12.3 (>=media-libs/mesa-9.1.6[egl,abi_x86_32(-),abi_x86_64(-)])
(>=media-libs/mesa-9.1.6[abi_x86_32(-),abi_x86_64(-)])
media-libs/libepoxy-1.4.2 (media-libs/mesa[egl,abi_x86_32(-),abi_x86_64(-)])
media-libs/libtxc_dxtn-1.0.1-r1 (media-libs/mesa)
net-libs/webkit-gtk-2.22.2 (media-libs/mesa[egl])
virtual/opengl-7.0-r1 (>=media-libs/mesa-9.1.6[abi_x86_32(-),abi_x86_64(-)])
www-client/firefox-52.4.0 (>=media-libs/mesa-10.2)
x11-apps/mesa-progs-8.3.0 (media-libs/mesa)
x11-base/xorg-server-1.20.5 (!minimal ? >=media-libs/mesa-18[X(+),egl,gbm])
x11-libs/cairo-1.16.0-r3

equery d llvm
* These packages depend on llvm:
media-libs/mesa-19.1.7 (video_cards_r600 ? sys-devel/llvm:9[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,llvm_targets_AMDGPU(-)])

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]id0
2019-11-29 05:20 (ссылка)
media-libs/mesa-19.1.7 (video_cards_r600 ? sys-devel/llvm:9[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?,llvm_targets_AMDGPU(-)]
тут же написано как раз то, о чём говорю, амдгпу, мипсы и рискпятики
зависят от ллвм.
если VIDEO_CARDS"intel nvidia i965/iris"
то всё должно быть хорошо

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2019-11-29 18:25 (ссылка)
у меня VIDEO_CARDS="nvidia"
но он все равно тянет LLVM,
думаю, из-за гле, галлиума или
какой-то такой же хуйни

аби у меня, естественно, x86_64

(Ответить) (Уровень выше)


[info]tiphareth
2019-11-28 20:53 (ссылка)

кстати, ты прав
похоже, что если отключить gallium,
меса не будет требовать llvm
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/38705-is-llvm-strictly-required-for-building-mesa-gallium-radeon

но есть риск, что wine тогда полетит,
или поддержка opengl

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2019-11-28 21:11 (ссылка)
а зачем вам wine?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2019-11-28 21:14 (ссылка)
для игр в основном

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2019-11-28 23:46 (ссылка)
какой вы хороший

(Ответить) (Уровень выше)


[info]id0
2019-11-29 05:05 (ссылка)
хоть я и пользуюсь ноумультилиб профилем,
вайн работал до этого момента без галлиума.
и на интеле, и на невидии где ириска, думается, этот галлиум,
как я помню, нужен строго для радеона. так что всё будет хорошо.
попробуй пересобрать без галлиума и ллвм, проверь вайн и опенгл
(можешь взять к8вавум из моей репки, например https://repo.or.cz/idgentoo.git там пока немного срач. планирую туда добавить ещё
уркванмастеров и вангеров + всякий саклесс софт и на дишечке что напишется.
пока что не подписывал коммиты, да.
ну или что-то своё можешь поставить и запустить, откатить юзфлаг ведь
для одной мезы легко. но у меня на двух машинах работало.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2019-11-29 12:50 (ссылка)
спасибо, ага
но мне удалось llvm откомпилировать в результате,
через NINJAOPTS="j1"
она поднялась ок

(Ответить) (Уровень выше)


[info]sometimes
2019-11-28 22:05 (ссылка)
Интересно, на самом деле, действительно ли clang и gcc так разошлись уже совсем, как в море корабли. А расскажите, как gentoo бутстрапится - ставится общий бинарный компилятор под платформу, и это безальтернативно gcc?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]perfect_kiss
2019-11-29 00:53 (ссылка)
https://pagure.io/fesco/issue/2020

шланг это эмулятор компилятора (типа как хром эмулятор браузера)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-29 13:40 (ссылка)
Не совсем понял ваш point. clang был написан, потому что код gcc запутался, и в нем невозможно было писать средства анализа кода. clang написан намного более внятно, его можно использовать как сервер для редакторов и даже есть cling. llvm - это, с моей точки зрения, очень полезная технология, хотя и жалко, конечно, что её возникновение простимулировал apple.
Новое, тем не менее, должно периодически сносить старое, иначе все окаменеет в legacy и кругом будет сплошной cobol.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2019-11-29 15:07 (ссылка)
>Новое, тем не менее, должно периодически сносить старое

как что-то хорошее

>все окаменеет в legacy и кругом будет сплошной cobol.

как что-то плохое

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-29 17:56 (ссылка)
Я не очень умею в этику, но это, несомненно, закрывает
возможности развития.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2019-11-30 10:58 (ссылка)
новое можно делать, не снося старое.
легаси востребовано, хорошо работает и приносит много пользы.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-30 13:53 (ссылка)
Да, но на нем продолжают разрабатывать и допиливать.
И это кошмарная потеря человеческих ресурсов.
Один null и include в C++ чего стоят.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2019-11-30 14:43 (ссылка)
это уже как в анекдоте: пессимист считает, что все женщины продажны. а оптимист как раз на это и рассчитывает!

(Ответить) (Уровень выше)


[info]perfect_kiss
2019-11-29 18:49 (ссылка)
Там по ссылке обсуждение от команды Федоры; им предложили перейти на сборку Фаерфокса через Clang, но в процессе обсуждения выяснилось, что в Clang либо не имплементированы разнообразные опции безопасности (тот же -fortify-source), либо же флаги есть, но они ничего не делают.

По итогу, хакинг жабоскрипом такого собранного Clang фаерфокса, в разы проще чем собранного GCC. У меня-то жабоскрип отключен, но далеко не у всех юзеров Fedora оно так. От перехода на Clang для сборки фокса в итоге отказались.

А вот в убунту, насколько я помню, уже довольно долго фокс собирают как раз Clang`ом.
Но у них там вообще алгоритмы шифрования специально понерфленные, не знаю кто может использовать убунту в 2019.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-29 22:41 (ссылка)
Интересно, чем собирают в арче.
Вообще это очень хорошо, прямо оживилось, типа, конкуренция (и буду знать).
Но со средствами статического анализа в C++ реально плохо, например, был gcc-xml, но он очень умер (именно по причине невозможности распутать gcc-код). О состоянии средств для суппорта IDE можно понять по тому, что практически все идешки чуть ли не до сих пор шлепаются и охреневают на коде буста, например. Это, конечно, не провал идешек, это заслуга C++, абсолютно безумный cancer language давно уже.
Ну и весь framework llvm очень интересный, я cling не зря упомянул, но там вообще дохрена всего, даже haskell компилируется в llvm (с ocaml, увы, все намного хуже). Ну и, опять же, интеграция llvm и webassembly.
Плюс код g++ начали распутывать, наконец, с появлением clang - а так бы и не почесались. Некоторая конкуренция нужна и при коммунизме, хотя, конечно, тут немного нечестненько, в clang небось намного больше бабла льется.
Если в итоге gcc убьют, будет плохо, clang превратится в gcc по качеству и с гораздо менее правильной лицензией.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]id0
2019-11-30 06:29 (ссылка)
>Интересно, чем собирают в арче.
смотря что, есть вероятность, что там gcc-only
за вычетом пары пакетов таких как хром, но, если рач под рукой,
то можно посмотреть это.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-30 14:03 (ссылка)
Посмотрел (не без труда, найти в поисковике не получилось
about:buildconfig).
clang там. С ключами компиляции, в частности,
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
как я понимаю, это не ключи компиляции, а определение макроса.
Кстати, произошло чудо - у меня google сломался -
не находит -fstack-protector-strong (yandex находит,
удивительно).

(Ответить) (Уровень выше)


[info]perfect_kiss
2019-11-29 18:51 (ссылка)
Да, как статический анализатор Clang куда лучше GCC, однако есть же огромное количество уже готовых анализаторов, пилить отдельный компилятор для того, чтобы починить анализ, это выглядит как кривление душой.

А на самом деле, подозреваю весь этот форс Clang и происходит для того, чтобы люди пользовались бинарями, собранными без опций безопасности, и гебнюкам было легче взламывать юзеров.

(Ответить) (Уровень выше)


[info]id0
2019-11-29 05:11 (ссылка)
можно шлангом собирать чуть ли не всё (всё но с кучей патчей, даже ядро)
https://blogs.gentoo.org/gsoc2016-native-clang/2016/07/24/a-new-gentoo-stage4-musl-clang/
короч было проделано много работы.
я пользовался и собирал с таким стеком:
нет гнутых утилит совсем (без бинутилс и прочего)
есть: либстд++, мусль, ллд, шланг последний (может что-то упустил)
закончил я этим польщоваться после того, как получил сегфолт в луне,
чинить мне это было откровенно лень и я смог подобрать флаги. что работают
тольео один раз.
бутстрапится в генте всё через гцц, раньше шланг требовал старый гцц
для сборки, примерно так: гцц6->clang(5 вроде) а дальше спокойно любой
шланг и ллвм. обещали к шлангу-х научить в нормальную сборку любой гцц,
но я не проверял.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-29 18:07 (ссылка)
clang 10 вроде только в проекте? Я сейчас живу на девятом,
у меня rolling release (manjaro).

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]id0
2019-11-29 19:34 (ссылка)
в моём контексте x != 10
это версия компиляора, которую я не помню.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-29 22:47 (ссылка)
А gentoo не поддерживает, кстати, удаленную и распределенную сборку?
У меня есть довольно мощный комп с 2990wx и 128G в пользовании, и было бы
радостно не компилировать на ноутбуке, ноутбук не для этого. Я, правда, и так
обычно работаю по ssh.

Я, правда, на nixos еще думал перебираться, там очень интересная система
пакетов (и он умеет в распределенную сборку, как говорят).

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]id0
2019-11-30 06:27 (ссылка)
есть решения: distcc (это сборка на нескольких машинах),
сборка пакетов на другой машине и использование бинарной репы
https://wiki.gentoo.org/wiki/Binary_package_guide
рачпределённая сборка (если это вариант дистцц -- говно),
скорее всего, она и в виде того, что у никсоси -- говно.
оч много ботленеков.
лучше собирать на серваке тогда уж и бин пакеты использовать.
я пробовал и никсось, и гуикс. гуикс мне понравился вот до этого
момента: http://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/
(считаю это ударом в спину (т.к. все начали массово писать про то как
РМС их "харасит") и использованием ресурса жму.орг в личных целях)
никсось это сисемуда и дсл, гуикс полноценный язык и можно творить что
угодно из сисемы, круче генты можно сделать. я хотел сделать подобие
на дишечке (тока круче, потому что там сейчас есть провалы в дезигне),
но я ленивое хууйло и робота. никсочь вроде позволяет в виртуалы и это
хорошо, но там не будет столь крутой кастомизации как в слаке или генте
(тебе придётся либо самому дохуя напилиить, либо сделать слаку/генту
(впрочем, это равномощно)) ну и никсось имеет ещё пару какашек,
но я про них забыл почти + системд во все поля, имхо, ненужно.
продумать нормальную систему виртуалов, провайдеров, парса конфига
и юз флага пока никто не осилил (может что забыл).

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]perfect_kiss
2019-11-30 12:36 (ссылка)
> http://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/

Ох лол.

Ну, ничего нового -- всевозможные кодеры и программисты это самая конформная часть общества вообще, такие как Столлман это исключение один на миллион.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]sometimes
2019-11-30 14:06 (ссылка)
Да, я видел этот отвратительный документ. Совсем у людей совести
не осталось. Вроде бы NixOS в таком не замазался. Вообще интересно,
а Linus как-нибудь отреагировал на этот скандал? Его в аналогичной
форме растоптали, только мягче (но зато более эффективно).

(Ответить) (Уровень выше)

(Читать комментарии) -