40278 2021-06-24 14:34:05 +0300 В python3-base задаются заведомо неоптимальные флаги сборки 2023-06-02 05:20:53 +0300 1 1 4 Development Sisyphus python3-base unstable all Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=40291 regression P3 normal --- 39329 1 mike grenka aris bircoph george glebfm grenka ilyakurdyukov imz kotopesutility lav ldv vitty qa-sisyphus oldest_to_newest 199450 0 mike 2021-06-24 14:34:05 +0300 +++ Данная ошибка создана размножением ошибки 39329 +++ Начиная с python3 3.9.4-alt1, сборка происходит с прибитым гвоздиком -O2 вместо указанного в %optflags и соответствующего %_optlevel, что само по себе нехорошо (считаю, что bug 39329 была изложена странно). Также наш специалист по оптимизации Илья Курдюков предлагает на x86 и, возможно, других архитектурах задействовать --enable-optimizations=yes, а вот на %e2k делать --with-computed-gotos=no (потребуется обсуждаемая отдельно доработка компилятора и, возможно, кода интерпретатора, чтоб они стали ускорять, а не тормозить); в любом случае по состоянию на сегодня для lcc 1.25 в альте штатным уровнем оптимизации является именно -O3 и разница производительности на всём этом выходит в разы. PS: -O3 гвоздиком же прибил vitty@ в 3.2.2-alt4: http://git.altlinux.org/gears/p/python3.git?p=python3.git;a=commitdiff;h=ab72acf07643aa6b3985631f8a9c3d49854d8335 -- что, впрочем, соответствует нынешнему апстримному configure.ac: http://github.com/python/cpython/blob/main/configure.ac#LC1564 199455 1 9447 ilyakurdyukov 2021-06-24 16:24:05 +0300 Created attachment 9447 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 на Эльбрусе пока невозможно, нужно делать какие-то хаки для компилятора, потому что сбор профиля падает с ошибкой. 199493 2 ilyakurdyukov 2021-06-25 15:54:22 +0300 И еще нашел две проблемы: 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 199500 3 mike 2021-06-26 10:59:44 +0300 (Ответ для ilyakurdyukov на комментарий #2) > И еще нашел две проблемы: Новые проблемы, не связанные с темой бага, лучше вешать новыми багами, чтобы каждый баг имел чёткий критерий, по которому он (не) решён. За тест спасибо :-) 199501 4 grenka 2021-06-26 11:06:50 +0300 Да, по поводу valgrind и shared хотел разобраться, но руки не дошли. Спасибо. Оформите отдельные баги, если не сложно, как указал mike@ чуть выше. Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи мало кого интересуют. 199523 5 lav 2021-06-27 01:37:48 +0300 (Ответ для Grigory Ustinov на комментарий #4) ... > Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и > ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи > мало кого интересуют. Возможно, в изменения по bug 39329 вкралась ошибка, и действительно в сборке участвует -O2 вне зависимости от указанного в %optflags. Мы на gcc это можем не замечать, а вот на Эльбрусе заметили, потому что у них -O3 в %optflags. Если получится убрать прибитый -O2 в пользу %optflags, было бы здорово. 199666 6 ilyakurdyukov 2021-06-29 15:18:34 +0300 valgrind и дублированную shared сборку исправили, теперь что с этой опцией ставящей -O2? Во первых и сама сборка проекта ставит -O3, и даже -O3 был явно задан в пакете: > PS: -O3 гвоздиком же прибил vitty@ в 3.2.2-alt4: Что игнорируется патчем. Я считаю что патч нужно откатить совсем, а не гнаться за непонятной красотой в логах. Мало того, этот патч еще отключал отладочную информацию (-g). Что я могу сам сделать, вместе с включением --enable-optimizations, и доработками для Эльбруса. 199673 7 grenka 2021-06-29 16:14:13 +0300 Я не понимаю, что от меня хотят. На нормальной архитектуре разница между O2 и O3 не заметна. То есть мне бы хотелось понимать, что нужно сделать: а. откатить все изменения по поводу флагов полностью б. оставить как есть в. сделать что-то промежуточное 199677 8 ilyakurdyukov 2021-06-29 16:33:26 +0300 Предлагаю удалить эти строки из спека: 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. 199681 9 grenka 2021-06-29 16:48:56 +0300 Принято. 199689 10 ilyakurdyukov 2021-06-29 19:24:37 +0300 Изменения на ревью: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git А мне еще проверить надо, что в новой версии всё работает (завершу уже завтра). 199690 11 grenka 2021-06-29 19:56:01 +0300 Во-первых, +%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) и этот баг закроется после того, как таск закоммитится. 199691 12 9459 ilyakurdyukov 2021-06-29 20:12:35 +0300 Created attachment 9459 python3.8.1-e2k-plus10.patch 199692 13 9460 ilyakurdyukov 2021-06-29 20:15:31 +0300 Created attachment 9460 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 выражения фактически делают то же самое, только менее красиво, зато автоматически. 199693 14 aris 2021-06-29 20:33:04 +0300 (Ответ для ilyakurdyukov на комментарий #13) > То что заменяет этот патч - понятно. Остальное непонятное - сделано так по > той причине, что мелкие правки от разработчиков питона будут часто ломать > патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при > добавлении или удалении любого нового опкода в интерпретаторе - патч нужно > будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что > удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы > добавить патч для Эльбруса в сизиф. Еще можно оформить этот набор sed-awk выражений в отдельный скрипт и использовать для генерации нового патча, когда текущий отвалится. 199694 15 grenka 2021-06-29 20:36:57 +0300 (Ответ для ilyakurdyukov на комментарий #13) > Создано вложение 9460 [подробности] > 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 > выражения фактически делают то же самое, только менее красиво, зато > автоматически. Холивар "патчи против регулярок" длится уже давно, я не хочу в нём участвовать. 199696 16 ilyakurdyukov 2021-06-30 06:08:01 +0300 Если хочется сделать красиво, то можно сделать так: %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. Для чего вероятно, нужно знать в какой ассемблер компилятор превращает то и другое. 199697 17 ilyakurdyukov 2021-06-30 06:48:34 +0300 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. 199698 18 grenka 2021-06-30 08:38:24 +0300 > Вы думаете, что всё это должно быть написано в комментариях в спеке? Для любопытных я могу оставить номер бага. Да, пожалуй. Выглядит оно мощно! 199701 19 ilyakurdyukov 2021-06-30 09:43:37 +0300 Обновил: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git > можно было бы просто сделать через git revert git revert не справился, потому что рядом были изменения. Так что сделал вручную, благо правки небольшие. 199704 20 lav 2021-06-30 10:32:17 +0300 (Ответ для 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 для этой фичи? 199705 21 ilyakurdyukov 2021-06-30 10:35:49 +0300 Таки почему-то локальная 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 так что и список бы не помог. 199747 22 9464 ilyakurdyukov 2021-06-30 15:14:15 +0300 Created attachment 9464 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 199751 23 grenka 2021-06-30 15:27:26 +0300 (Ответ для ilyakurdyukov на комментарий #22) > Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, чем > годами поддерживать этот патч. Который еще и static билд ломает, а значит > вредительский. Гораздо проще ничего не менять, если никому не мешает=) Золотое правило мастера "не чини то, что работает". > > Различия же в производительности static билда очень ощутимые (на 25% > быстрее). Почему так происходит - я не знаю. Но я думаю, что ради этого > стоит откатить патч из Федоры, его необходимость для меня сомнительна. > Возможно патч сломался после каких-то изменений в питоне. Предлагаю подобные отдельные ветви обсуждений выносить в отдельные баги, чтобы не потерялось и чтобы не путаться в обсуждениях. 199756 24 ilyakurdyukov 2021-06-30 16:44:10 +0300 Итак, вот коммиты, которыми я вроде бы починил все найденные проблемы с производительностью: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git Еще у меня есть подозрения что --with-valgrind может негативно влиять, но видимо эта разница небольшая, я проверяю на basalt, которая еще и как шлюз используется и на ней есть небольшая фоновая нагрузка. Но разница между static и shared точно вызвана не флуктуациями загрузки, так как очень значительная. Требуются тестеры для сравнения 3.9.6-alt1 и этого кандидата в 3.9.6-alt2. Можете использовать приложенный к багу fannkuch.py и другие вычислительные тесты, что найдёте. 199772 25 ilyakurdyukov 2021-06-30 18:02:34 +0300 Посоветовали: 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 199805 26 ilyakurdyukov 2021-07-01 04:06:08 +0300 Вчера проверял, но вне hasher: export CFLAGS_NODIST="-fno-semantic-interposition" export LDFLAGS_NODIST="-fno-semantic-interposition" Перед configure - делает shared билд почти таким же быстрым как static. Почти потому, что на 3% у меня вышло медленнее, непонятно, наводка ли это от системных процессов или действительно медленнее. На Эльбрусе же такая опция не поддерживается. Так что, если хотите shared билд - могу сделать для Эльбруса static, для всех остальных с этой опцией. 199827 27 imz 2021-07-01 13:18:25 +0300 (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, лучше не тащить, потому что с ним больше труда для мейнтейнера. 199830 28 imz 2021-07-01 13:37:52 +0300 (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.) 199833 29 ilyakurdyukov 2021-07-01 13:51:01 +0300 > На 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.) Пока широкой розничной доступности не будет - это проблема. Потому что зарубежному апстриму негде взять железо для проверки патчей. 199840 30 imz 2021-07-01 14:06:53 +0300 (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 независимо от наличия этого флага.) 199841 31 imz 2021-07-01 14:09:43 +0300 (In reply to ilyakurdyukov from comment #29) > > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.) > Пока широкой розничной доступности не будет - это проблема. Потому что > зарубежному апстриму негде взять железо для проверки патчей. Но патч без кода, а просто делающий выбор опций в зависимости от моедли компилятора могут и принять без тестирования. Есть подобные (и не совсем) патчи ради компиляции на e2k, принятые в другие upstream-ы. 199842 32 ilyakurdyukov 2021-07-01 14:22:27 +0300 Для понимания что такое -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. Попросил МЦСТ чтобы добавили такую опцию. 199899 33 ilyakurdyukov 2021-07-02 10:36:40 +0300 Хорошо бы не затягивать с исправлением производительности. Чтобы в 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) 199907 34 grenka 2021-07-02 12:26:03 +0300 (Ответ для ilyakurdyukov на комментарий #33) > Хорошо бы не затягивать с исправлением производительности. Чтобы в p10 ушла > быстрая версия. > > Такое уже бывало? На других архитектурах не было ошибки. Нет, это что-то новенькое. 199952 35 ilyakurdyukov 2021-07-02 17:30:46 +0300 Отключил PGO для armh, теперь собралось везде. http://git.altlinux.org/tasks/276773/logs/events.1.1.log Падение на том тесте не случайное, повторно воспроизводилось. Видимо компилятор переоптимизировал, возможно баг компилятора. 200063 36 imz 2021-07-06 17:34:44 +0300 (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 ~]$ 200066 37 ilyakurdyukov 2021-07-06 17:44:36 +0300 > Теперь, когда интерпретатор собран статически, часть пакетов (возможно) > ошибочно динамически линкует модули с libpython3.9.so.1.0. Дело в том, что там давно висел патч из Федоры, который статическую либу просто не собирал. Теперь либа собирается, но чтобы сохранить старое поведение, в пакет она не идёт: %files -n libpython3 %_libdir/libpython%pybasever%pyabi.so.* %exclude %_libdir/libpython%pybasever%pyabi.a Кстати, динамическую либу лучше собирать с тем самым флагом, чтобы была несколько быстрее. 200067 38 ilyakurdyukov 2021-07-06 18:03:17 +0300 Если питон используется из библиотек, то должен линковаться с библиотекой. Очевидно что при линковке с динамической должно занимать меньше места. Я не знаю сколько будет тянуть статическая линковка, возможно что несколько мегабайт. Не останется ли старый питон в статически слинкованных модулях при обновлении системного? В Убунту я вижу статический бинарник и динамическую либу. 200074 39 imz 2021-07-07 01:34:16 +0300 (Ответ для ilyakurdyukov на комментарий #38) > Если питон используется из библиотек, то должен линковаться с библиотекой. > Очевидно что при линковке с динамической должно занимать меньше места. Я не > знаю сколько будет тянуть статическая линковка, возможно что несколько > мегабайт. Не останется ли старый питон в статически слинкованных модулях при > обновлении системного? > > В Убунту я вижу статический бинарник и динамическую либу. Нет, я несколько другое имел в виду. Всё нормально, если в ELF-е (чаще исполняемой программе как gdb или gimp какой-нибудь, но может, и в библиотеке) нужен интерпретатор для расширений на питоне, и тогда динамически прилинкована библиотека libpython3. Но есть бинарные модули для питона. (Они используют ABI питона, предоставляемое как библиотекой libpython3, так и standalone интерпретатором, неважно как слинкованным: статически или динамически). Собственно, способ который всегда работает -- оставить модуль недолинкованым с libpython3, тогда он без проблем загрузится при обоих способах и ld.so не будет автоматически подгружать libpython3 (что может вызвать бабах при загрузке изнутри статически слинкованного интерпретатора). Есть подозрение, что в этом списке появились модули, которые ошибочно линкуются с libpython3 вместо недолиновки (что было принято в ALT-е раньше, пока не собрали python3 динамически). Попробую найти в списке пример для демонстрации. 200081 40 ilyakurdyukov 2021-07-07 05:57:18 +0300 Тогда это и правда может быть проблемой. Хотя скорее всего работать будет, просто будет два питона подгружаться. Статик билд был добавлен: 3.2.2-alt4 28 Mar 2012 Заменён на shared: 3.6.4-alt1 3 Apr 2018 Как линковались эти модули в этом промежутке? 200083 41 ilyakurdyukov 2021-07-07 06:04:06 +0300 Если модуль будет недолинкован, то каким образом система будет знать, что нужно будет подгрузить libpython? А при загрузке из статического питона - питон должен перекрыть все экспортируемые символы из библиотеки. Могут ли они перемешаться - не знаю. Лучше посмотреть как до 2018-го работало. 201005 42 mike 2021-07-29 09:17:02 +0300 Коллеги, если всё скопом забрать у Ильи сперва в сизиф, затем в 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-ы. Подтверждаю; и ради оптимизации -- тоже. 201703 43 grenka 2021-08-17 11:46:39 +0300 *** Bug 40750 has been marked as a duplicate of this bug. *** 201704 44 grenka 2021-08-17 11:48:42 +0300 ping ilyakurdyukov Что там новенького? 201707 45 ilyakurdyukov 2021-08-17 12:35:05 +0300 (Ответ для Grigory Ustinov на комментарий #44) > ping ilyakurdyukov > > Что там новенького? Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и не собирается. 201712 46 grenka 2021-08-17 13:35:42 +0300 (Ответ для ilyakurdyukov на комментарий #45) > (Ответ для Grigory Ustinov на комментарий #44) > > ping ilyakurdyukov > > > > Что там новенького? > > Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и > не собирается. Насколько я понял, мы остановились на таске 276773. Комментарий 35. С того момента были "озвучены" пожелания заинтересованных лиц. Вы хотели ревью, вы его получили. Теперь ваша очередь учесть эти пожелания и подготовить таск с опцией --commit. Потому что таск 276773 не упал с EPERM и никто из списка acl не может дать ему аппрув. Я попробую в кратце повторить суть желаемого: Давайте вынесем обсуждение статической линковки в отдельную багу и решим отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2) В этом релизе и так много очень хороших изменений, которым давно уже пора быть в сизифе. 201729 47 ilyakurdyukov 2021-08-17 15:00:41 +0300 Я просил проверить этот билд. В итоге я так и не понял, со всеми ли плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас должно. Запустил на коммит, чтобы был EPERM. Если кто-то хочет всё растащить по отдельным багам - растаскивайте. 201730 48 imz 2021-08-17 15:31:21 +0300 (Ответ для ilyakurdyukov на комментарий #47) > Я просил проверить этот билд. В итоге я так и не понял, со всеми ли > плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не > опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас > должно. > > Запустил на коммит, чтобы был EPERM. > > Если кто-то хочет всё растащить по отдельным багам - растаскивайте. Я, к сожалению, не успел всё детально проверить, потому что оказался занят другим. 201731 49 imz 2021-08-17 15:37:04 +0300 (Ответ для Grigory Ustinov на комментарий #46) > Я попробую в кратце повторить суть желаемого: > Давайте вынесем обсуждение статической линковки в отдельную багу и решим > отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2) > В этом релизе и так много очень хороших изменений, которым давно уже пора > быть в сизифе. На данном этапе, я считаю, хорошая мысль немного отложить статический билд, потому что менять требования к модулям, которые могут быть загружены, надо аккуратно, отслеживая этот интерфейс через формальные зависимости вроде python3.9-ABI (разделить эту на две: можно всякие модули грузить -- предоставляется питоном, собранным динамически с libpython; и нельзя динамически слинкованные модули грузить -- придётся новое завести для статической сборки). А прочие улучшения можно сейчас собрать, ещё раз посмотреть всем заинтересованным и сообща одобрить. 201747 50 ilyakurdyukov 2021-08-17 18:03:58 +0300 Ну и что всё это значит? 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] -- 201755 51 grenka 2021-08-17 19:16:57 +0300 (Ответ для 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 Я же попросил убрать оба коммита про статическую сборку, потому что они по смыслу идут вместе. 201756 52 imz 2021-08-17 20:20:24 +0300 (Ответ для 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 201766 53 repository-robot 2021-08-18 03:14:21 +0300 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). 226910 54 imz 2023-06-02 05:02:45 +0300 (Ответ для 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 $ 9447 2021-06-24 16:24:05 +0300 2021-06-30 15:14:15 +0300 fannkuch.py fannkuch.py text/x-python 3222 ilyakurdyukov IyBUaGUgQ29tcHV0ZXIgTGFuZ3VhZ2UgQmVuY2htYXJrcyBHYW1lCiMgaHR0cDovL2JlbmNobWFy a3NnYW1lLmFsaW90aC5kZWJpYW4ub3JnLwojCiMgY29udHJpYnV0ZWQgYnkgSm9lcmcgQmF1bWFu bgojIG1hbnkgdGhhbmtzIHRvIE9sZWcgTWF6dXJvdiBmb3IgaGlzIGhlbHBmdWwgZGVzY3JpcHRp b24KCmZyb20gc3lzIGltcG9ydCBhcmd2CmZyb20gbWF0aCBpbXBvcnQgZmFjdG9yaWFsCmZyb20g bXVsdGlwcm9jZXNzaW5nIGltcG9ydCBjcHVfY291bnQsIFBvb2wKZnJvbSBpdGVydG9vbHMgaW1w b3J0IGlzbGljZSwgc3Rhcm1hcAoKZGVmIHBlcm11dGF0aW9ucyhuLCBzdGFydCwgc2l6ZSk6CiAg ICBwID0gYnl0ZWFycmF5KHJhbmdlKG4pKQogICAgY291bnQgPSBieXRlYXJyYXkobikKCiAgICBy ZW1haW5kZXIgPSBzdGFydAogICAgZm9yIHYgaW4gcmFuZ2UobiAtIDEsIDAsIC0xKToKICAgICAg ICBjb3VudFt2XSwgcmVtYWluZGVyID0gZGl2bW9kKHJlbWFpbmRlciwgZmFjdG9yaWFsKHYpKQog ICAgICAgIGZvciBfIGluIHJhbmdlKGNvdW50W3ZdKToKICAgICAgICAgICAgcFs6dl0sIHBbdl0g PSBwWzE6diArIDFdLCBwWzBdCgogICAgYXNzZXJ0KGNvdW50WzFdID09IDApCiAgICBhc3NlcnQo c2l6ZSA8IDIgb3IgKHNpemUgJSAyID09IDApKQoKICAgIGlmIHNpemUgPCAyOgogICAgICAgIHlp ZWxkIHBbOl0KICAgIGVsc2U6CiAgICAgICAgcm90YXRpb25fc3dhcHMgPSBbTm9uZV0gKiBuCiAg ICAgICAgZm9yIGkgaW4gcmFuZ2UoMSwgbik6CiAgICAgICAgICAgIHIgPSBsaXN0KHJhbmdlKG4p KQogICAgICAgICAgICBmb3IgdiBpbiByYW5nZSgxLCBpICsgMSk6CiAgICAgICAgICAgICAgICBy Wzp2XSwgclt2XSA9IHJbMTp2ICsgMV0sIHJbMF0KICAgICAgICAgICAgc3dhcHMgPSBbXQogICAg ICAgICAgICBmb3IgZHN0LCBzcmMgaW4gZW51bWVyYXRlKHIpOgogICAgICAgICAgICAgICAgaWYg ZHN0ICE9IHNyYzoKICAgICAgICAgICAgICAgICAgICBzd2Fwcy5hcHBlbmQoKGRzdCwgc3JjKSkK ICAgICAgICAgICAgcm90YXRpb25fc3dhcHNbaV0gPSB0dXBsZShzd2FwcykKCiAgICAgICAgd2hp bGUgVHJ1ZToKICAgICAgICAgICAgeWllbGQgcFs6XQogICAgICAgICAgICBwWzBdLCBwWzFdID0g cFsxXSwgcFswXQogICAgICAgICAgICB5aWVsZCBwWzpdCiAgICAgICAgICAgIGkgPSAyCiAgICAg ICAgICAgIHdoaWxlIGNvdW50W2ldID49IGk6CiAgICAgICAgICAgICAgICBjb3VudFtpXSA9IDAK ICAgICAgICAgICAgICAgIGkgKz0gMQogICAgICAgICAgICBlbHNlOgogICAgICAgICAgICAgICAg Y291bnRbaV0gKz0gMQogICAgICAgICAgICAgICAgdCA9IHBbOl0KICAgICAgICAgICAgICAgIGZv ciBkc3QsIHNyYyBpbiByb3RhdGlvbl9zd2Fwc1tpXToKICAgICAgICAgICAgICAgICAgICBwW2Rz dF0gPSB0W3NyY10KCmRlZiBhbHRlcm5hdGluZ19mbGlwc19nZW5lcmF0b3Iobiwgc3RhcnQsIHNp emUpOgogICAgbWF4aW11bV9mbGlwcyA9IDAKICAgIGFsdGVybmF0aW5nX2ZhY3RvciA9IDEKICAg IGZvciBwZXJtdXRhdGlvbiBpbiBpc2xpY2UocGVybXV0YXRpb25zKG4sIHN0YXJ0LCBzaXplKSwg c2l6ZSk6CiAgICAgICAgZmlyc3QgPSBwZXJtdXRhdGlvblswXQogICAgICAgIGlmIGZpcnN0Ogog ICAgICAgICAgICBmbGlwc19jb3VudCA9IDEKICAgICAgICAgICAgd2hpbGUgVHJ1ZToKICAgICAg ICAgICAgICAgIHBlcm11dGF0aW9uWzpmaXJzdCArIDFdID0gcGVybXV0YXRpb25bZmlyc3Q6Oi0x XQogICAgICAgICAgICAgICAgZmlyc3QgPSBwZXJtdXRhdGlvblswXQogICAgICAgICAgICAgICAg aWYgbm90IGZpcnN0OiBicmVhawogICAgICAgICAgICAgICAgZmxpcHNfY291bnQgKz0gMQogICAg ICAgICAgICBpZiBtYXhpbXVtX2ZsaXBzIDwgZmxpcHNfY291bnQ6CiAgICAgICAgICAgICAgICBt YXhpbXVtX2ZsaXBzID0gZmxpcHNfY291bnQKICAgICAgICAgICAgeWllbGQgZmxpcHNfY291bnQg KiBhbHRlcm5hdGluZ19mYWN0b3IKICAgICAgICBlbHNlOgogICAgICAgICAgICB5aWVsZCAwCiAg ICAgICAgYWx0ZXJuYXRpbmdfZmFjdG9yID0gLWFsdGVybmF0aW5nX2ZhY3RvcgogICAgeWllbGQg bWF4aW11bV9mbGlwcwoKZGVmIHRhc2sobiwgc3RhcnQsIHNpemUpOgogICAgYWx0ZXJuYXRpbmdf ZmxpcHMgPSBhbHRlcm5hdGluZ19mbGlwc19nZW5lcmF0b3Iobiwgc3RhcnQsIHNpemUpCiAgICBy ZXR1cm4gc3VtKGlzbGljZShhbHRlcm5hdGluZ19mbGlwcywgc2l6ZSkpLCBuZXh0KGFsdGVybmF0 aW5nX2ZsaXBzKQoKZGVmIGZhbm5rdWNoKG4pOgogICAgaWYgbiA8IDA6CiAgICAgICAgZm9yIGRh dGEgaW4gaXNsaWNlKHBlcm11dGF0aW9ucygtbiwgMCwgZmFjdG9yaWFsKC1uKSksIGZhY3Rvcmlh bCgtbikpOgogICAgICAgICAgICBwcmludCgnJy5qb2luKG1hcChsYW1iZGEgbjogc3RyKG4gKyAx KSwgZGF0YSkpKQogICAgZWxzZToKICAgICAgICBhc3NlcnQobiA+IDApCgogICAgICAgIHRhc2tf Y291bnQgPSBjcHVfY291bnQoKQogICAgICAgIHRvdGFsID0gZmFjdG9yaWFsKG4pCiAgICAgICAg dGFza19zaXplID0gKHRvdGFsICsgdGFza19jb3VudCAtIDEpIC8vIHRhc2tfY291bnQKCiAgICAg ICAgaWYgdGFza19zaXplIDwgMjAwMDA6CiAgICAgICAgICAgIHRhc2tfc2l6ZSA9IHRvdGFsCiAg ICAgICAgICAgIHRhc2tfY291bnQgPSAxCgogICAgICAgIGFzc2VydCh0YXNrX3NpemUgJSAyID09 IDApCgogICAgICAgIHRhc2tfYXJncyA9IFsobiwgaSAqIHRhc2tfc2l6ZSwgdGFza19zaXplKSBm b3IgaSBpbiByYW5nZSh0YXNrX2NvdW50KV0KCiAgICAgICAgaWYgdGFza19jb3VudCA+IDE6CiAg ICAgICAgICAgIHdpdGggUG9vbCgpIGFzIHBvb2w6CiAgICAgICAgICAgICAgICBjaGVja3N1bXMs IG1heGltdW1zID0gemlwKCpwb29sLnN0YXJtYXAodGFzaywgdGFza19hcmdzKSkKICAgICAgICBl bHNlOgogICAgICAgICAgICBjaGVja3N1bXMsIG1heGltdW1zID0gemlwKCpzdGFybWFwKHRhc2ss IHRhc2tfYXJncykpCgogICAgICAgIGNoZWNrc3VtLCBtYXhpbXVtID0gc3VtKGNoZWNrc3Vtcyks IG1heChtYXhpbXVtcykKICAgICAgICBwcmludCgiezB9XG5QZmFubmt1Y2hlbih7MX0pID0gezJ9 Ii5mb3JtYXQoY2hlY2tzdW0sIG4sIG1heGltdW0pKQoKaWYgX19uYW1lX18gPT0gIl9fbWFpbl9f IjoKICAgIGZhbm5rdWNoKGludChhcmd2WzFdKSkK 9459 2021-06-29 20:12:35 +0300 2021-06-29 20:12:35 +0300 python3.8.1-e2k-plus10.patch python3.8.1-e2k-plus10.patch text/plain 2467 ilyakurdyukov ZGlmZiAtLWdpdCBhL1B5dGhvbi9jZXZhbC5jIGIvUHl0aG9uL2NldmFsLmMKaW5kZXggMzMwNmZi OS4uYjY4NDU3MCAxMDA2NDQKLS0tIGEvUHl0aG9uL2NldmFsLmMKKysrIGIvUHl0aG9uL2NldmFs LmMKQEAgLTg3Myw5ICs4NzMsMzYgQEAgX1B5RXZhbF9FdmFsRnJhbWVEZWZhdWx0KFB5RnJhbWVP YmplY3QgKmYsIGludCB0aHJvd2ZsYWcpCiAKICNlbHNlCiAjZGVmaW5lIFRBUkdFVChvcCkgb3AK KyNpZmRlZiBfX2Uya19fCisjaWZkZWYgTExUUkFDRQorI2RlZmluZSBOT19MTFRSQUNFICFsbHRy YWNlICYmCisjZWxzZQorI2RlZmluZSBOT19MTFRSQUNFIDEKKyNlbmRpZgorCisjZGVmaW5lIEZB U1RfRElTUEFUQ0goKSBcCisgICAgeyBcCisgICAgICAgIGlmIChOT19MTFRSQUNFICYmICFfUHlf VHJhY2luZ1Bvc3NpYmxlKGNldmFsKSAmJiAhUHlEVHJhY2VfTElORV9FTkFCTEVEKCkpIHsgXAor ICAgICAgICAgICAgZi0+Zl9sYXN0aSA9IElOU1RSX09GRlNFVCgpOyBcCisgICAgICAgICAgICBO RVhUT1BBUkcoKTsgXAorICAgICAgICAgICAgZ290byBzd2l0Y2hfbG9vcDsgXAorICAgICAgICB9 IFwKKyAgICAgICAgZ290byBmYXN0X25leHRfb3Bjb2RlOyBcCisgICAgfQorCisjZGVmaW5lIERJ U1BBVENIKCkgXAorICAgIHsgXAorICAgICAgICBpZiAoIV9QeV9hdG9taWNfbG9hZF9yZWxheGVk KGV2YWxfYnJlYWtlcikpIHsgXAorICAgICAgICAgICAgRkFTVF9ESVNQQVRDSCgpOyBcCisgICAg ICAgIH0gXAorICAgICAgICBjb250aW51ZTsgXAorICAgIH0KKworI2Vsc2UKICNkZWZpbmUgRkFT VF9ESVNQQVRDSCgpIGdvdG8gZmFzdF9uZXh0X29wY29kZQogI2RlZmluZSBESVNQQVRDSCgpIGNv bnRpbnVlCiAjZW5kaWYKKyNlbmRpZgogCiAKIC8qIFR1cGxlIGFjY2VzcyBtYWNyb3MgKi8KQEAg LTEzMjAsNiArMTM0Nyw5IEBAIG1haW5fbG9vcDoKICAgICAgICAgfQogI2VuZGlmCiAKKyNpZmRl ZiBfX2Uya19fCitzd2l0Y2hfbG9vcDoKKyNlbmRpZgogICAgICAgICBzd2l0Y2ggKG9wY29kZSkg ewogCiAgICAgICAgIC8qIEJFV0FSRSEKQEAgLTM2OTEsNiArMzcyMSwyNiBAQCBtYWluX2xvb3A6 CiAgICAgICAgIF91bmtub3duX29wY29kZToKICNlbmRpZgogICAgICAgICBkZWZhdWx0OgorI2lm ZGVmIF9fZTJrX18KKyAgICAgICAgICAgIFB5X1VOUkVBQ0hBQkxFKCk7CisgICAgICAgIC8qICQg YXdrICcvdW5rbm93bl9vcGNvZGUve3ByaW50ICJYKCIgTlItMiAiKSJ9JyBvcGNvZGVfdGFyZ2V0 cy5oICovCisjZGVmaW5lIFgoaSkgY2FzZSBpOgorICAgICAgICBYKDApIFgoNykgWCg4KSBYKDEz KSBYKDE0KSBYKDE4KSBYKDIxKSBYKDMwKSBYKDMxKSBYKDMyKSBYKDMzKSBYKDM0KQorICAgICAg ICBYKDM1KSBYKDM2KSBYKDM3KSBYKDM4KSBYKDM5KSBYKDQwKSBYKDQxKSBYKDQyKSBYKDQzKSBY KDQ0KSBYKDQ1KSBYKDQ2KQorICAgICAgICBYKDQ3KSBYKDQ4KSBYKDQ5KSBYKDU4KSBYKDc0KSBY KDgwKSBYKDk5KSBYKDExNykgWCgxMTgpIFgoMTE5KSBYKDEyMCkKKyAgICAgICAgWCgxMjEpIFgo MTIzKSBYKDEyNykgWCgxMjgpIFgoMTI5KSBYKDEzNCkgWCgxMzkpIFgoMTQwKSBYKDE1OSkgWCgx NjQpCisgICAgICAgIFgoMTY1KSBYKDE2NikgWCgxNjcpIFgoMTY4KSBYKDE2OSkgWCgxNzApIFgo MTcxKSBYKDE3MikgWCgxNzMpIFgoMTc0KQorICAgICAgICBYKDE3NSkgWCgxNzYpIFgoMTc3KSBY KDE3OCkgWCgxNzkpIFgoMTgwKSBYKDE4MSkgWCgxODIpIFgoMTgzKSBYKDE4NCkKKyAgICAgICAg WCgxODUpIFgoMTg2KSBYKDE4NykgWCgxODgpIFgoMTg5KSBYKDE5MCkgWCgxOTEpIFgoMTkyKSBY KDE5MykgWCgxOTQpCisgICAgICAgIFgoMTk1KSBYKDE5NikgWCgxOTcpIFgoMTk4KSBYKDE5OSkg WCgyMDApIFgoMjAxKSBYKDIwMikgWCgyMDMpIFgoMjA0KQorICAgICAgICBYKDIwNSkgWCgyMDYp IFgoMjA3KSBYKDIwOCkgWCgyMDkpIFgoMjEwKSBYKDIxMSkgWCgyMTIpIFgoMjEzKSBYKDIxNCkK KyAgICAgICAgWCgyMTUpIFgoMjE2KSBYKDIxNykgWCgyMTgpIFgoMjE5KSBYKDIyMCkgWCgyMjEp IFgoMjIyKSBYKDIyMykgWCgyMjQpCisgICAgICAgIFgoMjI1KSBYKDIyNikgWCgyMjcpIFgoMjI4 KSBYKDIyOSkgWCgyMzApIFgoMjMxKSBYKDIzMikgWCgyMzMpIFgoMjM0KQorICAgICAgICBYKDIz NSkgWCgyMzYpIFgoMjM3KSBYKDIzOCkgWCgyMzkpIFgoMjQwKSBYKDI0MSkgWCgyNDIpIFgoMjQz KSBYKDI0NCkKKyAgICAgICAgWCgyNDUpIFgoMjQ2KSBYKDI0NykgWCgyNDgpIFgoMjQ5KSBYKDI1 MCkgWCgyNTEpIFgoMjUyKSBYKDI1MykgWCgyNTQpCisgICAgICAgIFgoMjU1KSAKKyN1bmRlZiBY CisjZW5kaWYKICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLAogICAgICAgICAgICAgICAgICJY WFggbGluZW5vOiAlZCwgb3Bjb2RlOiAlZFxuIiwKICAgICAgICAgICAgICAgICBQeUZyYW1lX0dl dExpbmVOdW1iZXIoZiksCg== 9460 2021-06-29 20:15:31 +0300 2021-06-29 20:15:31 +0300 python3.9.5-e2k-plus10.patch python3.9.5-e2k-plus10.patch text/plain 2499 ilyakurdyukov ZGlmZiAtLWdpdCBhL1B5dGhvbi9jZXZhbC5jIGIvUHl0aG9uL2NldmFsLmMKaW5kZXggOTFlODc5 ZS4uZTZhZmZhMiAxMDA2NDQKLS0tIGEvUHl0aG9uL2NldmFsLmMKKysrIGIvUHl0aG9uL2NldmFs LmMKQEAgLTEwNDYsOSArMTA0NiwzNiBAQCBfUHlFdmFsX0V2YWxGcmFtZURlZmF1bHQoUHlUaHJl YWRTdGF0ZSAqdHN0YXRlLCBQeUZyYW1lT2JqZWN0ICpmLCBpbnQgdGhyb3dmbGFnKQogCiAjZWxz ZQogI2RlZmluZSBUQVJHRVQob3ApIG9wCisjaWZkZWYgX19lMmtfXworI2lmZGVmIExMVFJBQ0UK KyNkZWZpbmUgTk9fTExUUkFDRSAhbGx0cmFjZSAmJgorI2Vsc2UKKyNkZWZpbmUgTk9fTExUUkFD RSAxCisjZW5kaWYKKworI2RlZmluZSBGQVNUX0RJU1BBVENIKCkgXAorICAgIHsgXAorICAgICAg ICBpZiAoTk9fTExUUkFDRSAmJiAhX1B5X1RyYWNpbmdQb3NzaWJsZShjZXZhbDIpICYmICFQeURU cmFjZV9MSU5FX0VOQUJMRUQoKSkgeyBcCisgICAgICAgICAgICBmLT5mX2xhc3RpID0gSU5TVFJf T0ZGU0VUKCk7IFwKKyAgICAgICAgICAgIE5FWFRPUEFSRygpOyBcCisgICAgICAgICAgICBnb3Rv IHN3aXRjaF9sb29wOyBcCisgICAgICAgIH0gXAorICAgICAgICBnb3RvIGZhc3RfbmV4dF9vcGNv ZGU7IFwKKyAgICB9CisKKyNkZWZpbmUgRElTUEFUQ0goKSBcCisgICAgeyBcCisgICAgICAgIGlm ICghX1B5X2F0b21pY19sb2FkX3JlbGF4ZWQoZXZhbF9icmVha2VyKSkgeyBcCisgICAgICAgICAg ICBGQVNUX0RJU1BBVENIKCk7IFwKKyAgICAgICAgfSBcCisgICAgICAgIGNvbnRpbnVlOyBcCisg ICAgfQorCisjZWxzZQogI2RlZmluZSBGQVNUX0RJU1BBVENIKCkgZ290byBmYXN0X25leHRfb3Bj b2RlCiAjZGVmaW5lIERJU1BBVENIKCkgY29udGludWUKICNlbmRpZgorI2VuZGlmCiAKIAogLyog VHVwbGUgYWNjZXNzIG1hY3JvcyAqLwpAQCAtMTQ2MSw2ICsxNDg4LDkgQEAgbWFpbl9sb29wOgog ICAgICAgICB9CiAjZW5kaWYKIAorI2lmZGVmIF9fZTJrX18KK3N3aXRjaF9sb29wOgorI2VuZGlm CiAgICAgICAgIHN3aXRjaCAob3Bjb2RlKSB7CiAKICAgICAgICAgLyogQkVXQVJFIQpAQCAtMzcx Miw2ICszNzQyLDI2IEBAIG1haW5fbG9vcDoKICAgICAgICAgX3Vua25vd25fb3Bjb2RlOgogI2Vu ZGlmCiAgICAgICAgIGRlZmF1bHQ6CisjaWZkZWYgX19lMmtfXworICAgICAgICAgICAgUHlfVU5S RUFDSEFCTEUoKTsKKyAgICAgICAgLyogJCBhd2sgJy91bmtub3duX29wY29kZS97cHJpbnQgIlgo IiBOUi0yICIpIn0nIG9wY29kZV90YXJnZXRzLmggKi8KKyNkZWZpbmUgWChpKSBjYXNlIGk6Cisg ICAgICAgIFgoMCkgWCg3KSBYKDgpIFgoMTMpIFgoMTQpIFgoMTgpIFgoMjEpIFgoMzApIFgoMzEp IFgoMzIpIFgoMzMpIFgoMzQpCisgICAgICAgIFgoMzUpIFgoMzYpIFgoMzcpIFgoMzgpIFgoMzkp IFgoNDApIFgoNDEpIFgoNDIpIFgoNDMpIFgoNDQpIFgoNDUpIFgoNDYpCisgICAgICAgIFgoNDcp IFgoNTMpIFgoNTgpIFgoODApIFgoODEpIFgoODgpIFgoOTkpIFgoMTE5KSBYKDEyMCkgWCgxMjMp IFgoMTI3KQorICAgICAgICBYKDEyOCkgWCgxMjkpIFgoMTM0KSBYKDEzOSkgWCgxNDApIFgoMTQ5 KSBYKDE1MCkgWCgxNTEpIFgoMTUyKSBYKDE1MykKKyAgICAgICAgWCgxNTgpIFgoMTU5KSBYKDE2 NikgWCgxNjcpIFgoMTY4KSBYKDE2OSkgWCgxNzApIFgoMTcxKSBYKDE3MikgWCgxNzMpCisgICAg ICAgIFgoMTc0KSBYKDE3NSkgWCgxNzYpIFgoMTc3KSBYKDE3OCkgWCgxNzkpIFgoMTgwKSBYKDE4 MSkgWCgxODIpIFgoMTgzKQorICAgICAgICBYKDE4NCkgWCgxODUpIFgoMTg2KSBYKDE4NykgWCgx ODgpIFgoMTg5KSBYKDE5MCkgWCgxOTEpIFgoMTkyKSBYKDE5MykKKyAgICAgICAgWCgxOTQpIFgo MTk1KSBYKDE5NikgWCgxOTcpIFgoMTk4KSBYKDE5OSkgWCgyMDApIFgoMjAxKSBYKDIwMikgWCgy MDMpCisgICAgICAgIFgoMjA0KSBYKDIwNSkgWCgyMDYpIFgoMjA3KSBYKDIwOCkgWCgyMDkpIFgo MjEwKSBYKDIxMSkgWCgyMTIpIFgoMjEzKQorICAgICAgICBYKDIxNCkgWCgyMTUpIFgoMjE2KSBY KDIxNykgWCgyMTgpIFgoMjE5KSBYKDIyMCkgWCgyMjEpIFgoMjIyKSBYKDIyMykKKyAgICAgICAg WCgyMjQpIFgoMjI1KSBYKDIyNikgWCgyMjcpIFgoMjI4KSBYKDIyOSkgWCgyMzApIFgoMjMxKSBY KDIzMikgWCgyMzMpCisgICAgICAgIFgoMjM0KSBYKDIzNSkgWCgyMzYpIFgoMjM3KSBYKDIzOCkg WCgyMzkpIFgoMjQwKSBYKDI0MSkgWCgyNDIpIFgoMjQzKQorICAgICAgICBYKDI0NCkgWCgyNDUp IFgoMjQ2KSBYKDI0NykgWCgyNDgpIFgoMjQ5KSBYKDI1MCkgWCgyNTEpIFgoMjUyKSBYKDI1MykK KyAgICAgICAgWCgyNTQpIFgoMjU1KQorI3VuZGVmIFgKKyNlbmRpZgogICAgICAgICAgICAgZnBy aW50ZihzdGRlcnIsCiAgICAgICAgICAgICAgICAgIlhYWCBsaW5lbm86ICVkLCBvcGNvZGU6ICVk XG4iLAogICAgICAgICAgICAgICAgIFB5RnJhbWVfR2V0TGluZU51bWJlcihmKSwK 9464 2021-06-30 15:14:15 +0300 2021-06-30 15:14:15 +0300 fannkuch.py fannkuch.py text/x-python 3425 ilyakurdyukov IyBUaGUgQ29tcHV0ZXIgTGFuZ3VhZ2UgQmVuY2htYXJrcyBHYW1lCiMgaHR0cDovL2JlbmNobWFy a3NnYW1lLmFsaW90aC5kZWJpYW4ub3JnLwojCiMgY29udHJpYnV0ZWQgYnkgSm9lcmcgQmF1bWFu bgojIG1hbnkgdGhhbmtzIHRvIE9sZWcgTWF6dXJvdiBmb3IgaGlzIGhlbHBmdWwgZGVzY3JpcHRp b24KCmZyb20gc3lzIGltcG9ydCBhcmd2CmZyb20gbWF0aCBpbXBvcnQgZmFjdG9yaWFsCmZyb20g bXVsdGlwcm9jZXNzaW5nIGltcG9ydCBjcHVfY291bnQsIFBvb2wKZnJvbSBpdGVydG9vbHMgaW1w b3J0IGlzbGljZSwgc3Rhcm1hcAoKZGVmIHBlcm11dGF0aW9ucyhuLCBzdGFydCwgc2l6ZSk6CiAg ICBwID0gYnl0ZWFycmF5KHJhbmdlKG4pKQogICAgY291bnQgPSBieXRlYXJyYXkobikKCiAgICBy ZW1haW5kZXIgPSBzdGFydAogICAgZm9yIHYgaW4gcmFuZ2UobiAtIDEsIDAsIC0xKToKICAgICAg ICBjb3VudFt2XSwgcmVtYWluZGVyID0gZGl2bW9kKHJlbWFpbmRlciwgZmFjdG9yaWFsKHYpKQog ICAgICAgIGZvciBfIGluIHJhbmdlKGNvdW50W3ZdKToKICAgICAgICAgICAgcFs6dl0sIHBbdl0g PSBwWzE6diArIDFdLCBwWzBdCgogICAgYXNzZXJ0KGNvdW50WzFdID09IDApCiAgICBhc3NlcnQo c2l6ZSA8IDIgb3IgKHNpemUgJSAyID09IDApKQoKICAgIGlmIHNpemUgPCAyOgogICAgICAgIHlp ZWxkIHBbOl0KICAgIGVsc2U6CiAgICAgICAgcm90YXRpb25fc3dhcHMgPSBbTm9uZV0gKiBuCiAg ICAgICAgZm9yIGkgaW4gcmFuZ2UoMSwgbik6CiAgICAgICAgICAgIHIgPSBsaXN0KHJhbmdlKG4p KQogICAgICAgICAgICBmb3IgdiBpbiByYW5nZSgxLCBpICsgMSk6CiAgICAgICAgICAgICAgICBy Wzp2XSwgclt2XSA9IHJbMTp2ICsgMV0sIHJbMF0KICAgICAgICAgICAgc3dhcHMgPSBbXQogICAg ICAgICAgICBmb3IgZHN0LCBzcmMgaW4gZW51bWVyYXRlKHIpOgogICAgICAgICAgICAgICAgaWYg ZHN0ICE9IHNyYzoKICAgICAgICAgICAgICAgICAgICBzd2Fwcy5hcHBlbmQoKGRzdCwgc3JjKSkK ICAgICAgICAgICAgcm90YXRpb25fc3dhcHNbaV0gPSB0dXBsZShzd2FwcykKCiAgICAgICAgd2hp bGUgVHJ1ZToKICAgICAgICAgICAgeWllbGQgcFs6XQogICAgICAgICAgICBwWzBdLCBwWzFdID0g cFsxXSwgcFswXQogICAgICAgICAgICB5aWVsZCBwWzpdCiAgICAgICAgICAgIGkgPSAyCiAgICAg ICAgICAgIHdoaWxlIGNvdW50W2ldID49IGk6CiAgICAgICAgICAgICAgICBjb3VudFtpXSA9IDAK ICAgICAgICAgICAgICAgIGkgKz0gMQogICAgICAgICAgICBlbHNlOgogICAgICAgICAgICAgICAg Y291bnRbaV0gKz0gMQogICAgICAgICAgICAgICAgdCA9IHBbOl0KICAgICAgICAgICAgICAgIGZv ciBkc3QsIHNyYyBpbiByb3RhdGlvbl9zd2Fwc1tpXToKICAgICAgICAgICAgICAgICAgICBwW2Rz dF0gPSB0W3NyY10KCmRlZiBhbHRlcm5hdGluZ19mbGlwc19nZW5lcmF0b3Iobiwgc3RhcnQsIHNp emUpOgogICAgbWF4aW11bV9mbGlwcyA9IDAKICAgIGFsdGVybmF0aW5nX2ZhY3RvciA9IDEKICAg IGZvciBwZXJtdXRhdGlvbiBpbiBpc2xpY2UocGVybXV0YXRpb25zKG4sIHN0YXJ0LCBzaXplKSwg c2l6ZSk6CiAgICAgICAgZmlyc3QgPSBwZXJtdXRhdGlvblswXQogICAgICAgIGlmIGZpcnN0Ogog ICAgICAgICAgICBmbGlwc19jb3VudCA9IDEKICAgICAgICAgICAgd2hpbGUgVHJ1ZToKICAgICAg ICAgICAgICAgIHBlcm11dGF0aW9uWzpmaXJzdCArIDFdID0gcGVybXV0YXRpb25bZmlyc3Q6Oi0x XQogICAgICAgICAgICAgICAgZmlyc3QgPSBwZXJtdXRhdGlvblswXQogICAgICAgICAgICAgICAg aWYgbm90IGZpcnN0OiBicmVhawogICAgICAgICAgICAgICAgZmxpcHNfY291bnQgKz0gMQogICAg ICAgICAgICBpZiBtYXhpbXVtX2ZsaXBzIDwgZmxpcHNfY291bnQ6CiAgICAgICAgICAgICAgICBt YXhpbXVtX2ZsaXBzID0gZmxpcHNfY291bnQKICAgICAgICAgICAgeWllbGQgZmxpcHNfY291bnQg KiBhbHRlcm5hdGluZ19mYWN0b3IKICAgICAgICBlbHNlOgogICAgICAgICAgICB5aWVsZCAwCiAg ICAgICAgYWx0ZXJuYXRpbmdfZmFjdG9yID0gLWFsdGVybmF0aW5nX2ZhY3RvcgogICAgeWllbGQg bWF4aW11bV9mbGlwcwoKZGVmIHRhc2sobiwgc3RhcnQsIHNpemUpOgogICAgYWx0ZXJuYXRpbmdf ZmxpcHMgPSBhbHRlcm5hdGluZ19mbGlwc19nZW5lcmF0b3Iobiwgc3RhcnQsIHNpemUpCiAgICBy ZXR1cm4gc3VtKGlzbGljZShhbHRlcm5hdGluZ19mbGlwcywgc2l6ZSkpLCBuZXh0KGFsdGVybmF0 aW5nX2ZsaXBzKQoKZGVmIGZhbm5rdWNoKG4pOgogICAgaWYgbiA8IDA6CiAgICAgICAgZm9yIGRh dGEgaW4gaXNsaWNlKHBlcm11dGF0aW9ucygtbiwgMCwgZmFjdG9yaWFsKC1uKSksIGZhY3Rvcmlh bCgtbikpOgogICAgICAgICAgICBwcmludCgnJy5qb2luKG1hcChsYW1iZGEgbjogc3RyKG4gKyAx KSwgZGF0YSkpKQogICAgZWxzZToKICAgICAgICBhc3NlcnQobiA+IDApCgogICAgICAgIGlmIGxl bihhcmd2KSA+IDI6CiAgICAgICAgICAgIHRhc2tfY291bnQgPSBpbnQoYXJndlsyXSkKICAgICAg ICAgICAgdG90YWwgPSBmYWN0b3JpYWwobikKICAgICAgICAgICAgdGFza19zaXplID0gKHRvdGFs ICsgdGFza19jb3VudCAtIDEpIC8vIHRhc2tfY291bnQKCiAgICAgICAgZWxzZToKICAgICAgICAg ICAgdGFza19jb3VudCA9IGNwdV9jb3VudCgpCiAgICAgICAgICAgIHRvdGFsID0gZmFjdG9yaWFs KG4pCiAgICAgICAgICAgIHRhc2tfc2l6ZSA9ICh0b3RhbCArIHRhc2tfY291bnQgLSAxKSAvLyB0 YXNrX2NvdW50CgogICAgICAgICAgICBpZiB0YXNrX3NpemUgPCAyMDAwMDoKICAgICAgICAgICAg ICAgIHRhc2tfc2l6ZSA9IHRvdGFsCiAgICAgICAgICAgICAgICB0YXNrX2NvdW50ID0gMQoKICAg ICAgICAgICAgYXNzZXJ0KHRhc2tfc2l6ZSAlIDIgPT0gMCkKCiAgICAgICAgdGFza19hcmdzID0g WyhuLCBpICogdGFza19zaXplLCB0YXNrX3NpemUpIGZvciBpIGluIHJhbmdlKHRhc2tfY291bnQp XQoKICAgICAgICBpZiB0YXNrX2NvdW50ID4gMToKICAgICAgICAgICAgd2l0aCBQb29sKCkgYXMg cG9vbDoKICAgICAgICAgICAgICAgIGNoZWNrc3VtcywgbWF4aW11bXMgPSB6aXAoKnBvb2wuc3Rh cm1hcCh0YXNrLCB0YXNrX2FyZ3MpKQogICAgICAgIGVsc2U6CiAgICAgICAgICAgIGNoZWNrc3Vt cywgbWF4aW11bXMgPSB6aXAoKnN0YXJtYXAodGFzaywgdGFza19hcmdzKSkKCiAgICAgICAgY2hl Y2tzdW0sIG1heGltdW0gPSBzdW0oY2hlY2tzdW1zKSwgbWF4KG1heGltdW1zKQogICAgICAgIHBy aW50KCJ7MH1cblBmYW5ua3VjaGVuKHsxfSkgPSB7Mn0iLmZvcm1hdChjaGVja3N1bSwgbiwgbWF4 aW11bSkpCgppZiBfX25hbWVfXyA9PSAiX19tYWluX18iOgogICAgZmFubmt1Y2goaW50KGFyZ3Zb MV0pKQo=