ALT Linux Bugzilla – #20451

это NOTABUG, собственно. пересоберите codeblocks. поскольку версия wxGTK не изменилась, SONAME и все прочие пироги не изменились тоже.

API мог и не измениться, а вот ABI явно изменился.

тогда вопрос в том, что вызвало смену ABI в данном случае.

Поздравляю, у нас сломан binutils.

В wxGTK используется version-script.in следующего вида:

@WX_VERSION_TAG@.2 {
    global:
        # wxFileHistory::Set/GetBaseId()
        *wxFileHistory*etBaseId*;
        *wxSafeConvert*;
        *wxSearchCtrl*SetDescriptiveText*;
        *wxSearchCtrl*GetDescriptiveText*;
        *wxSizerFlags*Bottom*;
        *wxSizerFlags*FixedMinSize*;
        *wxSizerFlags*Shaped*;
        *wxSizerFlags*Top*;
        *wxToolBar*SetToolNormalBitmap;
        *wxToolBar*SetToolDisabledBitmap;
};
...
@WX_VERSION_TAG@ {
    global:
        *;
};

Т.е., части символов присваиваются версии вида WXU_2.8.2 (но при этом эти символы указываются через glob, чтобы не писать C++ mangled name), а для всех остальных через global: * указывается версия WXU_2.8. Однако где-то между binutils-2.18.50.0.9-alt5 и 2.19.51.0.2-alt2 этот механизм сломался - теперь все символы получают версию WXU_2.8 (хотя в таблицу версий WXU_2.8.2 всё-таки попадает, поэтому provides у пакета не отвалились).

Testcase:

$ cat libtest.c
int test(void) 
{
        return 1;
}

int test_new(void)
{
        return 2;
}

$ cat libtest.version 
TEST_1.0.1 {
        *new*;
};

TEST_1.0 {
        global: *;
};

$ gcc -c -fPIC libtest.c
$ ld -shared -o libtest.so -version-script libtest.version libtest.o

Со старой версией binutils получается:

$ objdump -T libtest.so |grep '\<test'
00000230 g    DF .text  0000000a  TEST_1.0    test
0000023a g    DF .text  0000000a  TEST_1.0.1  test_new

С новой версией:

$ LD_LIBRARY_PATH=./lib ./bin/ld -shared -o libtest.so -version-script libtest.version libtest.o
vsu@center4 ~/tmp/11 $ objdump -T libtest.so |grep '\<test'                                                          
00000230 g    DF .text  0000000a  TEST_1.0    test
0000023a g    DF .text  0000000a  TEST_1.0    test_new

Похоже, это побочный эффект исправления
http://sourceware.org/bugzilla/show_bug.cgi?id=7047

Теперь логика обработки glob pattern в version script изменилась - если имя символа соответствует нескольким шаблонам, раньше, похоже, брался первый из них, а теперь берётся последний (однако соответствия global более приоритетны, чем local, а точное соответствие имени (без glob) в любом случае имеет максимальный приоритет). В документации точное поведение ld в этом случае вновь обошли молчанием, добавив рекомендацию не использовать шаблоны в подобном случае:

| When the linker finds a symbol defined in a library which is not
| specifically bound to a version node, it will effectively bind it to an
| unspecified base version of the library.  You can bind all otherwise
| unspecified symbols to a given version node by using @samp{global: *;}
| somewhere in the version script.  Note that it's slightly crazy to use
| wildcards in a global spec except on the last version node.  Global
| wildcards elsewhere run the risk of accidentally adding symbols to the
| set exported for an old version.  That's wrong since older versions
| ought to have a fixed set of symbols.

(In reply to comment #5)
> Похоже, это побочный эффект исправления
> http://sourceware.org/bugzilla/show_bug.cgi?id=7047

Да, это именно он и есть.

> Теперь логика обработки glob pattern в version script изменилась - если имя
> символа соответствует нескольким шаблонам, раньше, похоже, брался первый из
> них, а теперь берётся последний (однако соответствия global более приоритетны,
> чем local, а точное соответствие имени (без glob) в любом случае имеет
> максимальный приоритет). В документации точное поведение ld в этом случае вновь
> обошли молчанием,

Alan Modra написал про это изменение следующее:
I don't try to provide any ordering between two matching wildcards, except that a match in a global specification has higher precedence than a local spec.  Otherwise, the last matching wildcard in the script wins.

Оборот речи "I don't try to provide any ordering" говорит о том, что поведение зависит от реализации и может измениться, если кто-нибудь ещё что-нибудь там исправит.

> добавив рекомендацию не использовать шаблоны в подобном
> случае:
> 
> | When the linker finds a symbol defined in a library which is not
> | specifically bound to a version node, it will effectively bind it to an
> | unspecified base version of the library.  You can bind all otherwise
> | unspecified symbols to a given version node by using @samp{global: *;}
> | somewhere in the version script.  Note that it's slightly crazy to use
> | wildcards in a global spec except on the last version node.  Global
> | wildcards elsewhere run the risk of accidentally adding symbols to the
> | set exported for an old version.  That's wrong since older versions
> | ought to have a fixed set of symbols.

Ну что, будем жаловаться "наверх" на incompatible change, или будем фиксить скрипты?

(В ответ на комментарий №6)
> Ну что, будем жаловаться "наверх" на incompatible change, или будем фиксить
> скрипты?

И как в данном случае это фиксить, чтобы результат работал и со старыми, и с новыми версиями binutils, и при этом не приходилось прибивать в скрипте все имена гвоздями (что в данном случае проблемно из-за C++ - насколько надёжно работает extern "C++" в version script с учётом возможности использования разных версий gcc?)?

отцы, так есть уже официально рекомендованный способ решения данной проблемы ? wxGTK и то, что от него зависит висит в разваленном состоянии.

(In reply to comment #7)
> (В ответ на комментарий №6)
> > Ну что, будем жаловаться "наверх" на incompatible change, или будем фиксить
> > скрипты?
> 
> И как в данном случае это фиксить, чтобы результат работал и со старыми, и с
> новыми версиями binutils, и при этом не приходилось прибивать в скрипте все
> имена гвоздями (что в данном случае проблемно из-за C++ - насколько надёжно
> работает extern "C++" в version script с учётом возможности использования
> разных версий gcc?)?

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

Created attachment 3743 [details]
ld_shared_wrapper.pl

Раз в binutils ничего не делается, видимо, придётся делать объезд со стороны wxGTK - например, подстановкой при сборке библиотек вместо g++ приложенного скрипта, который делает следующее:

1) Собирает библиотеку обычным образом во временный файл.
2) Извлекает из полученного временного файла список глобальных символов.
3) Используя этот список, заменяет шаблоны в version script на точный список символов, которые им соответствуют (остаётся в виде шаблона только "*", а также те шаблоны, для которых не найдено соответствий - иначе для некоторых версий могут получиться пустые секции, что ld считает ошибкой).
4) Собирает окончательный вариант библиотеки, используя модифицированный version script (кладётся в файл *.versions рядом с собранной библиотекой для проверки результатов работы).

Created attachment 3744 [details]
wxGTK-2.8.9-alt3.src.rpm.diff

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

wxGTK-2:2.8.10-alt2 -> sisyphus:

* Mon Aug 24 2009 Boris Savelev <boris@altlinux> 2:2.8.10-alt2

- Add workaround for new version script handling in binutils:
  expand symbol patterns in version scripts manually instead of relying on
  unstable binutins behavior (Sergey Vlasov) (closes #20451).

А можно получить пояснения, нуждается ли теперь в пересборке софт, слинкованный с wxGTK, который

а) перестал работать в результате этого бага?

б) перестал работать, но был пересобран с новой wxGTK, с тех пор работает?

(In reply to comment #13)
> А можно получить пояснения, нуждается ли теперь в пересборке софт, слинкованный
> с wxGTK, который

нуждается. весь.

(В ответ на комментарий №12)
>   unstable binutins behavior (Sergey Vlasov) (closes #20451).
Эх, опечатка пролезла :(

(В ответ на комментарий №13)
> А можно получить пояснения, нуждается ли теперь в пересборке софт,
> слинкованный с wxGTK, который
> 
> а) перестал работать в результате этого бага?
Не нуждается - теперь версии символов вернулись в первоначальное состояние. Я сравнивал символы wxGTK-2.8.9-alt1 и сборки со своим патчем - GLOBAL совпадают полностью, WEAK совпадают по версиям, но набор их поменялся (однако копии этих функций в любом случае будут и в бинарниках, реально их использующих, так что проблем из-за этого быть не должно).

> б) перестал работать, но был пересобран с новой wxGTK, с тех пор работает?
Вот это придётся опять пересобирать.

Гм. Значит я все прошедшие выходные копаюсь с переводом codeblocks, поскольку в
понедельник предполагают сделать RC школьного дистрибутива, а тут в Сизиф
въезжает бомба, ломающая весь wxGTK-софт, да?

Тогда либо нужно собирать RC сейчас, пока wxGTK не доехало до Сизифа, либо
пересобирать сразу же все пакеты...

В общем, прошу обратить внимание на проблему пересборки в свете предполагаемого
выхода RC.

(In reply to comment #16)
> Гм. Значит я все прошедшие выходные копаюсь с переводом codeblocks, поскольку в
> понедельник предполагают сделать RC школьного дистрибутива, а тут в Сизиф
> въезжает бомба, ломающая весь wxGTK-софт, да?

Не ломающая, а исправляющая.  Сломано было немного раньше.

> Тогда либо нужно собирать RC сейчас, пока wxGTK не доехало до Сизифа, либо
> пересобирать сразу же все пакеты...

RC лучше выпускать после изменения ABI, иначе релиз будет бинарно несовместим с RC по этим пакетам.

> В общем, прошу обратить внимание на проблему пересборки в свете предполагаемого
> выхода RC.

Давайте составим список пакетов, которые нужно пересобрать как можно быстрее.

> Не ломающая, а исправляющая.  Сломано было немного раньше.

Не суть - главное, что тот софт, который успели за последние 2,5 месяца пересобрать со сломанной wxGTK больше не работает.

> Давайте составим список пакетов, которые нужно пересобрать как можно быстрее.

codeblocks
poedit

Это из числа того, что отражено в зависимостях от этого бага.

(In reply to comment #18)
> > Не ломающая, а исправляющая.  Сломано было немного раньше.
> 
> Не суть - главное, что тот софт, который успели за последние 2,5 месяца
> пересобрать со сломанной wxGTK больше не работает.

Поскольку 2.5+ месяца назад софт тоже существовал, разнца всё же есть.

> > Давайте составим список пакетов, которые нужно пересобрать как можно быстрее.
> 
> codeblocks
> poedit
> 
> Это из числа того, что отражено в зависимостях от этого бага.

Можно попросить мантейнеров этих пакетов просто отправить пакеты на сборку?

codeblocks я могу отправить на пересборку прямо сейчас, наверное, надо
выставить requires на wxGTK >= 2.8.10-alt2

Нужно ли дожидаться, пока wxGTK доедет до сизифа, или можно отправить пакет
прямо сейчас вот с таким вот requires?

(In reply to comment #20)
> codeblocks я могу отправить на пересборку прямо сейчас, наверное, надо
> выставить requires на wxGTK >= 2.8.10-alt2

Да, пожалуй.

> Нужно ли дожидаться, пока wxGTK доедет до сизифа, или можно отправить пакет
> прямо сейчас вот с таким вот requires?

Уже доехал:
http://git.altlinux.org/tasks/11283/task/log

> Да, пожалуй.

codeblocks-8.02-alt17 ушел в incoming

> Уже доехал:
> http://git.altlinux.org/tasks/11283/task/log

Это до вас может быть доехал, а до меня, т.е. до публичных серверов - еще не доехал. Вот я сейчас src.rpm собирал с ключом --nodeps, у меня то нового wxGTK пока нет.

вот эта проблема
http://lists.altlinux.org/pipermail/devel/2009-July/173326.html
возможно тоже из-за binutils?

(In reply to comment #17)
> Давайте составим список пакетов, которые нужно пересобрать как можно быстрее.

Вот список всех пострадавших пакетов:
Aug 22 14:27 poedit-1.4.2-alt3.src.rpm
Aug 18 03:26 dvdstyler-1.7.3-alt2.src.rpm
Aug 11 23:48 wxMaxima-0.8.3-alt1.src.rpm
Jul 29 07:46 hugin-0.8.0-alt2.1.src.rpm
Jul 22 01:31 bacula-3.0.2-alt1.src.rpm
Jul  5 16:31 python-module-wx-2.8.9-alt1.src.rpm
Jul  1 21:31 scalasca-1.1-alt5.src.rpm
Jun 25 06:47 scummvm-tools-0.13.0-alt2.src.rpm
Jun 18 16:58 xchm-1.17-alt1.src.rpm
May 25 11:22 flamerobin-0.9.0-alt2.src.rpm
May 18 01:35 aMule-2.2.5-alt1.src.rpm
May 13 18:11 tintii-2.1.0-alt1.src.rpm

(В ответ на комментарий №24)
> (In reply to comment #17)
> > Давайте составим список пакетов, которые нужно пересобрать как можно быстрее.
> 
> Вот список всех пострадавших пакетов:

я бы добавил pgadmin3

> я бы добавил pgadmin3

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