Не собирается elfutils

У меня, например, оно без флага lzma успешно собралось. И в логе есть такие строчки:

../libdw/libdw.so: undefined reference to `lzma_code@XZ_5.0'
../libdw/libdw.so: undefined reference to `lzma_auto_decoder@XZ_5.0'
../libdw/libdw.so: undefined reference to `lzma_end@XZ_5.0'

Может для начала отключить этот юз у этого пакета и попробовать собрать?

Спасибо, сейчас попробуем.

почему не на багзилле?

почему не на багзилле?

Решил сначала тут узнать, мало ли это только у меня не собирается.

Да, без lzma собирается. Проследую в сторону багзиллы.

Если у него ядро пожато в LZMA (как у меня, например), то лучше не стоит так делать. Я не помню, кто юзает этот пакет и зачем, но.

To TS:
Что за «рецепт [nm]» гляди в Makefile, почему фейлится ld мне пока тоже не понятно.

P.S.: Ненавижу локализованные логи.

Что / как?

Я включил флаг lzma у себя. Успешно собралось, кстати.

Ну, собирать можно в пакет, а не на живую систему. Но да, мой комментарий содержал потенциально стрёмное указание.

Что / как?

Собрал elfutils с

-lzma

А в какой формат сжимается ядро? То есть действительно будет нехорошо, если не собрать поддержку нужного метода сжатия ядра. Можно проверить, не юзается ли lzma при сжатии ядра, с помощью

zcat /proc/config.gz | grep CONFIG_KERNEL_LZMA

Я не помню, кто юзает этот пакет и зачем, но.

Например, вот что от него зависит

>> equery d elfutils
 * These packages depend on elfutils:
dev-libs/glib-2.42.2 (>=dev-libs/elfutils-0.142)
media-libs/mesa-10.5.2 (video_cards_radeonsi ? >=dev-libs/elfutils-0.155-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
                       (video_cards_radeon ? >=dev-libs/elfutils-0.155-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])
                       (opencl ? >=dev-libs/elfutils-0.155-r1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?])

что ты подраузмеваешь под «если не собрать поддержку нужного метода сжатия ядра»? elfutils тут не при чём

в glib его юзает девелоперская утилита, в багзилле завели баг об удалении этой зависимости

Не собирается elfutils (комментарий) — вот в этом комментарии говорят о возможности проблем при сжатии ядра в lzma.

Я сопоставил следующие факты:
1)

>> euse -i lzma
...
[-      ] lzma
    dev-libs/elfutils: Support automatic decompression of LZMA-compressed 
    files and kernel images
...

ядро распаковывается при запуске без использования юзерспейса(тк оно стартует до него)

Это да. Но мало ли когда нужно использование elfutils на компе ТС?

если ТС не разработчик ядра — то никогда, если разработчик — сам разберётся. в противном случае это была бы жёсткая зависимость

Сам файл ядра может быть при некоторых обстоятельствах проверяться чем-либо и когда-либо уже в юзерспейсе и в том числе и утилитой из сабжа. Я не говорю, что это гарантировано так, но не гарантирую обратного.

Ну, меса и глиб сам блоб ядра не трогают, это им не нужно.

Ясно.

Таки хочется услышать ТС-а, как у него дела, всё обновилось / на multilib переехало?

если бы это было так, конфиг ядра бы проверялся с помощью linux-info.eclass, либо это просто была бы жёсткая зависимость. есть в этом сомнения — можешь зарепортить баг. подразумевается, что ни при каких сочетаниях use флагов ничего не должно ломаться

На самом деле нет никаких проблем с переходом.

Я не о проверке конфига ядра портажем, а о проверке самого файла ядра для каких-либо нужд.

Таки хочется услышать ТС-а, как у него дела, всё обновилось / на multilib переехало?

Да, всё обновилось. После обновления пересобрал elfutils снова с флагом lzma - все успешно скомпилилось.