> Судя по всему в C++ части бибилиотеки поменялся API, но ни в soname, ни > в vesrioning script это не отражено. (c) ns@ codeblocks-8.02-alt10 с библиотекой wxGTK-2.8.9-alt1 запускается нормально, при запуске же его с wxGTK-2.8.9-alt2 выдаётся следующая ошибка: codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference
это 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 Его уже нет в репозитории, по причине несобираемости. Правда, вроде как есть люди, желающие реанимировать.
