ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | В python3-base задаются заведомо неоптимальные флаги сборки | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Michael Shigorin <mike> | ||||||||||
| Component: | python3-base | Assignee: | Grigory Ustinov <grenka> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | aris, bircoph, george, glebfm, grenka, ilyakurdyukov, imz, lav, ldv, vitty | ||||||||||
| Version: | unstable | Keywords: | regression | ||||||||||
| Hardware: | all | ||||||||||||
| OS: | Linux | ||||||||||||
| See Also: | https://bugzilla.altlinux.org/show_bug.cgi?id=40291 | ||||||||||||
| Bug Depends on: | 39329 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Michael Shigorin
2021-06-24 14:34:05 MSK
Created attachment 9447 [details]
fannkuch.py
Прилагаю тест для проверки производительности из Benchmarks Game.
Собрано без hasher на x86_64:
./configure --with-computed-gotos=yes --enable-optimizations=no
$ time -p python3/python fannkuch.py 11
556355
Pfannkuchen(11) = 51
real 15.60
user 228.23
sys 0.10
$ time -p python3/python fannkuch.py 11
556355
Pfannkuchen(11) = 51
real 16.04
user 233.96
sys 0.17
./configure --with-computed-gotos=yes --enable-optimizations=yes
$ time -p python3/python fannkuch.py 11
556355
Pfannkuchen(11) = 51
real 14.25
user 206.53
sys 0.14
$ time -p python3/python fannkuch.py 11
556355
Pfannkuchen(11) = 51
real 14.13
user 204.83
sys 0.17
Видим +10% к производительности профилирования.
На Эльбрусе в разы быстрее с отключением computed-gotos (проблема компилятора):
./configure --with-computed-gotos=yes
$ time -p python3/python fannkuch.py 9
8629
Pfannkuchen(9) = 30
real 3.65
user 25.89
sys 0.11
./configure --with-computed-gotos=no
$ time -p python3/python fannkuch.py 9
8629
Pfannkuchen(9) = 30
real 1.08
user 5.58
sys 0.10
--enable-optimizations=yes на Эльбрусе пока невозможно, нужно делать какие-то хаки для компилятора, потому что сбор профиля падает с ошибкой.
И еще нашел две проблемы:
1) --with-valgrind никогда не срабатывает:
%if 0%{?with_valgrind}
--with-valgrind \
%endif
Потому что должно быть {?_with_valgrind} (с почерком), а лучше заменить на %{subst_with valgrind}
2) Должно собираться shared и static, но на самом деле оба раза собирается shared?
build() {
#see ALT39329
%remove_optflags -g -O3
%configure \
--with-platlibdir=%{_lib} \
--enable-ipv6 \
--enable-shared \
...
pushd ../build-shared
build --enable-shared
popd
(Ответ для ilyakurdyukov на комментарий #2) > И еще нашел две проблемы: Новые проблемы, не связанные с темой бага, лучше вешать новыми багами, чтобы каждый баг имел чёткий критерий, по которому он (не) решён. За тест спасибо :-) Да, по поводу valgrind и shared хотел разобраться, но руки не дошли. Спасибо. Оформите отдельные баги, если не сложно, как указал mike@ чуть выше. Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи мало кого интересуют. (Ответ для Grigory Ustinov на комментарий #4) ... > Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и > ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи > мало кого интересуют. Возможно, в изменения по bug 39329 вкралась ошибка, и действительно в сборке участвует -O2 вне зависимости от указанного в %optflags. Мы на gcc это можем не замечать, а вот на Эльбрусе заметили, потому что у них -O3 в %optflags. Если получится убрать прибитый -O2 в пользу %optflags, было бы здорово. valgrind и дублированную shared сборку исправили, теперь что с этой опцией ставящей -O2?
Во первых и сама сборка проекта ставит -O3, и даже -O3 был явно задан в пакете:
> PS: -O3 гвоздиком же прибил vitty@ в 3.2.2-alt4:
Что игнорируется патчем. Я считаю что патч нужно откатить совсем, а не гнаться за непонятной красотой в логах. Мало того, этот патч еще отключал отладочную информацию (-g).
Что я могу сам сделать, вместе с включением --enable-optimizations, и доработками для Эльбруса.
Я не понимаю, что от меня хотят. На нормальной архитектуре разница между O2 и O3 не заметна. То есть мне бы хотелось понимать, что нужно сделать: а. откатить все изменения по поводу флагов полностью б. оставить как есть в. сделать что-то промежуточное Предлагаю удалить эти строки из спека: 189 # remove -g and replace -O3 by -O2 in configure.ac 190 # see ALT39329 191 Patch1014: python3-fix-optflags.patch ... 387 %patch1014 -p2 ... 414 #see ALT39329 415 %remove_optflags -g -O3 И, соответственно, файл "python3-fix-optflags.patch". Могу сам это сделать, если вы со мной согласны, что от этого патча как минимум реальной пользы нет (а некоторым и вредит). P.S.: Тем не менее, хотя вы утверждаете что разницы между -O2 и -O3 большинстве архитектур нет, заметил что в libjpeg-turbo, например, тоже ставится -O3 после CFLAGS от пользователя или приходящих по умолчанию от cmake. Принято. Изменения на ревью: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git А мне еще проверить надо, что в новой версии всё работает (завершу уже завтра). Во-первых, +%ifarch %e2k +# times faster without it on e2k +%global with_computed_gotos no +%else %global with_computed_gotos yes +%endif можно было бы заменить на +%ifnarch %e2k %global with_computed_gotos yes +%endif Так проще и красивее. Во-вторых, чем вам не угодил Patch1013? Он в разы легче для восприятия, чем непонятная абракодабра в сед-выражении. Не говоря уже о том, что если что-то изменится, то патч свалится и его можно будет поймать, а сед просто пропустит мимо. Если это попытка показать ваше умение пользоваться регулярными выражениями, то "принято", а так, подобная вереница регулярок автоматически подписывает вас на решение любых проблем с питоном на эльбрусе. 3. Коммит 0b89b03 можно было бы просто сделать через git revert 4. Коммит 61fc581 было бы неплохо разделить на несколько. Как минимум на 2. Вот в одном мы заменяем патч сед выражением, а в другом творим адскую, практически никак не прокомментированную дичь. Понимаю, что для вас оно очевидно, а для других людей не очень. Так что хотелось бы увидеть хотя бы в описании коммита какие-нибудь комментарии по поводу того, что там происходит и зачем. 5. Ну и наконец, у нас существует система автозакрытия багов. Можно написать в ченджлоге (Closes: #40278) и этот баг закроется после того, как таск закоммитится. Created attachment 9459 [details]
python3.8.1-e2k-plus10.patch
Created attachment 9460 [details] python3.9.5-e2k-plus10.patch Как это... +%ifnarch %e2k %global with_computed_gotos yes +%endif Может работать с этим? --with-computed-gotos=%with_computed_gotos \ Чтобы подавалось "--with-computed-gotos=", что это будет значить? > Во-вторых, чем вам не угодил Patch1013? Он в разы легче для восприятия, чем непонятная абракодабра в сед-выражении. То что заменяет этот патч - понятно. Остальное непонятное - сделано так по той причине, что мелкие правки от разработчиков питона будут часто ломать патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при добавлении или удалении любого нового опкода в интерпретаторе - патч нужно будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы добавить патч для Эльбруса в сизиф. Я приложил вам пример патчей, которые бы пришлось постоянно обновлять. sed выражения фактически делают то же самое, только менее красиво, зато автоматически. (Ответ для ilyakurdyukov на комментарий #13) > То что заменяет этот патч - понятно. Остальное непонятное - сделано так по > той причине, что мелкие правки от разработчиков питона будут часто ломать > патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при > добавлении или удалении любого нового опкода в интерпретаторе - патч нужно > будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что > удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы > добавить патч для Эльбруса в сизиф. Еще можно оформить этот набор sed-awk выражений в отдельный скрипт и использовать для генерации нового патча, когда текущий отвалится. (Ответ для ilyakurdyukov на комментарий #13) > Создано вложение 9460 [details] [подробности] > python3.9.5-e2k-plus10.patch > > Как это... > > +%ifnarch %e2k > %global with_computed_gotos yes > +%endif > > Может работать с этим? Никак. Я погорячился и ошибся. Эта опция по умолчанию yes. Так что, вероятно, сработало бы обратное. > > --with-computed-gotos=%with_computed_gotos \ > > Чтобы подавалось "--with-computed-gotos=", что это будет значить? > > > Во-вторых, чем вам не угодил Patch1013? Он в разы легче для восприятия, чем непонятная абракодабра в сед-выражении. > > То что заменяет этот патч - понятно. Остальное непонятное - сделано так по > той причине, что мелкие правки от разработчиков питона будут часто ломать > патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при > добавлении или удалении любого нового опкода в интерпретаторе - патч нужно > будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что > удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы > добавить патч для Эльбруса в сизиф. Хорошо, если вы готовы за этим следить. И всё же было бы неплохо хоть чуть-чуть прокомментировать, что там происходит, на случай если стороннему человеку случайно придётся это поддержать. > > Я приложил вам пример патчей, которые бы пришлось постоянно обновлять. sed > выражения фактически делают то же самое, только менее красиво, зато > автоматически. Холивар "патчи против регулярок" длится уже давно, я не хочу в нём участвовать. Если хочется сделать красиво, то можно сделать так:
%configure \
--with-platlibdir=%{_lib} \
--enable-ipv6 \
--enable-shared \
--enable-optimizations \
%ifarch %e2k
--with-computed-gotos=no \
%endif
...
Но придётся еще писать комментарий чтобы это никто не сломал.
Потому что, стороннему наблюдателю обязательно покажется, что так:
%ifnarch %e2k
--with-computed-gotos \
%endif
...было бы логичнее и красивее, и исправит не зная как эта опция работает.
--with-computed-gotos enable computed gotos in evaluation loop (enabled by
default on supported compilers)
То есть включается она по умолчанию для тех компиляторов, которые смогли скомпилировать тест с этой фичей. Значит считается что фича поддерживается и даст ускорение. Фича называется Labels as Values, которая не является стандартом, а расширение GNU компиляторов.
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
Проблема компилятора для Эльбруса, что она работает, но работает очень медленно. Чтобы её сделать быстрой - говорят что нужны сложные изменения в компиляторе. Фича же используется крайне редко, это второй раз как я вижу её использование. Первый раз видел в OpenJDK Zero, это интерпретатор Java. Соответственно, оптимизацию редкой фичи откладывают.
Поэтому этот sed - awk патч подводит компилятор к тому, чтобы он сгенерировал правильный код не используя Labels as Values, но используя обычный switch.
Для этого требуется указать что default: метка в switch никогда не вызывается (unreachable), и тогда компилятор уберёт проверки диапазона значений перед прыжком по таблице меток.
#if USE_COMPUTED_GOTOS
_unknown_opcode:
#endif
default:
fprintf(stderr,
"XXX lineno: %d, opcode: %d\n",
PyFrame_GetLineNumber(f),
opcode);
_PyErr_SetString(tstate, PyExc_SystemError, "unknown opcode");
goto error;
Но это вызывает неопределённое поведение, если когда-либо попадутся опкоды, не указанные в case-ах switch. Возможные же значения опкодов находятся в пределах байта. Поэтому нужно найти все номера кейсов в диапазоне 0-255, котоыре НЕ были использованы.
Что могло бы быть сложной задачей, но к счастью, для использования Labels as Values вручную создаётся таблица прыжков, которая находится в файле opcode_targets.h, и выглядит так:
static void *opcode_targets[256] = {
&&_unknown_opcode, <--- case 0
&&TARGET_POP_TOP, <--- case 1
&&TARGET_ROT_TWO, <--- case 2
&&TARGET_ROT_THREE, <--- case 3
&&TARGET_DUP_TOP, <--- case 4
&&TARGET_DUP_TOP_TWO, <--- case 5
&&TARGET_ROT_FOUR, <--- case 6
&&_unknown_opcode, <--- case 7
&&_unknown_opcode,
&&TARGET_NOP,
&&TARGET_UNARY_POSITIVE,
&&TARGET_UNARY_NEGATIVE,
...
&&_unknown_opcode,
&&_unknown_opcode,
&&_unknown_opcode, <--- case 254
&&_unknown_opcode <--- case 255
};
Что позволяет сгенерировать эти кейсы простым awk скриптом:
awk '/_unknown_opcode/{print "case " NR-2 ":"}' Python/opcode_targets.h > Python/opcode_unknown.h
Как мы видим, первый _unknown_opcode соответствует первой позиции в таблице, что находится на второй строке.
Для него скрипт выдаст: "case 0:\n", cледующим будет "case 7:\n".
Если первый опкод окажется не на второй строке или стройный порядок перечисления опкодов изменится, то произойдёт ошибка при компиляции, так как unknown кейсы совпадут с номерами существующих.
А далее лишь нужно вставить этот список после default: в switch интерпретатора, что делает этот код:
sed -i "/_unknown_opcode:/{n;n;s|$|Py_UNREACHABLE();\n#include \"opcode_unknown.h\"|}" Python/ceval.c
Py_UNREACHABLE() это обёртка над __builtin_unreachable().
Поиск нужного места ведётся по "_unknown_opcode:" что встречается за две строки перед нужным "default:", так как default встречается в исходнике четыре раза, а _unknown_opcode упоминается лишь один раз.
Это нужно чтобы найти начало switch интерпретатора и добавить себе метку для прыжка на него:
sed -i "/switch (opcode) {/{s|^|switch_loop:|;:a;n;ba}" Python/ceval.c
Эта замена:
sed -i "s|\\*opcode_targets\\[opcode\\]|switch_loop|" Python/ceval.c
Далее нужно сделать из макросов, использующих Labels as Values, макросы делающие практически то же самое, но с прыжком на начало switch, вместо таблицы меток:
#if USE_COMPUTED_GOTOS
/* Import the static jump table */
#include "opcode_targets.h"
#define TARGET(op) \
op: \
TARGET_##op
#ifdef LLTRACE
#define FAST_DISPATCH() \
{ \
if (!lltrace && !_Py_TracingPossible(ceval2) && !PyDTrace_LINE_ENABLED()) { \
f->f_lasti = INSTR_OFFSET(); \
NEXTOPARG(); \
goto *opcode_targets[opcode]; \
} \
goto fast_next_opcode; \
}
#else
#define FAST_DISPATCH() \
{ \
if (!_Py_TracingPossible(ceval2) && !PyDTrace_LINE_ENABLED()) { \
f->f_lasti = INSTR_OFFSET(); \
NEXTOPARG(); \
goto *opcode_targets[opcode]; \
} \
goto fast_next_opcode; \
}
#endif
#define DISPATCH() \
{ \
if (!_Py_atomic_load_relaxed(eval_breaker)) { \
FAST_DISPATCH(); \
} \
continue; \
}
#else
#define TARGET(op) op
#define FAST_DISPATCH() goto fast_next_opcode
#define DISPATCH() continue
#endif
В коде выше нужно принудительно пойти по пути #if USE_COMPUTED_GOTOS, так как нам нужно позаимствовать оттуда определения макросов FAST_DISPATCH и DISPATCH. Но нужно удалить инклуд "opcode_targets.h", заменить макрос "TARGET(op) op: TARGET_##op", на простой "TARGET(op) op" и заменить "goto *opcode_targets[opcode];" на "goto switch_loop;" (switch_loop который ставится перед switch интерпретатора другим sed вызовом).
Удаление opcode_targets.h и старого TARGET(op) делается пропуском от первого #if USE_COMPUTED_GOTOS, до того как будет найдено упоминание LLTRACE.
#if USE_COMPUTED_GOTOS встречается в исходнике не один раз, поэтому после нахождения и изменения первого #if USE_COMPUTED_GOTOS - sed скрипт далее пропускает все строки, ничего не делая.
Всё это делается этим вызовом sed:
sed -i "/#if USE_COMPUTED_GOTOS/{:b;g;N;/LLTRACE/!bb;s|^|#undef USE_COMPUTED_GOTOS\n#define USE_COMPUTED_GOTOS 0\n#if 1\n#define TARGET(op) op|;:a;n;ba}" Python/ceval.c
Да, еще USE_COMPUTED_GOTOS присваивается 0, так что по идее с этим патчем "--with-computed-gotos=no" больше не нужно, но лучше передавать всё равно, на случай если кто-то захочет проверить разницу вносимую sed - awk пачтем, сейчас это +10% к производительности.
Вы думаете, что всё это должно быть написано в комментариях в спеке? Для любопытных я могу оставить номер бага.
P.S.: Это притом, что чтобы это понять нужно еще и знать почему Labels as Values (если грамотно реализовано) быстрее обычного switch. Для чего вероятно, нужно знать в какой ассемблер компилятор превращает то и другое.
TL;DR версия: Обычно switch превращается компилятором в такую конструкцию: if (x < first_case | x > last_case) goto default; goto *labels[x - first_case]; sed - awk патч убирает первую строку с проверкой диапазона. Сохраняя при этом обработку default: для неизвестных значений опкодов в пределах 0-255, а больше никакие другие значения прийти не могут. Сделано это без использования фичи Labels as Values, медленной в исполнении компилятора для Эльбруса. --with-computed-gotos - делает именно это, но с использованием Labels as Values. > Вы думаете, что всё это должно быть написано в комментариях в спеке? Для любопытных я могу оставить номер бага.
Да, пожалуй.
Выглядит оно мощно!
Обновил: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git > можно было бы просто сделать через git revert git revert не справился, потому что рядом были изменения. Так что сделал вручную, благо правки небольшие. (Ответ для ilyakurdyukov на комментарий #16) > Если хочется сделать красиво, то можно сделать так: > > %configure \ > --with-platlibdir=%{_lib} \ > --enable-ipv6 \ > --enable-shared \ > --enable-optimizations \ > %ifarch %e2k > --with-computed-gotos=no \ > %endif > ... > > Но придётся еще писать комментарий чтобы это никто не сломал. > Потому что, стороннему наблюдателю обязательно покажется, что так: > > %ifnarch %e2k > --with-computed-gotos \ > %endif > > ...было бы логичнее и красивее, и исправит не зная как эта опция работает. > > --with-computed-gotos enable computed gotos in evaluation loop (enabled > by > default on supported compilers) > > То есть включается она по умолчанию для тех компиляторов, которые смогли > скомпилировать тест с этой фичей. Значит считается что фича поддерживается и > даст ускорение. Фича называется Labels as Values, которая не является > стандартом, а расширение GNU компиляторов. > > https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html > > Проблема компилятора для Эльбруса, что она работает, но работает очень > медленно. Чтобы её сделать быстрой - говорят что нужны сложные изменения в А не правильнее было бы сделать так, чтобы компилятор Эльбруса перестал быть supported compiler для этой фичи? Таки почему-то локальная static x86_64 сборка предыдущей версии у меня выходит заметно быстрее сборки из hasher:
$ LD_LIBRARY_PATH=$TMP/chroot/usr/src/tmp/python3-buildroot/usr/lib64/ time -p $TMP/chroot/usr/src/tmp/python3-buildroot/usr/bin/python3 fannkuch.py 11 4
556355
Pfannkuchen(11) = 51
real 33.31
user 130.37
sys 0.05
$ time -p python3/python fannkuch.py 11 4
556355
Pfannkuchen(11) = 51
real 27.85
user 108.16
sys 0.05
Может shared сборка медленнее чем static? Или из-за каких-то флагов?
> А не правильнее было бы сделать так, чтобы компилятор Эльбруса
> перестал быть supported compiler для этой фичи?
Там нет списка поддерживаемых компиляторов, просто проверяют что следующий код скомпилируется:
int main(int argc, char **argv)
{
static void *targets[1] = { &&LABEL1 };
goto LABEL2;
LABEL1:
return 0;
LABEL2:
goto *targets[0];
return 1;
}
Если скомпилировался - значит поддерживается. Но LCC всё равно притворяется GCC 7.3.0 так что и список бы не помог.
Created attachment 9464 [details] fannkuch.py Прилагаю новую версию fannkuch.py, которым я тестирую производительность, добавил параметр с количеством потоков, так как он использовал по количеству процессоров, что даёт больше погрешности. Я выяснил что вот этот патч ломает static билд: # 00111 # # Patch the Makefile.pre.in so that the generated Makefile doesn't try to build # a libpythonMAJOR.MINOR.a # See https://bugzilla.redhat.com/show_bug.cgi?id=556092 # Downstream only: not appropriate for upstream Patch111: 00111-no-static-lib.patch Ошибка такая: make[3]: *** No rule to make target 'libpython3.9.a', needed by 'python'. Stop. Зачём это нужно, мне не ясно. Я в оптимизациях разбираюсь, а не в таких тонкостях что статическая библиотека кому-то помешала. > https://bugzilla.redhat.com/show_bug.cgi?id=556092 > We could change things to not build it, or we could simply delete it after linking: I've chosen to patch the Makefile.pre.in to not build it. Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, чем годами поддерживать этот патч. Который еще и static билд ломает, а значит вредительский. Различия же в производительности static билда очень ощутимые (на 25% быстрее). Почему так происходит - я не знаю. Но я думаю, что ради этого стоит откатить патч из Федоры, его необходимость для меня сомнительна. Возможно патч сломался после каких-то изменений в питоне. # hasher shared (./configure --enable-shared --enable-optimizations --with-valgrind) $ LD_LIBRARY_PATH=$TMP/chroot/usr/src/tmp/python3-buildroot/usr/lib64/ time -p nice $TMP/chroot/usr/src/tmp/python3-buildroot/usr/bin/python3 fannkuch.py 11 4 556355 Pfannkuchen(11) = 51 real 32.81 user 127.51 sys 0.06 # hasher static (./configure --enable-optimizations --with-valgrind) $ LD_LIBRARY_PATH=$TMP/chroot/usr/src/tmp/python3-buildroot/usr/lib64/ time -p nice $TMP/chroot/usr/src/tmp/python3-buildroot/usr/bin/python3 fannkuch.py 11 4 556355 Pfannkuchen(11) = 51 real 26.29 user 102.55 sys 0.06 (Ответ для ilyakurdyukov на комментарий #22) > Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, чем > годами поддерживать этот патч. Который еще и static билд ломает, а значит > вредительский. Гораздо проще ничего не менять, если никому не мешает=) Золотое правило мастера "не чини то, что работает". > > Различия же в производительности static билда очень ощутимые (на 25% > быстрее). Почему так происходит - я не знаю. Но я думаю, что ради этого > стоит откатить патч из Федоры, его необходимость для меня сомнительна. > Возможно патч сломался после каких-то изменений в питоне. Предлагаю подобные отдельные ветви обсуждений выносить в отдельные баги, чтобы не потерялось и чтобы не путаться в обсуждениях. Итак, вот коммиты, которыми я вроде бы починил все найденные проблемы с производительностью: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git Еще у меня есть подозрения что --with-valgrind может негативно влиять, но видимо эта разница небольшая, я проверяю на basalt, которая еще и как шлюз используется и на ней есть небольшая фоновая нагрузка. Но разница между static и shared точно вызвана не флуктуациями загрузки, так как очень значительная. Требуются тестеры для сравнения 3.9.6-alt1 и этого кандидата в 3.9.6-alt2. Можете использовать приложенный к багу fannkuch.py и другие вычислительные тесты, что найдёте. Посоветовали: https://src.fedoraproject.org/rpms/python3/pull-request/151 > The compiler flag has been added to CFLAGS_NODIST and > LDFLAGS_NODIST. This will compile the core interpreter > and the stdlib modules with -fno-semantic-interposition > but will not affect user build and rpm C extension modules > compiled by distutils. > This has the effect of speeding up the interpreter up to > 27%, depending on the workload, with the drawback of disabling > the capability of using LD_PRELOAD to override symbols in > libpython. > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup Собирал в убунте, тоже static быстрее, но на 10%. Причём системный питон работает много быстрее - вот у кого спеки смотреть надо. $ time -p python3 fannkuch.py 11 2 shared: 73.56 static: 66.59 system: 56,71 Вчера проверял, но вне hasher: export CFLAGS_NODIST="-fno-semantic-interposition" export LDFLAGS_NODIST="-fno-semantic-interposition" Перед configure - делает shared билд почти таким же быстрым как static. Почти потому, что на 3% у меня вышло медленнее, непонятно, наводка ли это от системных процессов или действительно медленнее. На Эльбрусе же такая опция не поддерживается. Так что, если хотите shared билд - могу сделать для Эльбруса static, для всех остальных с этой опцией. (In reply to ilyakurdyukov from comment #26) > Вчера проверял, но вне hasher: > > export CFLAGS_NODIST="-fno-semantic-interposition" > export LDFLAGS_NODIST="-fno-semantic-interposition" > > Перед configure - делает shared билд почти таким же быстрым как static. > Почти потому, что на 3% у меня вышло медленнее, непонятно, наводка ли это от > системных процессов или действительно медленнее. > > На Эльбрусе же такая опция не поддерживается. > > Так что, если хотите shared билд - могу сделать для Эльбруса static, для > всех остальных с этой опцией. А разве кто-то специально хочет shared build интерпретатора? Изначально он делался vitty@ static из-за скорости, и по большому счёту к этому у нас пакеты и инфраструктура были подготовлены. С т.зр. тестированности лучше, когда более похожи пакеты на разных платформах. (Т.е. везде static, например.) На x86_64 замедление shared build должно быть не так заметно, как на архитектурах с меньшим количеством регистров (или где их много требуется задействовать для вызовов функций следуя ABI), т.е. например, i586. (Ну, это такие теоретические соображения.) Согласен, что патч, от которого нет особый пользы, и который можно просто заменить rm, лучше не тащить, потому что с ним больше труда для мейнтейнера. (In reply to Vitaly Lipatov from comment #20) > (Ответ для ilyakurdyukov на комментарий #16) > > Если хочется сделать красиво, то можно сделать так: > > > > %configure \ > > --with-platlibdir=%{_lib} \ > > --enable-ipv6 \ > > --enable-shared \ > > --enable-optimizations \ > > %ifarch %e2k > > --with-computed-gotos=no \ > > %endif > > ... > > > > Но придётся еще писать комментарий чтобы это никто не сломал. > > Потому что, стороннему наблюдателю обязательно покажется, что так: > > > > %ifnarch %e2k > > --with-computed-gotos \ > > %endif > > > > ...было бы логичнее и красивее, и исправит не зная как эта опция работает. > > > > --with-computed-gotos enable computed gotos in evaluation loop (enabled > > by > > default on supported compilers) > > > > То есть включается она по умолчанию для тех компиляторов, которые смогли > > скомпилировать тест с этой фичей. Значит считается что фича поддерживается и > > даст ускорение. Фича называется Labels as Values, которая не является > > стандартом, а расширение GNU компиляторов. > > > > https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html > > > > Проблема компилятора для Эльбруса, что она работает, но работает очень > > медленно. Чтобы её сделать быстрой - говорят что нужны сложные изменения в > А не правильнее было бы сделать так, чтобы компилятор Эльбруса перестал быть > supported compiler для этой фичи? Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.) > На x86_64 замедление shared build должно быть не так заметно, как на архитектурах с меньшим количеством регистров +25% разница на вычислениях в питоне как раз на x86_64. А на Эльбрусе с 256 регистрами и еще выше. Насколько я понял, какие-то правила экспортирования символов в библиотеках мешают оптимизациям, и эта опция говорит компилятору что можно делать некоторые оптимизации. А ломает это только на то, что пользователь не сможет делать LD_PRELOAD хаки, когда можно подгрузить свою либу, которая имеет те же имена функций, что имена функций из libpython, и подменяет их. > For a non-vague-linkage function definition, by default (-fsemantic-interposition) the -fpic > mode does not allow a call site in the same translation unit to inline the callee or perform > other interprocedural optimizations. -fno-semantic-interposition re-enables interprocedural > optimizations. > If a caller inlines a callee, using LD_PRELOAD to interpose the callee will not affect the caller. > But many other LD_PRELOAD usage still work. We consider the small LD_PRELOAD limitation a good > trade off for the speedup. > А разве кто-то специально хочет shared build интерпретатора? В Федоре похоже принципиальная позиция, что они всё делают только shared. В Убунту же явно статик. > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.) Пока широкой розничной доступности не будет - это проблема. Потому что зарубежному апстриму негде взять железо для проверки патчей. (In reply to ilyakurdyukov from comment #29) > > На x86_64 замедление shared build должно быть не так заметно, как на архитектурах с меньшим количеством регистров > +25% разница на вычислениях в питоне как раз на x86_64. А на Эльбрусе с 256 > регистрами и еще выше. Насколько я понял, какие-то правила экспортирования > символов в библиотеках мешают оптимизациям, и эта опция говорит компилятору > что можно делать некоторые оптимизации. А ломает это только на то, что > пользователь не сможет делать LD_PRELOAD хаки, когда можно подгрузить свою > либу, которая имеет те же имена функций, что имена функций из libpython, и > подменяет их. > > > For a non-vague-linkage function definition, by default (-fsemantic-interposition) the -fpic > > mode does not allow a call site in the same translation unit to inline the callee or perform > > other interprocedural optimizations. -fno-semantic-interposition re-enables interprocedural > > optimizations. > > If a caller inlines a callee, using LD_PRELOAD to interpose the callee will not affect the caller. > > But many other LD_PRELOAD usage still work. We consider the small LD_PRELOAD limitation a good > > trade off for the speedup. Я имел в виду, что помимо этого обнаруженного на x86_64 фактора вероятно есть другие, которые могут иметь эффект только на i586 и т.п. (Если разница без -fno-semantic-interposition обнаружилась на x86_64 и она "лечится" этой опцией, это не значит, что нет разницы в скорости на i586 независимо от наличия этого флага.) (In reply to ilyakurdyukov from comment #29) > > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.) > Пока широкой розничной доступности не будет - это проблема. Потому что > зарубежному апстриму негде взять железо для проверки патчей. Но патч без кода, а просто делающий выбор опций в зависимости от моедли компилятора могут и принять без тестирования. Есть подобные (и не совсем) патчи ради компиляции на e2k, принятые в другие upstream-ы. Для понимания что такое -fno-semantic-interposition (я полагаю может пригодиться в других проектах):
Эта опция отменяет ограничения на межпроцедурную оптимизацию введенные -fPIC.
Например у нас есть код:
int mul3(int x) { return x * 3; }
int mul9(int x) { return mul3(mul3(x)); }
Где компилятор, которому указано -fPIC, не может заинлайнить mul3() в mul9(), а делает два вызова mul3 даже зная что такую простую функцию можно заинлайнить, заменив вызовы на return x * 9;
Если же указать -fno-semantic-interposition, то это будет сделано.
Соответственно, если mul3 заинлайнен в mul9, то LD_PRELOAD библиотеки которая экспортирует int mul3(int x) { return x * 4; } не заставит mul9() умножать на 16.
Попросил МЦСТ чтобы добавили такую опцию.
Хорошо бы не затягивать с исправлением производительности. Чтобы в p10 ушла быстрая версия. Такое уже бывало? На других архитектурах не было ошибки. [armh] 1 test failed: [armh] test_hashlib [armh] 22 tests skipped: [armh] test_curses test_devpoll test_gdb test_ioctl test_kqueue [armh] test_msilib test_nis test_ossaudiodev test_smtpnet [armh] test_socketserver test_startfile test_timeout test_tix test_tk [armh] test_ttk_guionly test_urllib2net test_urllibnet test_winconsoleio [armh] test_winreg test_winsound test_xmlrpc_net test_zipfile64 [armh] Total duration: 2 min 39 sec [armh] Tests result: FAILURE http://git.altlinux.org/tasks/276715/build/100/armh/log [00:43:17] 0:00:02 load avg: 3.79 [137/424/1] test_hashlib crashed (Exit code -7) (Ответ для ilyakurdyukov на комментарий #33) > Хорошо бы не затягивать с исправлением производительности. Чтобы в p10 ушла > быстрая версия. > > Такое уже бывало? На других архитектурах не было ошибки. Нет, это что-то новенькое. Отключил PGO для armh, теперь собралось везде. http://git.altlinux.org/tasks/276773/logs/events.1.1.log Падение на том тесте не случайное, повторно воспроизводилось. Видимо компилятор переоптимизировал, возможно баг компилятора. (In reply to ilyakurdyukov from comment #35) > Отключил PGO для armh, теперь собралось везде. > > http://git.altlinux.org/tasks/276773/logs/events.1.1.log > > Падение на том тесте не случайное, повторно воспроизводилось. Видимо > компилятор переоптимизировал, возможно баг компилятора. Спасибо за всю эту работу! Теперь, когда интерпретатор собран статически, часть пакетов (возможно) ошибочно динамически линкует модули с libpython3.9.so.1.0. (Речь идёт именно о модулях, а не программах, которые используют python как встроенный интерпретатор. Какие в этом списке какие -- предстоит разобраться, чтобы вернуть всё как было раньше, когда интерпретатор в ALT собирался всё ещё статически.) [imz@altair ~]$ cat ~/hasher/aptbox/etc/apt/sources.list rpm-dir file:/tmp/.private/imz/hasher/repo x86_64 hasher rpm [alt] file:/ALT/Sisyphus x86_64 classic debuginfo checkinstall rpm [alt] file:/ALT/Sisyphus noarch classic checkinstall rpm [alt] file:/ALT/Sisyphus x86_64-i586 classic [imz@altair ~]$ ~/hasher/aptbox/apt-cache whatdepends 'libpython3.9.so.1.0()(64bit)' <libpython3.9.so.1.0()(64bit)> weechat-plugin-python-3.0-alt1:sisyphus+274516.36400.2.1@1623665973 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-vtkaddon-0-alt1.git.402e7c6:sisyphus+273287.2200.5.3@1622762129 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-vtk-9.0.1-alt5:sisyphus+275609.100.2.1@1624610186 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libvtk9.0-python3-9.0.1-alt5:sisyphus+275609.100.2.1@1624610186 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libvtk9.0-9.0.1-alt5:sisyphus+275609.100.2.1@1624610186 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-vboxapi-6.1.22-alt1:sisyphus+271870.100.4.2@1621205089 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-enhanced-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-X11-neXtaw-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-X11-gtk2-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-X11-gnome2-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libvapoursynth-53-alt1:sisyphus+270454.100.1.1@1619068724 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 uwsgi-2.0.18-alt1:sisyphus+265234.21500.49.1@1613754902 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-uhd-3.15.0.0-alt6.1:sisyphus+273092.200.1.1@1622480604 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 syslog-ng-python3-3.32.1-alt1:sisyphus+274086.400.4.1@1623188981 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 sudo-python-1:1.9.7-alt1:sisyphus+271887.100.1.1@1621022852 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 slicer-4.11.20210226-alt1:sisyphus+276144.300.2.1@1624882290 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 scribus-1:1.5.7-alt1.1:sisyphus+274992.100.1.1@1624381968 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-samba-4.14.5-alt1:sisyphus+273560.100.2.1@1624188304 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-qpid-proton-0.28.0-alt1.1:sisyphus+273102.1600.4.1@1622494580 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 qgis3-python-3.18.3-alt1:sisyphus+272347.100.1.1@1621692091 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libpythonqt-0-alt1.git.dafdb72:sisyphus+273287.1700.5.3@1622761569 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-pynest2d-4.8-alt2:sisyphus+265234.42700.49.1@1613771698 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-gst1.0-1.18.4-alt1:sisyphus+267876.600.1.1@1615841302 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-cx-freeze-6.1-alt1:sisyphus+265234.33100.49.1@1613764407 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-caja-1.24.0-alt1:sisyphus+265234.42200.49.1@1613771272 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-shiboken2-5.15.0-alt4:sisyphus+265234.42720.50.1@1613896979 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-PySide2-5.15.0-alt4:sisyphus+265234.42720.50.1@1613896979 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-PyQt5-5.13.1-alt3:sisyphus+265234.43400.50.1@1613897523 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql9.6-python-9.6.22-alt1:sisyphus+274516.11400.1.1@1623618701 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql13-python-13.3-alt1:sisyphus+274516.4500.1.1@1623614512 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-1C-python-12.6-alt3:sisyphus+274516.11300.1.1@1623618431 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-1C-contrib-12.6-alt3:sisyphus+274516.11300.1.1@1623618431 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-python-12.7-alt1:sisyphus+274516.11100.1.1@1623617870 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-contrib-12.7-alt1:sisyphus+274516.11100.1.1@1623617870 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql11-python-11.12-alt1:sisyphus+274516.11000.1.1@1623617585 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql11-contrib-11.12-alt1:sisyphus+274516.11000.1.1@1623617585 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql10-python-10.17-alt2:sisyphus+274516.11200.1.1@1623618142 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql10-contrib-10.17-alt2:sisyphus+274516.11200.1.1@1623618142 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 pitivi-2021.05-alt1:sisyphus+272866.200.2.1@1622409755 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 perl-Inline-Python-0.56-alt1:sisyphus+274516.53400.2.1@1623671172 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-partio-1.14.0-alt1:sisyphus+274474.200.1.1@1623522713 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-libpamtest-1.1.3-alt1.1:sisyphus+269879.17400.53.1@1622285275 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-openshadinglanguage-1.11.14.1-alt1:sisyphus+274117.340.3.2@1623320459 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-openbabel-2.4.1-alt7:sisyphus+265234.27300.49.1@1613759478 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 obs-studio-base-27.0.1-alt2:sisyphus+276040.200.2.1@1624796313 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libobs-27.0.1-alt2:sisyphus+276040.200.2.1@1624796313 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-ngsolve-6.2.2103-alt1:sisyphus+274615.300.2.1@1623829837 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libngsolve-6.2.2103-alt1:sisyphus+274615.300.2.1@1623829837 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-netgen-6.2.2103-alt2:sisyphus+274615.100.1.1@1623772101 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libnetgen-6.2.2103-alt2:sisyphus+274615.100.1.1@1623772101 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 nemo-python-5.0.1-alt1:sisyphus+276160.600.2.1@1624999290 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 nautilus-python-1.2.3-alt2:sisyphus+265234.42600.49.1@1613771651 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 mysql-workbench-community-8.0.25-alt1:sisyphus+272319.1100.10.1@1622580477 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-log4cplus-2.0.6-alt1:sisyphus+274735.100.1.1@1624006201 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 perf-5.13-alt1:sisyphus+276445.300.3.1@1625013959 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-talloc-1:2.3.2-alt1:sisyphus+268191.100.8.1@1616984054 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libsigrokdecode-0.5.3-alt2:sisyphus+265234.30700.49.1@1613761948 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-savitar-4.8-alt1:sisyphus+265234.26500.49.1@1613758671 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libpeas-python3-loader-1.30.0-alt1:sisyphus+268501.3600.4.2@1617047300 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-openshot-0.2.5-alt3.1:sisyphus+271676.1240.3.1@1622401220 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-pyldb-2.3.0-alt1:sisyphus+268191.540.8.1@1616984229 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-libcomps-0.1.17-alt1_1:sisyphus+274849.100.1.1@1624274584 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-cec-6.0.2-alt1:sisyphus+265234.1200.49.1@1613743606 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-ldns-1.7.1-alt1.git.e99accb9:sisyphus+265234.25700.49.1@1613758136 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 krita-4.4.2-alt1:sisyphus+265234.50700.50.1@1613901027 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kodi-bin-19.1-alt1:sisyphus+274595.100.1.1@1623759880 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kmymoney-weboob-5.1.2-alt3:sisyphus+276737.100.2.1@1625221305 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kitty-0.21.2-alt1:sisyphus+276142.100.2.2@1624869903 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kicad-1:5.1.9-alt2.1:sisyphus+273312.200.3.2@1622570598 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kde5-kig-21.04.1-alt1:sisyphus+272539.1400.1.1@1622016524 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kde5-cantor-21.04.1-alt1:sisyphus+272539.1700.1.1@1622016867 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 hugin-2020.0.0-alt1:sisyphus+275077.100.1.2@1624412528 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libges-1.18.4-alt1:sisyphus+267876.1200.1.1@1615841595 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 gnuradio-3.9.1.0-alt1:sisyphus+271536.100.1.1@1620837010 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 gnumeric-1.12.50-alt1:sisyphus+274516.31500.2.1@1623663581 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libgladeui2.0-3.39.0-alt0.1:sisyphus+270761.100.1.1@1619503359 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 gdb-10.1-alt1:sisyphus+265234.500.49.1@1613741942 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 freecad-1:0.19.2-alt2:sisyphus+271619.1700.16.2@1621461369 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libfontforge-20201107-alt1:sisyphus+265234.31600.49.1@1613762820 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 ceph-mgr-15.2.13-alt1:sisyphus+276363.100.1.3@1625001559 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 calibre-4.23.0-alt3:sisyphus+276534.20.4.3@1625176475 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 blender-2.93.1-alt1:sisyphus+276143.100.2.2@1624885452 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 apache2-mod_wsgi-py3-4.8.0-alt1:sisyphus+272442.100.1.1@1621930032 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 adonthell-0.3.6-alt1_9:sisyphus+265234.200.49.1@1613741537 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 LibreOffice-still-common-7.0.6.2-alt2:sisyphus+276330.100.1.3@1624985903 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 LibreOffice-common-7.1.3.2-alt1:sisyphus+274980.100.1.2@1624383308 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-CTK-0.1.0-alt1.git.dc2e1289:sisyphus+273287.2000.5.3@1622761894 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libCTK-0.1.0-alt1.git.dc2e1289:sisyphus+273287.2000.5.3@1622761894 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 [imz@altair ~]$ > Теперь, когда интерпретатор собран статически, часть пакетов (возможно)
> ошибочно динамически линкует модули с libpython3.9.so.1.0.
Дело в том, что там давно висел патч из Федоры, который статическую либу просто не собирал. Теперь либа собирается, но чтобы сохранить старое поведение, в пакет она не идёт:
%files -n libpython3
%_libdir/libpython%pybasever%pyabi.so.*
%exclude %_libdir/libpython%pybasever%pyabi.a
Кстати, динамическую либу лучше собирать с тем самым флагом, чтобы была несколько быстрее.
Если питон используется из библиотек, то должен линковаться с библиотекой. Очевидно что при линковке с динамической должно занимать меньше места. Я не знаю сколько будет тянуть статическая линковка, возможно что несколько мегабайт. Не останется ли старый питон в статически слинкованных модулях при обновлении системного? В Убунту я вижу статический бинарник и динамическую либу. (Ответ для ilyakurdyukov на комментарий #38) > Если питон используется из библиотек, то должен линковаться с библиотекой. > Очевидно что при линковке с динамической должно занимать меньше места. Я не > знаю сколько будет тянуть статическая линковка, возможно что несколько > мегабайт. Не останется ли старый питон в статически слинкованных модулях при > обновлении системного? > > В Убунту я вижу статический бинарник и динамическую либу. Нет, я несколько другое имел в виду. Всё нормально, если в ELF-е (чаще исполняемой программе как gdb или gimp какой-нибудь, но может, и в библиотеке) нужен интерпретатор для расширений на питоне, и тогда динамически прилинкована библиотека libpython3. Но есть бинарные модули для питона. (Они используют ABI питона, предоставляемое как библиотекой libpython3, так и standalone интерпретатором, неважно как слинкованным: статически или динамически). Собственно, способ который всегда работает -- оставить модуль недолинкованым с libpython3, тогда он без проблем загрузится при обоих способах и ld.so не будет автоматически подгружать libpython3 (что может вызвать бабах при загрузке изнутри статически слинкованного интерпретатора). Есть подозрение, что в этом списке появились модули, которые ошибочно линкуются с libpython3 вместо недолиновки (что было принято в ALT-е раньше, пока не собрали python3 динамически). Попробую найти в списке пример для демонстрации. Тогда это и правда может быть проблемой. Хотя скорее всего работать будет, просто будет два питона подгружаться. Статик билд был добавлен: 3.2.2-alt4 28 Mar 2012 Заменён на shared: 3.6.4-alt1 3 Apr 2018 Как линковались эти модули в этом промежутке? Если модуль будет недолинкован, то каким образом система будет знать, что нужно будет подгрузить libpython? А при загрузке из статического питона - питон должен перекрыть все экспортируемые символы из библиотеки. Могут ли они перемешаться - не знаю. Лучше посмотреть как до 2018-го работало. Коллеги, если всё скопом забрать у Ильи сперва в сизиф, затем в p10 (и на e2k) не получается (страшно, непонятно, нерешённые вопросы) -- предлагаю вместо "всё в одном и хрен поймёшь" завести и порешать отдельными багами (в которых можно сослаться на соответствующие места этого обсуждения -- "bug 40278 comment NN"): - отключение COMPUTED_GOTOS на текущем %e2k (срочно, важно, несложно); - -O%_optlevel по умолчанию вместо прибитого гвоздями -O2 (важно); - применение патча насчёт labels as values на e2k (неохота тащить форк); - shared vs static по умолчанию. В принципе для переоформления багов и коммитов может хватить и меня, только есть риск, что засвоплюсь (эту багу прочёл уже выйдя из отпуска). (Ответ для Grigory Ustinov на комментарий #15) > Холивар "патчи против регулярок" длится уже давно Это не холивар, а выбор между известными плюсами и минусами двух вариантов. Каждый раз он делается заново -- с учётом конкретики проекта и изменения. (Ответ для Grigory Ustinov на комментарий #18) > > Вы думаете, что всё это должно быть написано в комментариях в спеке? Совершенно точно _не_ должно: в спеке это шум. А вот коммит "Updated Elbrus fixes" (2ebc522457794b150109e8ae42f3775e7ecd6f99) я бы тоже разбил на несколько (e2k-linux-gnu, computed gotos, labels as values, опции/баги профилировки lcc). При этом стоит перенести из comment 16 хоть дословно, хоть в сокращённом переводе на ИТ-латиницу (сославшись на полный вариант) в описание коммита про labels as values. Возможно, проще будет даже объединить его с более точечным и "простым" отключением computed gotos -- именно чтобы вся заваренная каша была описана слитно; возможно, стоит разделить объёмное описание на две части: 1) почему именно применена штатная ручка --with-computed-gotos=no (и при каких условиях её будет пора отключить, здесь стоит упомянуть "mcst#6028"), и 2) что именно делает скрипт (при этом однострочный комментарий в _спеке_ вида "see also ALT#40278/40xxx and commit message for 3.9.6-alt2" полезен). В данном разе добавление e2k-linux-gnu я бы оформил патчем и постарался его заапстримить -- а на sed откатился бы впоследствии, если апстрим заупрямится, но при этом другие новые архитектуры продолжит добавлять (ломая контекст). > > Для любопытных я могу оставить номер бага. > Да, пожалуй. Не просто "да", а обязательно; такие метаданные, когда подробности из головы повылетали, могут сберечь часы и дни раскопок заново даже самому сделавшему. > Выглядит оно мощно! Хороший commit message, см. тж. ядро. :-) Плохие дублируют код, а хорошие задают контекст и объясняют причины/тонкости. (Ответ для Grigory Ustinov на комментарий #23) > (Ответ для ilyakurdyukov на комментарий #22) > > > https://bugzilla.redhat.com/show_bug.cgi?id=556092 > > Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, > > чем годами поддерживать этот патч. Который еще и static билд ломает, > > а значит вредительский. > Гораздо проще ничего не менять, если никому не мешает=) > Золотое правило мастера "не чини то, что работает". Не пытался вникнуть в причины данного "I've chosen", но фраза про красную шляпу на пустом жбане помнится ещё с тех пор, как эти деятели упаковали как-то /usr/sbin/named нулевого размера в обновления... Считать любого сотрудника редхата априори мастером я бы поостерёгся: рукожопов, напылесошенных по объявлению, там гораздо больше, чем хотелось бы. Ну и даже на мастера бывает недосып, недосмотр и прочая проруха. Сейчас bugzilla.redhat.com на обслуживании, но вообще-то хорошо бы им отписать в тот старый rh#556092, что это "chosen to patch" ломает статическую сборку, даже если им до этого дела нет (как вариант, напомните мне письмом). > Предлагаю подобные отдельные ветви обсуждений выносить в отдельные баги, > чтобы не потерялось и чтобы не путаться в обсуждениях. +1 (Ответ для Ivan Zakharyaschev на комментарий #31) > (In reply to ilyakurdyukov from comment #29) > > > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, > > > если этот механизм родом из upstream.) > > Пока широкой розничной доступности не будет - это проблема. Потому что > > зарубежному апстриму негде взять железо для проверки патчей. > Но патч без кода, а просто делающий выбор опций в зависимости от моедли > компилятора могут и принять без тестирования. Есть подобные (и не совсем) > патчи ради компиляции на e2k, принятые в другие upstream-ы. Подтверждаю; и ради оптимизации -- тоже. *** Bug 40750 has been marked as a duplicate of this bug. *** ping ilyakurdyukov Что там новенького? (Ответ для Grigory Ustinov на комментарий #44) > ping ilyakurdyukov > > Что там новенького? Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и не собирается. (Ответ для ilyakurdyukov на комментарий #45) > (Ответ для Grigory Ustinov на комментарий #44) > > ping ilyakurdyukov > > > > Что там новенького? > > Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и > не собирается. Насколько я понял, мы остановились на таске 276773. Комментарий 35. С того момента были "озвучены" пожелания заинтересованных лиц. Вы хотели ревью, вы его получили. Теперь ваша очередь учесть эти пожелания и подготовить таск с опцией --commit. Потому что таск 276773 не упал с EPERM и никто из списка acl не может дать ему аппрув. Я попробую в кратце повторить суть желаемого: Давайте вынесем обсуждение статической линковки в отдельную багу и решим отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2) В этом релизе и так много очень хороших изменений, которым давно уже пора быть в сизифе. Я просил проверить этот билд. В итоге я так и не понял, со всеми ли плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас должно. Запустил на коммит, чтобы был EPERM. Если кто-то хочет всё растащить по отдельным багам - растаскивайте. (Ответ для ilyakurdyukov на комментарий #47) > Я просил проверить этот билд. В итоге я так и не понял, со всеми ли > плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не > опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас > должно. > > Запустил на коммит, чтобы был EPERM. > > Если кто-то хочет всё растащить по отдельным багам - растаскивайте. Я, к сожалению, не успел всё детально проверить, потому что оказался занят другим. (Ответ для Grigory Ustinov на комментарий #46) > Я попробую в кратце повторить суть желаемого: > Давайте вынесем обсуждение статической линковки в отдельную багу и решим > отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2) > В этом релизе и так много очень хороших изменений, которым давно уже пора > быть в сизифе. На данном этапе, я считаю, хорошая мысль немного отложить статический билд, потому что менять требования к модулям, которые могут быть загружены, надо аккуратно, отслеживая этот интерфейс через формальные зависимости вроде python3.9-ABI (разделить эту на две: можно всякие модули грузить -- предоставляется питоном, собранным динамически с libpython; и нельзя динамически слинкованные модули грузить -- придётся новое завести для статической сборки). А прочие улучшения можно сейчас собрать, ещё раз посмотреть всем заинтересованным и сообща одобрить. Ну и что всё это значит? http://git.altlinux.org/tasks/283153/logs/events.1.1.log 2021-Aug-17 14:26:06 :: task #283153 for sisyphus started by ilyakurdyukov: #100 build 3.9.6-alt2 from /people/ilyakurdyukov/packages/python3.git fetched at 2021-Aug-17 14:26:05 2021-Aug-17 14:26:07 :: [ppc64le] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [x86_64] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [armh] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [aarch64] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [i586] #100 python3.git 3.9.6-alt2: build start [x86_64] from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:12: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_condvar.h:5:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 5 | # error "this header requires Py_BUILD_CORE define" [x86_64] In file included from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:12: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_gil.h:15:4: error: #error You need either a POSIX-compatible or a Windows system! [x86_64] 15 | # error You need either a POSIX-compatible or a Windows system! [x86_64] cpp.req: /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h: cpp failed, trying c++ mode [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:8:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 8 | # error "this header requires Py_BUILD_CORE define" [x86_64] In file included from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:11: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_atomic.h:8:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 8 | # error "this header requires Py_BUILD_CORE define" [x86_64] In file included from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:12: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_gil.h:8:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 8 | # error "this header requires Py_BUILD_CORE define" [x86_64] -- (Ответ для ilyakurdyukov на комментарий #50) > Ну и что всё это значит? > > http://git.altlinux.org/tasks/283153/logs/events.1.1.log Это всё не мешает сборке. Сборка упала на error: No such file or directory: /usr/src/tmp/python3-buildroot/usr/lib64/libpython3.9.a Я же попросил убрать оба коммита про статическую сборку, потому что они по смыслу идут вместе. (Ответ для Grigory Ustinov на комментарий #51) > (Ответ для ilyakurdyukov на комментарий #50) > > Ну и что всё это значит? > > > > http://git.altlinux.org/tasks/283153/logs/events.1.1.log > > Это всё не мешает сборке. Сборка упала на > error: No such file or directory: > /usr/src/tmp/python3-buildroot/usr/lib64/libpython3.9.a Видно в конце http://git.altlinux.org/tasks/283153/build/100/x86_64/log python3-3.9.6-alt2 -> sisyphus: Wed Jun 30 2021 Ilya Kurdyukov <ilyakurdyukov@altlinux> 3.9.6-alt2 - Removed changes from ALT39329, restores -O3 and -g flags (Closes: #40278). - Updated Elbrus fixes. - Enabled optimizations (armh excluded due to test_hashlib crash). (Ответ для ilyakurdyukov на комментарий #41) > Если модуль будет недолинкован, то каким образом система будет знать, что > нужно будет подгрузить libpython? "Модуль" загружается уже из интерпретатора питона (либо статического /usr/bin/python3, либо встроенного в другую программу с помощью libpython3). Так что тут нет проблемы. > А при загрузке из статического питона - питон должен перекрыть все > экспортируемые символы из библиотеки. Могут ли они перемешаться - не знаю. > Лучше посмотреть как до 2018-го работало. Ну тогда большинство модулей волшебным образом были недолинкованы, а где-то могли требоваться какие-то патчи (и если падение при использовании модуля происходило, это был сигнал мейнтейнеру; а за время динамического питона этих сигналов не было, что могло позволить расслабиться). Например, в p8 список python3-module-* с такой зависимостью невелик. Я посмотрел так: $ hsh --ini ~/hasher2/ --apt-conf /home/imz/.hasher/p8/apt.conf $ ~/hasher2/aptbox/apt-cache whatdepends 'libpython3.5m.so.1.0()(64bit)' А в таком списке для Sisyphus я наугад несколько проверил. Например, в python3-module-PyQt5 вроде всё законно: модули для питона недолинкованы с libpython3, а заисимость берётся из плагинов для qt, которые используют интерпретатор. А вот падение -- вызвано ли оно обсуждаемой проблемой, я не исследовал: $ p=python3-module-CTK; hsh --without-stuff --ini ~/hasher2 && hsh-install ~/hasher2/ "$p" tests-for-installed-python3-pkgs && hsh-run ~/hasher2/ --mount=/proc,/dev/pts -- bash -c "rpm -q $p; rpm -q $p --provides; echo 'Non-importable:'; /usr/lib/rpm/check-python3-provs-importable $p" python3-module-CTK-0.1.0-alt3.git.dc2e1289.x86_64 python3(CTKCommandLineModulesBackendFunctionPointerPythonQt) python3(CTKCommandLineModulesBackendLocalProcessPythonQt) python3(CTKCommandLineModulesBackendXMLCheckerPythonQt) python3(CTKCommandLineModulesCorePythonQt) python3(CTKCommandLineModulesFrontendQtGuiPythonQt) python3(CTKCommandLineModulesFrontendQtWebKitPythonQt) python3(CTKCorePythonQt) python3(CTKDICOMCorePythonQt) python3(CTKDICOMWidgetsPythonQt) python3(CTKImageProcessingITKCorePythonQt) python3(CTKPluginFrameworkPythonQt) python3(CTKScriptingPythonWidgetsPythonQt) python3(CTKVisualizationVTKCorePythonQt) python3(CTKVisualizationVTKWidgetsPythonQt) python3(CTKWidgetsPythonQt) python3(ctk) python3(ctkSimplePythonShell) python3(qt) python3-module-CTK = 0.1.0-alt3.git.dc2e1289:sisyphus+293819.1140.16.3 Non-importable: CTKCommandLineModulesBackendFunctionPointerPythonQt CTKCommandLineModulesBackendLocalProcessPythonQt CTKCommandLineModulesBackendXMLCheckerPythonQt CTKCommandLineModulesCorePythonQt CTKCommandLineModulesFrontendQtGuiPythonQt CTKCommandLineModulesFrontendQtWebKitPythonQt sh: line 1: 183721 Segmentation fault python3 -c 'import CTKCorePythonQt' 2> /dev/null CTKCorePythonQt sh: line 1: 183723 Segmentation fault python3 -c 'import CTKDICOMCorePythonQt' 2> /dev/null CTKDICOMCorePythonQt sh: line 1: 183725 Segmentation fault python3 -c 'import CTKDICOMWidgetsPythonQt' 2> /dev/null CTKDICOMWidgetsPythonQt CTKImageProcessingITKCorePythonQt CTKPluginFrameworkPythonQt sh: line 1: 183731 Segmentation fault python3 -c 'import CTKScriptingPythonWidgetsPythonQt' 2> /dev/null CTKScriptingPythonWidgetsPythonQt sh: line 1: 183733 Segmentation fault python3 -c 'import CTKVisualizationVTKCorePythonQt' 2> /dev/null CTKVisualizationVTKCorePythonQt sh: line 1: 183735 Segmentation fault python3 -c 'import CTKVisualizationVTKWidgetsPythonQt' 2> /dev/null CTKVisualizationVTKWidgetsPythonQt sh: line 1: 183737 Segmentation fault python3 -c 'import CTKWidgetsPythonQt' 2> /dev/null CTKWidgetsPythonQt sh: line 1: 183739 Segmentation fault python3 -c 'import ctk' 2> /dev/null ctk ctkSimplePythonShell qt $ |
