Bug 39530

/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 оно не работает. Сделайте плиз.