размер файла 232 150 328 байт. Похоже на ошибку сборки. Я проверил в других дистрибутивах, ничего подобного нет.
да, strip помог
Спасибо, посмотрю.
Я ожидаю, что strip'ать /usr/bin/audacity должен rpmbuild, после того, как извлечёт из него debuginfo. rpmbuild, похоже, делает это, но не слишком успешно: он вызывает eu-strip, который по каким-то причинам не слишком справляется -- обычный strip справляется гораздо лучше: $ rpm -qf /usr/bin/audacity audacity-3.4.2-alt1.x86_64 $ cp /usr/bin/audacity ./audacity $ eu-strip --strip-all ./audacity $ ls -lh ./audacity -rwxr-xr-x 1 iv iv 222M Nov 22 14:04 ./audacity $ strip --strip-all ./audacity $ ls -lh ./audacity -rwxr-xr-x 1 iv iv 15M Nov 22 14:04 ./audacity Перевешиваю на elfutils и прошу помощи знатоков оттуда.
- rpmpeek /ALT/Sisyphus/files/x86_64/RPMS/audacity-3.4.2-alt1.x86_64.rpm $ readelf -S usr/bin/audacity .. [20] .bss NOBITS 0000000000d68380 d67348 024360 00 WA 0 0 64 [21] .gnu.build.attributes NOTE 0000000000d8e6e0 dd64be0 000048 00 0 0 4 [22] .interp PROGBITS 000000000dc77000 dc77000 00001c 00 A 0 0 8 ... Похоже после .bss много пустого пространства, это как раз примерно где и были .debug секции. - rpmpeek /ALT/Sisyphus/files/x86_64/RPMS/audacity-debuginfo-3.4.2-alt1.x86_64.rpm $ eu-readelf -S ./usr/lib/debug/usr/bin/audacity.debug ... [20] .bss NOBITS 0000000000d68380 000003c0 00024360 0 WA 0 0 64 [21] .comment PROGBITS 0000000000000000 000003c0 00000036 1 MS 0 0 1 [22] .GCC.command.line PROGBITS 0000000000000000 000003f6 000004af 1 MS 0 0 1 [23] .gnu.build.attributes NOTE 0000000000d8e6e0 000008a8 00000048 0 0 0 4 [24] .debug_aranges PROGBITS 0000000000000000 000008f0 000032f0 0 0 0 1 [25] .debug_info PROGBITS 0000000000000000 00003be0 08a4e448 0 0 0 1 [26] .debug_abbrev PROGBITS 0000000000000000 08a52028 002cc845 0 0 0 1 [27] .debug_line PROGBITS 0000000000000000 08d1e86d 00928ec8 0 0 0 1 [28] .debug_str PROGBITS 0000000000000000 09647735 02287da1 1 MS 0 0 1 [29] .debug_line_str PROGBITS 0000000000000000 0b8cf4d6 00012aea 1 MS 0 0 1 [30] .debug_loclists PROGBITS 0000000000000000 0b8e1fc0 00ff35a1 0 0 0 1 [31] .debug_rnglists PROGBITS 0000000000000000 0c8d5561 003430f0 0 0 0 1 [32] .symtab SYMTAB 0000000000000000 0cc18658 000d4970 24 33 17096 8 [33] .strtab STRTAB 0000000000000000 0ccecfc8 0022097c 0 0 0 1 [34] .shstrtab STRTAB 0000000000000000 0cf0d944 000001c8 0 0 0 1 [35] .interp NOBITS 000000000dc77000 0cf0db10 0000001c 0 A 0 0 8 ... ps. Please reports bugs at https://sourceware.org/bugzilla/
похоже на https://sourceware.org/bugzilla/show_bug.cgi?id=32271 Вопрос: а зачем вообще этот eu-strip используется? если бинари у нас в 99,99% случаев создаются binutils-ом и этот binutils всегда у нас в сборочном окружении.. кажется логичным использовать strip (?)
Очередной подход к этой проблеме оказался чуть более успешным чем предыдущие. Выяснилось, что в бинарнике audacity по результатам секции %install несколько секций c флагом SHF_ALLOC оказываются в конце файла: [35] .interp PROGBITS 000000000c68f000 c68f000 00001c 00 A 0 0 8 [36] .note.gnu.property NOTE 000000000c68f020 c68f020 000040 00 A 0 0 8 [37] .note.gnu.build-id NOTE 000000000c68f060 c68f060 000024 00 A 0 0 4 [38] .note.ABI-tag NOTE 000000000c68f088 c68f088 000020 00 A 0 0 4 [39] .gnu.hash GNU_HASH 000000000c68f0a8 c68f0a8 016394 00 A 1 0 8 [40] .dynstr STRTAB 000000000c6a5440 c6a5440 0dc260 00 A 0 0 8 [41] .dynamic DYNAMIC 000000000c7816a0 c7816a0 0006c0 10 WA 40 0 8 Поскольку это секции с SHF_ALLOC, eu-strip не решается менять их адрес, а заодно и смещение, и они остаются там же, где и были, не смотря на пустоту на месте отладочных секций. Тем временем, strip из binutils меняет смещения этим секциям. Видимо, будучи частью binutils, он может легко воспользоваться более подробной информацией о семантике этих секций, но тут я в деталях не разбирался. То есть это не баг, а меньший функционал eu-strip. Ну что ж. Чтобы решить конкретную проблему с audacity достаточно было разобраться, почему эти секции оказываются в конце бинарника. Я искал долго и безуспешно искал источник проблем в опциях компоновщика и его скриптах, а надо было протереть глаза и посмотреть в саму секцию %install, где правится RPATH при помощи patchelf, который не стесняется переносить секции в новое место если в какой-то из них в старом месте ему не хватило, так сказать, места. Я же его правил, я в курсе его такого поведения. Но вот тут картинка сложилась не сразу. Так что разумный вариант -- не использовать patchelf. В спеке уже был вариант изменения RPATH при помощи chrpath -r, спрятанный под %ifarch %e2k. Я перешёл на него на всех архитектурах, и это, похоже, сработало: бинарник вернулся к более разумному размеру, rpath на месте, и на первый взгляд всё работает: $ ls -lh /usr/bin/audacity -rwxr-xr-x 1 root root 12M May 6 19:09 /usr/bin/audacity $ patchelf --print-rpath /usr/bin/audacity $ORIGIN/../lib64/audacity Ждём: #383459 BUILDING #2.3 [locked] sisyphus/iv audacity.git=3.7.3-alt2
audacity-3.7.3-alt2 -> sisyphus: Tue May 06 2025 Ivan A. Melnikov <iv@altlinux> 3.7.3-alt2 - unify rpath adjustment code with %e2k + simplifies spec; + helps eu-strip make smaller binaries (ALT#48494).
А нельзя было его сделать sparse после patchelf? (cp --sparse=always)
(In reply to Vitaly Chikunov from comment #8) > А нельзя было его сделать sparse после patchelf? (cp --sparse=always) В этот момент в нём ещё есть вся отладочная информация. Или Вы предлагаете его в %%install сделать sparse, и тогда после debugedit'а он останется sparse?
Чисто научный интерес поможет ли это (может и нет), сохранится ли sparse до конечной системы пользователя и бинарник останется в рабочем состоянии. Не предлагаю ваше решение менять на это.
