Bug 48494

да, 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 до конечной системы пользователя и бинарник останется в рабочем состоянии. Не предлагаю ваше решение менять на это.