Нужна функция автоматической генерации debug-пакетов, аналогичная реализованной в Debian и Fedora. Подробности реализации в fedora можно посмотреть в их rpm 4.7 macros.in:166, scripts/find-debuginfo.sh.
В SuSE, кажется, тоже было что-то подобное.
Нерабочий proof of concept тут: http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo
(В ответ на комментарий №1) > В SuSE, кажется, тоже было что-то подобное. Это в дебиане "что-то подобное", во всех остальных rpm-baes дистрибутивах оно просто через rpm-4.2+
прошу обратить внимание на фич реквест, полезная же вещь!
Вообще очень интересно, как можно что-то отлаживать, отлавливать ошибки, если нормальной возможности получить отладочный вывод для программы из собранного пакета.
Дима, есть мысли на этот счёт?
(In reply to comment #2) > Нерабочий proof of concept тут: > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo Почему нерабочий?
(В ответ на комментарий №7) > > Нерабочий proof of concept тут: > > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo > > Почему нерабочий? http://lists.altlinux.org/pipermail/devel/2009-May/170090.html Хочет beecrypt из этого века.
http://lists.altlinux.org/pipermail/devel/2010-August/183683.html
Спасибо Кириллу, beecrypt уже давно обновлён. Кто будет катить камень дальше?
(In reply to comment #10) > Спасибо Кириллу, beecrypt уже давно обновлён. > Кто будет катить камень дальше? Я собирался после gcc4.5.
Мужики, у нас же свой brp-strip, и он обрезает сильнее, чем в редхате (у нас используется 'strip --strip-unneeded', а в редхате используется 'eu-strip --strip-debug'). И в нём 100 тысяч миллионов опций. Так что надо всё переделывать, причем неизвестно как. А просто так коммитить новые файлы в наш rpm смысла нет. В лучшем случае мы получим пустые/некогерентные debuginfo пакеты. Принципиальный вопрос - надо ли обрезать .symtab. У нас .symtab всегда обрезается. В редхате .symtab не обрезается.
Нет, американцы тоже .symtab отрезают, я не так понял в одном месте. Надо придумать, как совместить brb-strip и debuginfo, чтобы это работало одинаково для всех пакетов - работало хорошо и с минимальным количеством опций. Дело в том что сейчас всякие опции в rpmbuild типа _strip_method или _strip_skiplist исходят из того, что бинарики собраны без -g. А если бинарики собраны с -g, то debug можно отрезать в любом случае. Короче смысол этих опций будет под вопросом. Предлагаю для обдумывания следующую модель brp-strip+debuginfo: каждый ELF executable и ELF shared в билдруте принудительно обрезается (и создается /usr/lib/debug$f.debug файл). Разница только сколько надо обрезать. По умолчанию режим обрезания "debug,comment,symbols". Со стороны rpmbuild можно только изменить сколько надо обрезать, например, так: %название_макроса_обрезания шелл-паттерн сколько-обрезать E.g. # keep symbols %название_макроса_обрезания %_libdir/valgrind/*.so debug,comment
Мужики, короче я подумал, решил что надо делать отдельный *-debuginfo пакет на каждый подпакет, а пустых *-debuginfo пакетов делать не надо. И чтобы у каждого *-debuginfo пакета была зависимость на свой подпакет. А это не очень просто сделать. Так что кому надо просьба не беспокоиться. Я уже придумал как можно сделать. А то американцы насрут - всё в один пакет и без всяких зависимостей - и считается что круто. И ещё надо делать сделать замыкание *-debuginfo пакетов по завимостям. То есть чтобы была "сквозная отладка". А не так там что на одном фрейме отладка есть а на другом нету.
И класть бы их хорошо в отдельный компонент, не classic.
Мужики, я нарисовал сишную часть, лежит у меня в rpm.git бранч debuginfo. Работает пока примерно так: LD_LIBRARY_PATH=$PWD/build/.libs rpmbuild --define '__find_debuginfo_files while read -r f; do f=${f#$RPM_BUILD_ROOT}; if [ -f $RPM_BUILD_ROOT/usr/lib/debug$f.debug ]; then echo /usr/lib/debug$f.debug; fi; done' -bb --short-circuit *.spec То есть там будет две стадии - одна brp-debuginfo для всего билдрута в целом, а другая на каждый пакет, которая будет выцеживать нужные файлы. Какие будут мнения.
Мужчины, я выложил бранч debuginfo, там реализована мегафича - автоматическое удаление дупов исходников между *-debuginfo подпакетами. На основе зависимостей между основными подпакетами! Например, если пакет rpm требует пакет librpm, то из пакета rpm-debuginfo можно удалить пересекающиеся исходники, добавив зависимость на librpm-debuginfo. А пакет rpm-static требует пакет rpm. Тогда, по этой же логике, из пакета rpm-static-debuginfo можно удлить исходники, пересекающиеся с rpm-debuginfo, и добавить зависимость на rpm-debuginfo. Но rpm в свою очередь требует librpm. Так что в пакете rpm-static-debuginfo по идее может вообще не остаться исходников! Бранч debuginfo собираем, его можно собрать в хешере два раза и посмотреть результат (который появится на второй раз в результате сборки rpm'а самим собой).
(В ответ на комментарий №17) > Бранч debuginfo собираем, его можно собрать в хешере два раза и посмотреть > результат (который появится на второй раз в результате сборки rpm'а самим > собой). Пробовал собрать midori на x86_64. Создался пакет midori-debuginfo, но символы запаковались в /usr/lib/debug вместо /usr/lib64/debug и gdb их соотвественно автоматом не подхватывает. В целом же фича просто потрясающая! Спасибо!
По-моему должно быть /usr/lib/debug на обеих архитектурах.
(In reply to comment #19) > По-моему должно быть /usr/lib/debug на обеих архитектурах. Если /usr/lib/debug -- это префикс, за котором следует полный путь, включая %_libdir, то совершенно все равно, какой это префикс. На данном этапе есть возможность выбрать такой же префикс, как и у других.
Лучше сделать как в редхате, если нет других соображений. Я проверил, gdb действительно смотрит в /usr/lib64/debug (хотя в "info gdb" написано про /usr/lib/debug). А valgrind - в /usr/lib/debug. Я помню, что valgrind у меня подцепил debuginfo пакет... $ strings /usr/bin/gdb |grep /debug /usr/lib64/debug $ rpm -ql valgrind |xargs strings |grep /debug m_debuginfo/debuginfo.c /usr/lib/debug%s/%s /usr/lib/debug/.build-id/%c%c/%s.debug Да, подразумевается, что /usr/lib/debug - это префикс, за которым следует полный путь - будет выполняться что-то вроде eu-strip -f /usr/lib/debug$f.debug $f
(In reply to comment #21) > Лучше сделать как в редхате, если нет других соображений. А какой префикс выбрали там? > Я проверил, gdb > действительно смотрит в /usr/lib64/debug (хотя в "info gdb" написано про > /usr/lib/debug). А valgrind - в /usr/lib/debug. Я помню, что valgrind у меня > подцепил debuginfo пакет... Префикс должен быть один для всех, кого-то из них придется исправить.
В федоре везде /usr/lib/debug. Можно скачать какой-нибудь пакет и посмотреть. http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/debug/
В ubuntu/debian тоже /usr/lib/debug
(В ответ на комментарий №24) > В ubuntu/debian тоже /usr/lib/debug Так там беарчь без извращений с /usr/lib64.
Вроде бы уже есть?
