Re: [devel] Проблема при сборке newmon 27.0

[Ivan Zakharyaschev <imz@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 3924 bytes --]

> On Tue, 15 Nov 2016, Hihin Ruslan wrote:
>
>>  Здравствуйте Alexey Tourbin
>>   В сообщении от 13 ноября 2016 Alexey Tourbin написал(a):
>> >  2016-11-13 11:23 GMT+03:00 Hihin Ruslan <ruslandh@gmail.com>:
>> > >  Ruslan Hihin, [13.11.16 11:18]
>> > >  Я что-то не пойму как правильно сделать. В новой версии
>> > >  palemoon почему-то вдруг взорвалось :
>> > > 
>> > >  ...
>> > >  Verifying ELF objects in /usr/src/tmp/palemoon-buildroot
>> > >  (arch=normal,fhs=normal,lfs=relaxed,lint=relaxed,rpath=norma
>> > > l,stack=normal,textrel=normal,unresolved=normal) verify-elf:
>> > >  ERROR: ./usr/lib64/newmoon/plugin-container: not found:
>> > >  libmozalloc.so
>> > >  verify-elf: ERROR: ./usr/lib64/newmoon/plugin-container: not
>> > >  found: libxul.so
>> > 
>> >  У него в прежней версии прописан RPATH, а в новой, вероятно,
>> >  не прописан (или прописан неверно).
>> > 
>> >  $ rpmpeek newmoon-26.5.0-alt1.x86_64.rpm \
>> >  objdump -p ./usr/lib64/newmoon/plugin-container |grep PATH
>> >    RPATH                /usr/lib64/newmoon
>> > 
>> >  plugin-container как программу и запустить не получится, если
>> >  только какой-нибудь скрипт перед запуском не выставит ему в
>> >  окружение LD_LIBRARY_PATH=/usr/lib64/newmoon.
>> > 
>> >  Короче, посмотрите, что говорит
>> >  $ objdump -p
>> >  newmoon-buildroot/usr/lib64/newmoon/plugin-container |grep
>> >  PATH
>>
>>  Получается что-то странное:
>>  objdump -p plugin-container  | grep PATH
>>   RUNPATH              /usr/lib64/newmoon
>>
>>  Что за RUNPATH ?
>
> Из того, что я узнал и понял из этого обсуждения, RUNPATH должен был бы 
> работать не хуже, чем RPATH, который был в прошлых версиях.
>
> Но хочется понять до конца: проблема всё же в изменении этого ключевого слова 
> (как Вы стали предполагать) или в каких-то других изменениях.

Вот действительно, проблема в том, что verify-elf не учитывает RUNPATH 
(как Вы и предположили). В отличие от lib.req, например.

http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=scripts/verify-elf.in;h=316117f05428961b85fa4428f86f4e6f9f0a7968;hb=HEAD#l378

 		verify_unresolved "$f" "$preload" "$fname" \
 			"$(printf %s "$objdump_info" |awk '{if ($1=="RPATH") print $2}' |tr -s : ' ' |sed -e "s|\$ORIGIN|${fname%/*}|g")"

lib.req.in:95:		 awk '($1=="RPATH"||$1=="RUNPATH"){print $2}' |

Спасибо за предоставленный более полный материал (хотя бы в виде 
бинарника) к этому, получается, багрепорту.

> У Вас есть под рукой бинарник plugin-container, который должен был бы 
> работать, но verify-elf не проходит? (verify-elf и т.п. можно запускать 
> отдельной командой, не во время сборки.) Без всяких дополнительных 
> редактирований. Просто нам остальным не так просто его получить -- процесс 
> сборки тяжёлый -- чтобы потом поизучать. Напишите побольше подробностей про 
> один конкретный бинарник (verify-elf, objdump для начала), чтобы ситуация 
> была яснее.
>
> -- 
> Best regards,
> Ivan
>