При сборке пакета lmdbg-1.3.0-alt1 под i586 крешится ldd(1) как показано ниже. Воспроизводится как в сборочнице, так и в локальном хешере. Под x86_64 не воспроизводится. Finding Requires (using /usr/lib/rpm/find-requires) Executing: /bin/sh -e /usr/src/tmp/rpm-tmp.gpym1I find-requires: running scripts (cpp,debuginfo,files,lib,pam,perl,pkgconfig,pkgconfiglib,python,rpmlib,shebang,shell,static,symlinks,systemd-services) /usr/lib/rpm/ldd: line 100: 108570 Segmentation fault LD_TRACE_LOADED_OBJECTS=1 LD_WARN=$warn LD_BIND_NOW=$bind_now LD_DEBUG=$debug LD_LIBRARY_VERSION=$verify_out LD_PRELOAD="$rtld_preload" "$rtld" --library-path "$rpath" "$rtld_target" ldd: ERROR: : trace failed find-requires: ERROR: /usr/lib/rpm/lib.req failed Полный лог здесь: http://git.altlinux.org/tasks/264463/logs/events.1.1.log.
/usr/lib/rpm/find-requires спотыкается на /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug. Точнее, падает (в i586-м хешере на x86_64) команда LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 --library-path /usr/src/tmp/lmdbg-buildroot/lib:/usr/src/tmp/lmdbg-buildroot/usr/lib /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug Интересно, что просто /usr/bin/ldd /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug не сегфолтится так как $ /lib/ld-linux.so.2 --verify /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug; echo $? 2 Ну потому что реально это не совсем настоящий "ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped", что бы там file по этому поводу не думал. С точки зрения lmdbg проблема в том, что из-за недосмотра автора спека на 32-битных архитектурах файлы debuginfo попадают в основной пакет. Такое вот тривиальное изменение, возможно, не является оптимальным вариантом (зачем в этом пакете симлинки?), но исправляет сборку на i586 %files -n lib%name -%_libdir/* +%_libdir/*.so* Неплохо бы куда-нибудь в rpmbuild добавить проверку, что файлы debuginfo ни в какие пакеты не попадают (кроме формируемых автоматически *-debuginfo), чтобы до find-requires получать в таких ситуациях вменяемую диагностику. Также было бы полезно повысить информированность общественности о невероятных возможностях %define _scripts_debug 3.
(In reply to Ivan A. Melnikov from comment #1) > /usr/lib/rpm/find-requires спотыкается на > /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug. > Точнее, падает (в i586-м хешере на x86_64) команда > > LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 --library-path > /usr/src/tmp/lmdbg-buildroot/lib:/usr/src/tmp/lmdbg-buildroot/usr/lib > /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug > > Интересно, что просто /usr/bin/ldd > /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug не > сегфолтится так как > > $ /lib/ld-linux.so.2 --verify > /usr/src/tmp/lmdbg-buildroot/usr/lib/debug/usr/lib/liblmdbg.so.0.0.debug; > echo $? > 2 Мне кажется, что разница обусловлена парметрами, возможно, ldd -r тоже свалится. > Ну потому что реально это не совсем настоящий "ELF 32-bit LSB shared object, > Intel 80386, version 1 (SYSV), dynamically linked, not stripped", что бы там > file по этому поводу не думал. > > С точки зрения lmdbg проблема в том, что из-за недосмотра автора спека на > 32-битных архитектурах файлы debuginfo попадают в основной пакет. Такое вот > тривиальное изменение, возможно, не является оптимальным вариантом (зачем в > этом пакете симлинки?), но исправляет сборку на i586 > > %files -n lib%name > -%_libdir/* > +%_libdir/*.so* Это типовая ошибка упаковки. Перевешиваю на rpm-build, но и там ошибки нет на самом деле. > Неплохо бы куда-нибудь в rpmbuild добавить проверку, что файлы debuginfo ни > в какие пакеты не попадают (кроме формируемых автоматически *-debuginfo), > чтобы до find-requires получать в таких ситуациях вменяемую диагностику. Понятно ли, как идентифицировать файлы debuginfo? > Также было бы полезно повысить информированность общественности о > невероятных возможностях %define _scripts_debug 3. И rpmbuild -vvv?
> > Неплохо бы куда-нибудь в rpmbuild добавить проверку, что файлы debuginfo ни > > в какие пакеты не попадают (кроме формируемых автоматически *-debuginfo), > > чтобы до find-requires получать в таких ситуациях вменяемую диагностику. Может проверка должны быть в sisyphus-check? > Понятно ли, как идентифицировать файлы debuginfo? Not stripped (налицие секции .symtab) + .debug_info/.zdebug_info секция + расширение .debug + локация в /usr/{lib,src}/debug.
(Ответ для Vitaly Chikunov на комментарий #3) > > > Неплохо бы куда-нибудь в rpmbuild добавить проверку, что файлы debuginfo ни > > > в какие пакеты не попадают (кроме формируемых автоматически *-debuginfo), > > > чтобы до find-requires получать в таких ситуациях вменяемую диагностику. > > Может проверка должны быть в sisyphus-check? 2. А ещё вариант - rpmbuild мог бы игнорировать файлы в /usr/lib/debug/*. Но тогда ошибка в спеке останется, но она не будет у нас ошибкой. Но, при возможном переходе в будущем на другой rpm она всплывёт с новой силой.
(Ответ для Vitaly Chikunov на комментарий #3) > Может проверка должны быть в sisyphus-check? > > > Понятно ли, как идентифицировать файлы debuginfo? sisyphus_check не лезет в payload пакета.
(In reply to Vitaly Chikunov from comment #3) > > > Неплохо бы куда-нибудь в rpmbuild добавить проверку, что файлы debuginfo ни > > > в какие пакеты не попадают (кроме формируемых автоматически *-debuginfo), > > > чтобы до find-requires получать в таких ситуациях вменяемую диагностику. > > Может проверка должны быть в sisyphus-check? Идея добавления такой проверки в rpmbuild была в том, чтобы она выполнилась до find-requires, verify-elf и всего такого -- чтобы в случае проблем сборка пакета завершалась ошибкой с диагностикой от этой проверки, а не непонятным падением чего-то там. sisyphus-check, емнип, отрабатывает позже. С другой стороны, если падение ldd будет исправлено по месту, порядок естественно станет не важен.
Спек я, положим, поправлю, симлинки, допустим, уберу, но по-моему имеет смысл поправить ldd с тем, чтобы не падал все-таки. Тем более, что здесь есть люди, близкие к разработке glibc.
Забыл сказать. Для этого пакета в сборочницу нужно добавить пакет glibc-core-debuginfo. В противном случае его невозможно тестировать и выставить правильные зависимости. Потреба странная, но в данном конкретном случае обоснованная. Без debuginfo оно не работает. Сделайте плиз.
