Bug 40278 - В python3-base задаются заведомо неоптимальные флаги сборки
Summary: В python3-base задаются заведомо неоптимальные флаги сборки
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: python3-base (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Grigory Ustinov
QA Contact: qa-sisyphus
URL:
Keywords: regression
: 40750 (view as bug list)
Depends on: 39329
Blocks:
  Show dependency tree
 
Reported: 2021-06-24 14:34 MSK by Michael Shigorin
Modified: 2023-06-02 05:20 MSK (History)
10 users (show)

See Also:


Attachments
fannkuch.py (3.15 KB, text/x-python)
2021-06-24 16:24 MSK, ilyakurdyukov
no flags Details
python3.8.1-e2k-plus10.patch (2.41 KB, patch)
2021-06-29 20:12 MSK, ilyakurdyukov
no flags Details | Diff
python3.9.5-e2k-plus10.patch (2.44 KB, patch)
2021-06-29 20:15 MSK, ilyakurdyukov
no flags Details | Diff
fannkuch.py (3.34 KB, text/x-python)
2021-06-30 15:14 MSK, ilyakurdyukov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Shigorin 2021-06-24 14:34:05 MSK
+++ Данная ошибка создана размножением ошибки 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
Comment 1 ilyakurdyukov 2021-06-24 16:24: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 на Эльбрусе пока невозможно, нужно делать какие-то хаки для компилятора, потому что сбор профиля падает с ошибкой.
Comment 2 ilyakurdyukov 2021-06-25 15:54:22 MSK
И еще нашел две проблемы:

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
Comment 3 Michael Shigorin 2021-06-26 10:59:44 MSK
(Ответ для ilyakurdyukov на комментарий #2)
> И еще нашел две проблемы:
Новые проблемы, не связанные с темой бага, лучше вешать новыми багами,
чтобы каждый баг имел чёткий критерий, по которому он (не) решён.
За тест спасибо :-)
Comment 4 Grigory Ustinov 2021-06-26 11:06:50 MSK
Да, по поводу valgrind и shared хотел разобраться, но руки не дошли. Спасибо. Оформите отдельные баги, если не сложно, как указал mike@ чуть выше.

Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи мало кого интересуют.
Comment 5 Vitaly Lipatov 2021-06-27 01:37:48 MSK
(Ответ для Grigory Ustinov на комментарий #4)
...
> Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и
> ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи
> мало кого интересуют.
Возможно, в изменения по bug 39329 вкралась ошибка, и действительно в сборке участвует -O2 вне зависимости от указанного в %optflags.
Мы на gcc это можем не замечать, а вот на Эльбрусе заметили, потому что у них -O3 в %optflags.
Если получится убрать прибитый -O2 в пользу %optflags, было бы здорово.
Comment 6 ilyakurdyukov 2021-06-29 15:18:34 MSK
valgrind и дублированную shared сборку исправили, теперь что с этой опцией ставящей -O2?

Во первых и сама сборка проекта ставит -O3, и даже -O3 был явно задан в пакете:

> PS: -O3 гвоздиком же прибил vitty@ в 3.2.2-alt4:

Что игнорируется патчем. Я считаю что патч нужно откатить совсем, а не гнаться за непонятной красотой в логах. Мало того, этот патч еще отключал отладочную информацию (-g).

Что я могу сам сделать, вместе с включением --enable-optimizations, и доработками для Эльбруса.
Comment 7 Grigory Ustinov 2021-06-29 16:14:13 MSK
Я не понимаю, что от меня хотят. На нормальной архитектуре разница между O2 и O3 не заметна.

То есть мне бы хотелось понимать, что нужно сделать:
а. откатить все изменения по поводу флагов полностью
б. оставить как есть
в. сделать что-то промежуточное
Comment 8 ilyakurdyukov 2021-06-29 16:33:26 MSK
Предлагаю удалить эти строки из спека:

 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.
Comment 9 Grigory Ustinov 2021-06-29 16:48:56 MSK
Принято.
Comment 10 ilyakurdyukov 2021-06-29 19:24:37 MSK
Изменения на ревью:

http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git

А мне еще проверить надо, что в новой версии всё работает (завершу уже завтра).
Comment 11 Grigory Ustinov 2021-06-29 19:56:01 MSK
Во-первых,

+%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) и этот баг закроется после того, как таск закоммитится.
Comment 12 ilyakurdyukov 2021-06-29 20:12:35 MSK
Created attachment 9459 [details]
python3.8.1-e2k-plus10.patch
Comment 13 ilyakurdyukov 2021-06-29 20:15:31 MSK
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 выражения фактически делают то же самое, только менее красиво, зато автоматически.
Comment 14 Yuri N. Sedunov 2021-06-29 20:33:04 MSK
(Ответ для ilyakurdyukov на комментарий #13)
> То что заменяет этот патч - понятно. Остальное непонятное - сделано так по
> той причине, что мелкие правки от разработчиков питона будут часто ломать
> патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при
> добавлении или удалении любого нового опкода в интерпретаторе - патч нужно
> будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что
> удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы
> добавить патч для Эльбруса в сизиф.

Еще можно оформить этот набор sed-awk выражений в отдельный скрипт и использовать для генерации нового патча, когда текущий отвалится.
Comment 15 Grigory Ustinov 2021-06-29 20:36:57 MSK
(Ответ для 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
> выражения фактически делают то же самое, только менее красиво, зато
> автоматически.

Холивар "патчи против регулярок" длится уже давно, я не хочу в нём участвовать.
Comment 16 ilyakurdyukov 2021-06-30 06:08:01 MSK
Если хочется сделать красиво, то можно сделать так:

%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. Для чего вероятно, нужно знать в какой ассемблер компилятор превращает то и другое.
Comment 17 ilyakurdyukov 2021-06-30 06:48:34 MSK
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.
Comment 18 Grigory Ustinov 2021-06-30 08:38:24 MSK
> Вы думаете, что всё это должно быть написано в комментариях в спеке? Для любопытных я могу оставить номер бага.

Да, пожалуй.

Выглядит оно мощно!
Comment 19 ilyakurdyukov 2021-06-30 09:43:37 MSK
Обновил: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git

> можно было бы просто сделать через git revert

git revert не справился, потому что рядом были изменения. Так что сделал вручную, благо правки небольшие.
Comment 20 Vitaly Lipatov 2021-06-30 10:32:17 MSK
(Ответ для 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 для этой фичи?
Comment 21 ilyakurdyukov 2021-06-30 10:35:49 MSK
Таки почему-то локальная 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 так что и список бы не помог.
Comment 22 ilyakurdyukov 2021-06-30 15:14:15 MSK
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
Comment 23 Grigory Ustinov 2021-06-30 15:27:26 MSK
(Ответ для ilyakurdyukov на комментарий #22)
> Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, чем
> годами поддерживать этот патч. Который еще и static билд ломает, а значит
> вредительский.

Гораздо проще ничего не менять, если никому не мешает=) Золотое правило мастера "не чини то, что работает".

> 
> Различия же в производительности static билда очень ощутимые (на 25%
> быстрее). Почему так происходит - я не знаю. Но я думаю, что ради этого
> стоит откатить патч из Федоры, его необходимость для меня сомнительна.
> Возможно патч сломался после каких-то изменений в питоне.

Предлагаю подобные отдельные ветви обсуждений выносить в отдельные баги, чтобы не потерялось и чтобы не путаться в обсуждениях.
Comment 24 ilyakurdyukov 2021-06-30 16:44:10 MSK
Итак, вот коммиты, которыми я вроде бы починил все найденные проблемы с производительностью:

http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git

Еще у меня есть подозрения что --with-valgrind может негативно влиять, но видимо эта разница небольшая, я проверяю на basalt, которая еще и как шлюз используется и на ней есть небольшая фоновая нагрузка. Но разница между static и shared точно вызвана не флуктуациями загрузки, так как очень значительная.

Требуются тестеры для сравнения 3.9.6-alt1 и этого кандидата в 3.9.6-alt2. Можете использовать приложенный к багу fannkuch.py и другие вычислительные тесты, что найдёте.
Comment 25 ilyakurdyukov 2021-06-30 18:02:34 MSK
Посоветовали: 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
Comment 26 ilyakurdyukov 2021-07-01 04:06:08 MSK
Вчера проверял, но вне hasher:

export CFLAGS_NODIST="-fno-semantic-interposition"
export LDFLAGS_NODIST="-fno-semantic-interposition"

Перед configure - делает shared билд почти таким же быстрым как static. Почти потому, что на 3% у меня вышло медленнее, непонятно, наводка ли это от системных процессов или действительно медленнее.

На Эльбрусе же такая опция не поддерживается.

Так что, если хотите shared билд - могу сделать для Эльбруса static, для всех остальных с этой опцией.
Comment 27 Ivan Zakharyaschev 2021-07-01 13:18:25 MSK
(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, лучше не тащить, потому что с ним больше труда для мейнтейнера.
Comment 28 Ivan Zakharyaschev 2021-07-01 13:37:52 MSK
(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.)
Comment 29 ilyakurdyukov 2021-07-01 13:51:01 MSK
> На 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.)
Пока широкой розничной доступности не будет - это проблема. Потому что зарубежному апстриму негде взять железо для проверки патчей.
Comment 30 Ivan Zakharyaschev 2021-07-01 14:06:53 MSK
(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 независимо от наличия этого флага.)
Comment 31 Ivan Zakharyaschev 2021-07-01 14:09:43 MSK
(In reply to ilyakurdyukov from comment #29)

> > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.)
> Пока широкой розничной доступности не будет - это проблема. Потому что
> зарубежному апстриму негде взять железо для проверки патчей.

Но патч без кода, а просто делающий выбор опций в зависимости от моедли компилятора могут и принять без тестирования. Есть подобные (и не совсем) патчи ради компиляции на e2k, принятые в другие upstream-ы.
Comment 32 ilyakurdyukov 2021-07-01 14:22:27 MSK
Для понимания что такое -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.

Попросил МЦСТ чтобы добавили такую опцию.
Comment 33 ilyakurdyukov 2021-07-02 10:36:40 MSK
Хорошо бы не затягивать с исправлением производительности. Чтобы в 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)
Comment 34 Grigory Ustinov 2021-07-02 12:26:03 MSK
(Ответ для ilyakurdyukov на комментарий #33)
> Хорошо бы не затягивать с исправлением производительности. Чтобы в p10 ушла
> быстрая версия.
> 
> Такое уже бывало? На других архитектурах не было ошибки.

Нет, это что-то новенькое.
Comment 35 ilyakurdyukov 2021-07-02 17:30:46 MSK
Отключил PGO для armh, теперь собралось везде.

http://git.altlinux.org/tasks/276773/logs/events.1.1.log

Падение на том тесте не случайное, повторно воспроизводилось. Видимо компилятор переоптимизировал, возможно баг компилятора.
Comment 36 Ivan Zakharyaschev 2021-07-06 17:34:44 MSK
(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 ~]$
Comment 37 ilyakurdyukov 2021-07-06 17:44:36 MSK
> Теперь, когда интерпретатор собран статически, часть пакетов (возможно)
> ошибочно динамически линкует модули с libpython3.9.so.1.0.

Дело в том, что там давно висел патч из Федоры, который статическую либу просто не собирал. Теперь либа собирается, но чтобы сохранить старое поведение, в пакет она не идёт:

%files -n libpython3
%_libdir/libpython%pybasever%pyabi.so.*
%exclude %_libdir/libpython%pybasever%pyabi.a

Кстати, динамическую либу лучше собирать с тем самым флагом, чтобы была несколько быстрее.
Comment 38 ilyakurdyukov 2021-07-06 18:03:17 MSK
Если питон используется из библиотек, то должен линковаться с библиотекой. Очевидно что при линковке с динамической должно занимать меньше места. Я не знаю сколько будет тянуть статическая линковка, возможно что несколько мегабайт. Не останется ли старый питон в статически слинкованных модулях при обновлении системного?

В Убунту я вижу статический бинарник и динамическую либу.
Comment 39 Ivan Zakharyaschev 2021-07-07 01:34:16 MSK
(Ответ для ilyakurdyukov на комментарий #38)
> Если питон используется из библиотек, то должен линковаться с библиотекой.
> Очевидно что при линковке с динамической должно занимать меньше места. Я не
> знаю сколько будет тянуть статическая линковка, возможно что несколько
> мегабайт. Не останется ли старый питон в статически слинкованных модулях при
> обновлении системного?
> 
> В Убунту я вижу статический бинарник и динамическую либу.

Нет, я несколько другое имел в виду. Всё нормально, если в ELF-е (чаще исполняемой программе как gdb или gimp какой-нибудь, но может, и в библиотеке) нужен интерпретатор для расширений на питоне, и тогда динамически прилинкована библиотека libpython3.

Но есть бинарные модули для питона. (Они используют ABI питона, предоставляемое как библиотекой libpython3, так и standalone интерпретатором, неважно как слинкованным: статически или динамически). Собственно, способ который всегда работает -- оставить модуль недолинкованым с libpython3, тогда он без проблем загрузится при обоих способах и ld.so не будет автоматически подгружать libpython3 (что может вызвать бабах при загрузке изнутри статически слинкованного интерпретатора).

Есть подозрение, что в этом списке появились модули, которые ошибочно линкуются с libpython3 вместо недолиновки (что было принято в ALT-е раньше, пока не собрали python3 динамически). Попробую найти в списке пример для демонстрации.
Comment 40 ilyakurdyukov 2021-07-07 05:57:18 MSK
Тогда это и правда может быть проблемой. Хотя скорее всего работать будет, просто будет два питона подгружаться.

Статик билд был добавлен: 3.2.2-alt4 28 Mar 2012

Заменён на shared: 3.6.4-alt1 3 Apr 2018

Как линковались эти модули в этом промежутке?
Comment 41 ilyakurdyukov 2021-07-07 06:04:06 MSK
Если модуль будет недолинкован, то каким образом система будет знать, что нужно будет подгрузить libpython?

А при загрузке из статического питона - питон должен перекрыть все экспортируемые символы из библиотеки. Могут ли они перемешаться - не знаю. Лучше посмотреть как до 2018-го работало.
Comment 42 Michael Shigorin 2021-07-29 09:17:02 MSK
Коллеги, если всё скопом забрать у Ильи сперва в сизиф, затем в 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-ы.

Подтверждаю; и ради оптимизации -- тоже.
Comment 43 Grigory Ustinov 2021-08-17 11:46:39 MSK
*** Bug 40750 has been marked as a duplicate of this bug. ***
Comment 44 Grigory Ustinov 2021-08-17 11:48:42 MSK
ping ilyakurdyukov

Что там новенького?
Comment 45 ilyakurdyukov 2021-08-17 12:35:05 MSK
(Ответ для Grigory Ustinov на комментарий #44)
> ping ilyakurdyukov
> 
> Что там новенького?

Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и не собирается.
Comment 46 Grigory Ustinov 2021-08-17 13:35:42 MSK
(Ответ для ilyakurdyukov на комментарий #45)
> (Ответ для Grigory Ustinov на комментарий #44)
> > ping ilyakurdyukov
> > 
> > Что там новенького?
> 
> Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и
> не собирается.

Насколько я понял, мы остановились на таске 276773. Комментарий 35.

С того момента были "озвучены" пожелания заинтересованных лиц. Вы хотели ревью, вы его получили. Теперь ваша очередь учесть эти пожелания и подготовить таск с опцией --commit. Потому что таск 276773 не упал с EPERM и никто из списка acl не может дать ему аппрув.

Я попробую в кратце повторить суть желаемого:
Давайте вынесем обсуждение статической линковки в отдельную багу и решим отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2) В этом релизе и так много очень хороших изменений, которым давно уже пора быть в сизифе.
Comment 47 ilyakurdyukov 2021-08-17 15:00:41 MSK
Я просил проверить этот билд. В итоге я так и не понял, со всеми ли плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас должно.

Запустил на коммит, чтобы был EPERM.

Если кто-то хочет всё растащить по отдельным багам - растаскивайте.
Comment 48 Ivan Zakharyaschev 2021-08-17 15:31:21 MSK
(Ответ для ilyakurdyukov на комментарий #47)
> Я просил проверить этот билд. В итоге я так и не понял, со всеми ли
> плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не
> опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас
> должно.
> 
> Запустил на коммит, чтобы был EPERM.
> 
> Если кто-то хочет всё растащить по отдельным багам - растаскивайте.

Я, к сожалению, не успел всё детально проверить, потому что оказался занят другим.
Comment 49 Ivan Zakharyaschev 2021-08-17 15:37:04 MSK
(Ответ для Grigory Ustinov на комментарий #46)

> Я попробую в кратце повторить суть желаемого:
> Давайте вынесем обсуждение статической линковки в отдельную багу и решим
> отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2)
> В этом релизе и так много очень хороших изменений, которым давно уже пора
> быть в сизифе.

На данном этапе, я считаю, хорошая мысль немного отложить статический билд, потому что менять требования к модулям, которые могут быть загружены, надо аккуратно, отслеживая этот интерфейс через формальные зависимости вроде python3.9-ABI (разделить эту на две: можно всякие модули грузить -- предоставляется питоном, собранным динамически с libpython; и нельзя динамически слинкованные модули грузить -- придётся новое завести для статической сборки).

А прочие улучшения можно сейчас собрать, ещё раз посмотреть всем заинтересованным и сообща одобрить.
Comment 50 ilyakurdyukov 2021-08-17 18:03:58 MSK
Ну и что всё это значит?

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] --
Comment 51 Grigory Ustinov 2021-08-17 19:16:57 MSK
(Ответ для 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

Я же попросил убрать оба коммита про статическую сборку, потому что они по смыслу идут вместе.
Comment 52 Ivan Zakharyaschev 2021-08-17 20:20:24 MSK
(Ответ для 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
Comment 53 Repository Robot 2021-08-18 03:14:21 MSK
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).
Comment 54 Ivan Zakharyaschev 2023-06-02 05:02:45 MSK
(Ответ для 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
$