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

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

[Hihin Ruslan]

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

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=normal,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
....
symbol: moz_free
verify-elf: ERROR: ./usr/lib64/newmoon/plugin-container: 
undefined symbol: moz_xmalloc
section [ 2] '.dynsym': symbol 384: local symbol outside range 
described in sh_info
....
section [ 2] '.dynsym': symbol 2922: symbol in dynamic symbol 
table with non-default visibility
...

Хотя расположение файлов осталось прежним. 
Конечно можно симлинк сделать 
с  /usr/lib64/newmoon/libmozalloc.so 
на /usr/lib64/libmozalloc.so, или в ld.so.conf.d прописать путь 
к /usr/lib64/newmoon, но как-то не хочется нарваться на конфликт 
с каким-нибудь другим мозилловским продуктом.

Ruslan Hihin, [13.11.16 11:21]
И руками разные варианты не проверишь - каждоая сборка около двух 
часов 😉
-- 
  А ещё говорят так  (fortune): 
 
endothermal recalibration 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Alexey Tourbin]

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=normal,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

> Хотя расположение файлов осталось прежним.
> Конечно можно симлинк сделать
> с  /usr/lib64/newmoon/libmozalloc.so
> на /usr/lib64/libmozalloc.so, или в ld.so.conf.d прописать путь
> к /usr/lib64/newmoon, но как-то не хочется нарваться на конфликт
> с каким-нибудь другим мозилловским продуктом.

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

[Hihin Ruslan]

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

Здравствуйте Alexey Tourbin
  В сообщении от 13 ноября 2016 Alexey Tourbin написал(a):
> У него в прежней версии прописан 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

Спасибо. Уже ищу в направлении, где правильно задать rpath.
Следующая возможность посмотреть будет уже вечером ;-)

Пока запустил http://git.altlinux.org/tasks/172194/
Может что-то и получится ;-)

-- 
  А ещё говорят так  (fortune): 
 
> Это faq или bug? Это Сизиф-специфик -- zerg in sisyphus@ 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Hihin Ruslan]

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

Здравствуйте 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 ?


-- 
  А ещё говорят так  (fortune): 
 
Файлоимитатор. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ruslan Hihin]

http://stackoverflow.com/questions/7967848/use-rpath-but-not-runpath
-- 
Простите за краткость, создано в K-9 Mail.

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 3036 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, который был в прошлых версиях.

Но хочется понять до конца: проблема всё же в изменении этого ключевого 
слова (как Вы стали предполагать) или в каких-то других изменениях.

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

-- 
Best regards,
Ivan

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

[Hihin Ruslan]

[-- Attachment #1.1: Type: text/plain, Size: 1049 bytes --]

Здравствуйте Ivan Zakharyaschev
  В сообщении от 25 ноября 2016 Ivan Zakharyaschev написал(a):

> потом поизучать. Напишите побольше подробностей про один
> конкретный бинарник (verify-elf, objdump для начала), чтобы
> ситуация была яснее.

Спасибо за толчрк в нужном направлении. 

В общем нашёл проблему с помощью ldd:

имею  взаимное :

libicuuc.so.52:
	libicudata.so.52 => not found
libicui18n.so.52:
	libicuuc.so.52 => not found

Пока не пойму - что делать с библиотками.

Собственно результат сборки - в https://yadi.sk/d/O5E1v_iJzWDZf


-- 
  А ещё говорят так  (fortune): 
 
Не так страшен Билл, как его Клинтон 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #1.2: ldd_log.err --]
[-- Type: text/plain, Size: 8228 bytes --]

libicuuc.so.52:
	linux-vdso.so.1 (0x00007ffe10d72000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f20d7518000)
	libicudata.so.52 => not found
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f20d7310000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f20d6f90000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f20d6c88000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f20d68e0000)
	/lib64/ld-linux-x86-64.so.2 (0x000055f5b159e000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f20d66c8000)
libicui18n.so.52:
	linux-vdso.so.1 (0x00007ffdda3ea000)
	libicuuc.so.52 => not found
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f08fb740000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f08fb438000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f08fb090000)
	/lib64/ld-linux-x86-64.so.2 (0x00005613cb283000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f08fae78000)



libmozjs.so:
	linux-vdso.so.1 (0x00007ffef0ea2000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe5b40f0000)
	libicui18n.so.52 => not found
	libicuuc.so.52 => not found
	libnspr4.so => /usr/lib64/libnspr4.so (0x00007fe5b3ea8000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fe5b3ba0000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe5b3820000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe5b3608000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fe5b3260000)
	/lib64/ld-linux-x86-64.so.2 (0x00005610acd45000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fe5b3058000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fe5b2e50000)
libsoftokn3.so:
	linux-vdso.so.1 (0x00007ffefdb42000)
	libmozsqlite3.so => not found
	libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007fbc04c70000)
	libplc4.so => /usr/lib64/libplc4.so (0x00007fbc04a68000)
	libplds4.so => /usr/lib64/libplds4.so (0x00007fbc04860000)
	libnspr4.so => /usr/lib64/libnspr4.so (0x00007fbc04618000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbc043f8000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fbc041f0000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fbc03e48000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fbc03c40000)
	/lib64/ld-linux-x86-64.so.2 (0x000055d32c1fe000)
libxul.so:
	linux-vdso.so.1 (0x00007ffe5374a000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f96323a0000)
	libnss3.so => /usr/lib64/libnss3.so (0x00007f9632078000)
	libsmime3.so => /usr/lib64/libsmime3.so (0x00007f9631e50000)
	libssl3.so => /usr/lib64/libssl3.so (0x00007f9631bf8000)
	libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f96319c8000)
	libmozsqlite3.so => not found
	libmozjs.so => not found
	libmozalloc.so => not found
	libplds4.so => /usr/lib64/libplds4.so (0x00007f96317c0000)
	libplc4.so => /usr/lib64/libplc4.so (0x00007f96315b8000)
	libnspr4.so => /usr/lib64/libnspr4.so (0x00007f9631370000)
	libicui18n.so.52 => not found
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f9631168000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f9630ea8000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f9630c60000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f9630a58000)
	libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f9630848000)
	libvpx.so.3 => /usr/lib64/libvpx.so.3 (0x00007f9630440000)
	libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007f9630130000)
	libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f962faf0000)
	libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f962f758000)
	libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f962f4a0000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f962f278000)
	libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f962f028000)
	libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f962ed00000)
	libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f962eaa8000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f962e790000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f962e450000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f962e238000)
	libXt.so.6 => /usr/lib64/libXt.so.6 (0x00007f962dfd0000)
	libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f962ddc8000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f962da48000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f962d740000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f962d528000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f962d180000)
	/lib64/ld-linux-x86-64.so.2 (0x000055f9ad225000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f962cf68000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f962cd50000)
	libpng15.so.15 => /usr/lib64/libpng15.so.15 (0x00007f962cb20000)
	libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007f962c8b8000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f962c688000)
	libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f962c480000)
	libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f962c270000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f962c068000)
	libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f962be40000)
	libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f962bc28000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f962ba00000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f962b7e8000)
	libmount.so.1 => /lib64/libmount.so.1 (0x00007f962b598000)
	libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f962b390000)
	libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f962b180000)
	libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f962af70000)
	libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f962ad60000)
	libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f962ab58000)
	libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f962a950000)
	libthai.so.0 => /usr/lib64/libthai.so.0 (0x00007f962a740000)
	libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f962a490000)
	libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007f962a258000)
	libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007f962a050000)
	libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007f9629e40000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f9629c18000)
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f96299a8000)
	libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f9629798000)
	libpcre.so.3 => /lib64/libpcre.so.3 (0x00007f9629550000)
	libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f9629348000)
	libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f9629128000)
	libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007f9628ef0000)
	libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f9628ca8000)
	libdatrie.so.1 => /usr/lib64/libdatrie.so.1 (0x00007f9628aa0000)
	libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007f9628898000)
	libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007f9628690000)
	libxcb-xfixes.so.0 => /usr/lib64/libxcb-xfixes.so.0 (0x00007f9628488000)
	libxcb-dri3.so.0 => /usr/lib64/libxcb-dri3.so.0 (0x00007f9628280000)
	libxcb-present.so.0 => /usr/lib64/libxcb-present.so.0 (0x00007f9628078000)
	libxcb-sync.so.1 => /usr/lib64/libxcb-sync.so.1 (0x00007f9627e70000)
	libxshmfence.so.1 => /usr/lib64/libxshmfence.so.1 (0x00007f9627c68000)
	libwayland-client.so.0 => /usr/lib64/libwayland-client.so.0 (0x00007f9627a58000)
	libwayland-server.so.0 => /usr/lib64/libwayland-server.so.0 (0x00007f9627840000)
	libgbm.so.1 => /usr/lib64/libgbm.so.1 (0x00007f9627630000)
	libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f9627420000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f9627218000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f9627010000)
	libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007f9626de0000)
	libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007f9626bc0000)
	libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f96269b8000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f96267b0000)
plugin-container:
	linux-vdso.so.1 (0x00007ffc52a92000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9f3dd08000)
	libmozalloc.so => not found
	libnspr4.so => /usr/lib64/libnspr4.so (0x00007f9f3dac0000)
	libxul.so => not found
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f9f3d740000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f9f3d438000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f9f3d090000)
	/lib64/ld-linux-x86-64.so.2 (0x000055631ce3e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f9f3ce88000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f9f3cc80000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9f3ca68000)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ivan Zakharyaschev]

[-- 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
>

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

[Hihin Ruslan]

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

Здравствуйте Ivan Zakharyaschev
  В сообщении от 27 ноября 2016 Ivan Zakharyaschev написал(a):
> > Из того, что я узнал и понял из этого обсуждения, RUNPATH
> > должен был бы работать не хуже, чем RPATH, который был в
> > прошлых версиях.
> >
> > Но хочется понять до конца: проблема всё же в изменении
> > этого ключевого слова (как Вы стали предполагать) или в
> > каких-то других изменениях.
>
> Вот действительно, проблема в том, что verify-elf не учитывает
> RUNPATH (как Вы и предположили). В отличие от lib.req,
> например.
>
> http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=scr
>ipts/verify-elf.in;h=316117f05428961b85fa4428f86f4e6f9f0a7968;h
>b=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}' |
>
> Спасибо за предоставленный более полный материал (хотя бы в
> виде бинарника) к этому, получается, багрепорту.

Вот спасибо, а то я весь код palemoon уже перерыл ;-)

ЗЫ Нужен багрепорт в багзиле?

-- 
  А ещё говорят так  (fortune): 
 
СисОп, разрывающий пасть пишyщемy чайникy. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ivan Zakharyaschev]

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

On Sun, 27 Nov 2016, Hihin Ruslan wrote:

>> Вот действительно, проблема в том, что verify-elf не учитывает
>> RUNPATH (как Вы и предположили). В отличие от lib.req,
>> например.
>>
>> http://git.altlinux.org/gears/r/rpm.git?p=rpm.git;a=blob;f=scr
>> ipts/verify-elf.in;h=316117f05428961b85fa4428f86f4e6f9f0a7968;h
>> b=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}' |
>>
>> Спасибо за предоставленный более полный материал (хотя бы в
>> виде бинарника) к этому, получается, багрепорту.
>
> Вот спасибо, а то я весь код palemoon уже перерыл ;-)

А нужно было порыть verify-elf, получается.

> ЗЫ Нужен багрепорт в багзиле?

Думаю, тут можно будет обсудить предлагаемое изменение. Не известны ли 
кому-нибудь противопоказания?

-- 
Best regards,
Ivan

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

[Ivan Zakharyaschev]

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

On Sun, 27 Nov 2016, Hihin Ruslan wrote:

> Здравствуйте Ivan Zakharyaschev

>> > Из того, что я узнал и понял из этого обсуждения, RUNPATH
>> > должен был бы работать не хуже, чем RPATH, который был в
>> > прошлых версиях.

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

> Вот спасибо, а то я весь код palemoon уже перерыл ;-)

Чтобы всё было хорошо и красиво, при моём поверхнстном взгляде на 
последнюю сборку 27.0.2-alt1 мне кажется, что не хватает аналогичного (как 
у всех других библиотек, которые он носит с собой) RUNPATH у 
libsoftokn3.so:

verify-elf: WARNING: 
./usr/lib64/newmoon/libxul.so: RPATH entry found: /usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: not found: 
libmozsqlite3.so
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_temp_directory
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_busy_timeout
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_column_blob
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_reset
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_exec
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_open
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_bind_int
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_column_int
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_step
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_close
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_column_bytes
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_bind_text
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_bind_blob
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_finalize
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_prepare_v2
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_file_control
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_free
verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
sqlite3_mprintf
verify-elf: WARNING: ./usr/lib64/newmoon/libplds4.so: RPATH entry found: 
/usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libplc4.so: RPATH entry found: 
/usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libnspr4.so: RPATH entry found: 
/usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libmozsqlite3.so: RPATH entry 
found: /usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libmozjs.so: RPATH entry found: 
/usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libmozalloc.so: RPATH entry 
found: /usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libicuuc.so.52: RPATH entry 
found: /usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libicui18n.so.52: RPATH entry 
found: /usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/libicudata.so.52: RPATH entry 
found: /usr/lib64/newmoon
verify-elf: WARNING: ./usr/lib64/newmoon/components/libmozgnome.so: RPATH 
entry found: /usr/lib64/newmoon
verify-elf: WARNING: 
./usr/lib64/newmoon/browser/components/libbrowsercomps.so: RPATH entry 
found: /usr/lib64/newmoon

В Вашем случае ничто не мешает такую же строгую проверку ввести для 
содержимого /usr/lib64/newmoon/ , как и для стандартных путей с 
библиотеками, чтобы такие вещи отлавливать. (Раз у Вас всё хорошо 
благодаря RPATH/RUNPATH в отличие от случаев всяких плагинов.)

Кажется, такая опция в макросах для управления verify-elf есть. Но надо 
посмотреть, чтобы точно сказать.

-- 
Best regards,
Ivan

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

[Ivan Zakharyaschev]

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

On Fri, 2 Dec 2016, Ivan Zakharyaschev wrote:

> В Вашем случае ничто не мешает такую же строгую проверку ввести для 
> содержимого /usr/lib64/newmoon/ , как и для стандартных путей с библиотеками, 
> чтобы такие вещи отлавливать. (Раз у Вас всё хорошо благодаря RPATH/RUNPATH в 
> отличие от случаев всяких плагинов.)
>
> Кажется, такая опция в макросах для управления verify-elf есть. Но надо 
> посмотреть, чтобы точно сказать.

Нет, такой ручки сейчас нет. Строгость определяется наличием пути в 
$RPM_VERIFY_ELF_LDD_RPATH, а его, во-первых, не легко поменять (только 
через изменение LIBDIR, что повлечёт много изменений), во-вторых, он 
используется и в других проверках как информация о стандартных путях, 
которые не надо менять, конечно.

case "$VERIFY_ELF_UNRESOLVED" in
 	no|relaxed)
 		ldd_rc=0
 		;;
 	strict)
 		ldd_rc=1
 		;;
 	*)
 		if [ -z "${t##*ELF* executable*dynamically linked*}" ] ||
 		   lookup_path "${fname%/*}" "$RPM_VERIFY_ELF_LDD_RPATH"; 
then
 			ldd_rc=1
 		else
 			ldd_rc=0
 		fi
 		;;
esac


> -- 
> Best regards,
> Ivan

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

[Ivan Zakharyaschev]

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

On Fri, 2 Dec 2016, Ivan Zakharyaschev wrote:

> Чтобы всё было хорошо и красиво, при моём поверхнстном взгляде на последнюю 
> сборку 27.0.2-alt1 мне кажется, что не хватает аналогичного (как у всех 
> других библиотек, которые он носит с собой) RUNPATH у libsoftokn3.so:
>
> verify-elf: WARNING: ./usr/lib64/newmoon/libxul.so: RPATH entry found: 
> /usr/lib64/newmoon
> verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: not found: 
> libmozsqlite3.so
> verify-elf: WARNING: ./usr/lib64/newmoon/libsoftokn3.so: undefined symbol: 
> sqlite3_temp_directory

> В Вашем случае ничто не мешает такую же строгую проверку ввести для 
> содержимого /usr/lib64/newmoon/ , как и для стандартных путей с библиотеками, 
> чтобы такие вещи отлавливать. (Раз у Вас всё хорошо благодаря RPATH/RUNPATH в 
> отличие от случаев всяких плагинов.)

Просто советую после исправления ошибок выше ввести у себя в .spec:

%set_verify_elf_method unresolved=strict

> Кажется, такая опция в макросах для управления verify-elf есть. Но надо 
> посмотреть, чтобы точно сказать.

-- 
Best regards,
Ivan

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

[Hihin Ruslan]

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

Здравствуйте Ivan Zakharyaschev
  В сообщении от 2 декабря 2016 Ivan Zakharyaschev написал(a):
> >> Вот действительно, проблема в том, что verify-elf не
> >> учитывает RUNPATH (как Вы и предположили). В отличие от
> >> lib.req, например.
> >
> > Вот спасибо, а то я весь код palemoon уже перерыл ;-)
>
> Чтобы всё было хорошо и красиво, при моём поверхнстном взгляде
> на последнюю сборку 27.0.2-alt1 мне кажется, что не хватает
> аналогичного (как у всех других библиотек, которые он носит с
> собой) RUNPATH у libsoftokn3.so:
Вот это почему-то пока не получается. Пока получилось или собрать 
без RUNPATH у libsoftokn3.so, или создать RUNPATH у 
libsoftokn3.so, но на этапе то-ли сборки, то-ли инсталяции, 
вылезают ошибки:

c++ -o 
Unified_cpp_js_src9.o -c  -I../../dist/system_wrappers -include /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/gcc_hidden.h -DFFI_BUILDING -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX='"lib"' -DDLL_SUFFIX='".so"' -DMOZ_GLUE_IN_PROGRAM -DAB_CD= -DNO_NSPR_10_SUPPORT -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/js/src -I. -Ictypes/libffi/include -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/intl/icu/source/common -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/intl/icu/source/i18n -I../../dist/include   -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/nspr         -fPIC   -DMOZILLA_CLIENT -include ../../js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src9.o.pp  -Wall -Wsign-compare -Wtype-limits -Wno-invalid-offsetof -Wcast-align -pipe -g -O2 -fPIC -DPIC -D_GNUC_ -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -g -freorder-blocks -O3 -fomit-frame-pointer      /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/js/src/Unified_cpp_js_src9.cpp
libjs_static.a
rm -f libjs_static.a libjs_static.a.desc
libmozjs.so
rm -f libmozjs.so
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/_virtualenv/bin/python /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/expandlibs_exec.py --extract -- 
ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o 
ExecutableAllocatorPosix.o jsarray.o jsatom.o jsmath.o jsutil.o 
pm_linux.o TraceLogging.o TraceLoggingGraph.o 
TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o 
Unified_cpp_js_src10.o Unified_cpp_js_src11.o 
Unified_cpp_js_src12.o Unified_cpp_js_src2.o 
Unified_cpp_js_src3.o Unified_cpp_js_src4.o 
Unified_cpp_js_src5.o Unified_cpp_js_src6.o 
Unified_cpp_js_src7.o Unified_cpp_js_src8.o 
Unified_cpp_js_src9.o ../../memory/fallible/libfallible.a ../../config/external/ffi/libffi.a ../../config/external/icu/libicu.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/_virtualenv/bin/python /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/expandlibs_exec.py --uselist --  
c++  -Wall -Wsign-compare -Wtype-limits -Wno-invalid-offsetof -Wcast-align -pipe -g -O2 -fPIC -DPIC -D_GNUC_ -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -g -freorder-blocks -O3 -fomit-frame-pointer  -fPIC -shared -Wl,-z,defs -Wl,-h,libmozjs.so -o 
libmozjs.so  RegExp.o CTypes.o Library.o Parser.o 
ExecutableAllocatorPosix.o jsarray.o jsatom.o jsmath.o jsutil.o 
pm_linux.o TraceLogging.o TraceLoggingGraph.o 
TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o 
Unified_cpp_js_src10.o Unified_cpp_js_src11.o 
Unified_cpp_js_src12.o Unified_cpp_js_src2.o 
Unified_cpp_js_src3.o Unified_cpp_js_src4.o 
Unified_cpp_js_src5.o Unified_cpp_js_src6.o 
Unified_cpp_js_src7.o Unified_cpp_js_src8.o 
Unified_cpp_js_src9.o   -lpthread  -Wl,-rpath,/__________________ -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -B /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/js/src/build/unix/gold -Wl,-version-script,symverscript    -Wl,-rpath-link,../../dist/bin -Wl,-rpath-link,/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/lib   ../../memory/fallible/libfallible.a ../../config/external/ffi/libffi.a ../../config/external/icu/libicu.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a ../../intl/icu/target/lib/libicui18n.so ../../intl/icu/target/lib/libicuuc.so ../../intl/icu/target/lib/libicudata.so ../../nsprpub/lib/ds/libplds4.so ../../nsprpub/lib/libc/src/libplc4.so ../../nsprpub/pr/src/libnspr4.so    -lm -lsocket -ldl  -lm -ldl
../../config/nsinstall -R -m 
644 'libjs_static.a' '../../dist/lib'
chmod +x libmozjs.so
strip  libmozjs.so
../../config/nsinstall -R -m 644 'libmozjs.so' '../../dist/bin'
../../config/nsinstall -R -m 644 'libmozjs.so' '../../dist/lib'
../../config/nsinstall -R -m 
644 'libmozjs.so' '../../dist/sdk/lib'
make[5]: Leaving directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/js/src'
make[4]: Leaving directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir'
make[3]: *** [compile] Error 2
make[3]: Leaving directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir'
make[2]: *** [default] Error 2
make[2]: Leaving directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir'
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon'
make: *** [build] Error 2
make: Leaving directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon'
error: Bad exit status from /usr/src/tmp/rpm-tmp.25662 (%build)


RPM build errors:
    Bad exit status from /usr/src/tmp/rpm-tmp.25662 (%build)
Command exited with non-zero status 1
274.49user 4518.29system 28:02.01elapsed 284%CPU 
(0avgtext+0avgdata 1381484maxresident)k
23472inputs+0outputs (167major+80604010minor)pagefaults 0swaps
hsh-rebuild: rebuild of `pkg.tar' failed.

-- 
  А ещё говорят так  (fortune): 
 
I have just had eighteen whiskeys in a row. I do believe that is 
a record. -- Dylan Thomas, his last words 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ivan Zakharyaschev]

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

Здравствуйте!

On Sat, 3 Dec 2016, Hihin Ruslan wrote:

>  В сообщении от 2 декабря 2016 Ivan Zakharyaschev написал(a):

>> Чтобы всё было хорошо и красиво, при моём поверхнстном взгляде
>> на последнюю сборку 27.0.2-alt1 мне кажется, что не хватает
>> аналогичного (как у всех других библиотек, которые он носит с
>> собой) RUNPATH у libsoftokn3.so:
> Вот это почему-то пока не получается. Пока получилось или собрать 
> без RUNPATH у libsoftokn3.so, или создать RUNPATH у 
> libsoftokn3.so, но на этапе то-ли сборки, то-ли инсталяции, 
> вылезают ошибки:

По-моему, ошибки где-то выше. Не вижу здесь команд, вызывающих ошибки. И 
упоминаний libsoftokn3.so тоже нет:

> c++ -o 
> Unified_cpp_js_src9.o -c  -I../../dist/system_wrappers -include /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/gcc_hidden.h -DFFI_BUILDING -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX='"lib"' -DDLL_SUFFIX='".so"' -DMOZ_GLUE_IN_PROGRAM -DAB_CD= -DNO_NSPR_10_SUPPORT -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/js/src -I. -Ictypes/libffi/include -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/intl/icu/source/common -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/intl/icu/source/i18n -I../../dist/include   -I/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/nspr         -fPIC   -DMOZILLA_CLIENT -include ../../js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src9.o.pp  -Wall -Wsign-compare -Wtype-limits -Wno-invalid-offsetof -Wcast-align -pipe -g -O2 -fPIC -DPIC -D_GNUC_ -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -g -freorder-blocks -O3 -fomit-frame-pointer      /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/js/src/U
 nified_cpp_js_src9.cpp
> libjs_static.a
> rm -f libjs_static.a libjs_static.a.desc
> libmozjs.so
> rm -f libmozjs.so
> /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/_virtualenv/bin/python /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/expandlibs_exec.py --extract -- 
> ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o 
> ExecutableAllocatorPosix.o jsarray.o jsatom.o jsmath.o jsutil.o 
> pm_linux.o TraceLogging.o TraceLoggingGraph.o 
> TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o 
> Unified_cpp_js_src10.o Unified_cpp_js_src11.o 
> Unified_cpp_js_src12.o Unified_cpp_js_src2.o 
> Unified_cpp_js_src3.o Unified_cpp_js_src4.o 
> Unified_cpp_js_src5.o Unified_cpp_js_src6.o 
> Unified_cpp_js_src7.o Unified_cpp_js_src8.o 
> Unified_cpp_js_src9.o ../../memory/fallible/libfallible.a ../../config/external/ffi/libffi.a ../../config/external/icu/libicu.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a
> /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/_virtualenv/bin/python /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/expandlibs_exec.py --uselist -- 
> c++  -Wall -Wsign-compare -Wtype-limits -Wno-invalid-offsetof -Wcast-align -pipe -g -O2 -fPIC -DPIC -D_GNUC_ -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -g -freorder-blocks -O3 -fomit-frame-pointer  -fPIC -shared -Wl,-z,defs -Wl,-h,libmozjs.so -o 
> libmozjs.so  RegExp.o CTypes.o Library.o Parser.o 
> ExecutableAllocatorPosix.o jsarray.o jsatom.o jsmath.o jsutil.o 
> pm_linux.o TraceLogging.o TraceLoggingGraph.o 
> TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o 
> Unified_cpp_js_src10.o Unified_cpp_js_src11.o 
> Unified_cpp_js_src12.o Unified_cpp_js_src2.o 
> Unified_cpp_js_src3.o Unified_cpp_js_src4.o 
> Unified_cpp_js_src5.o Unified_cpp_js_src6.o 
> Unified_cpp_js_src7.o Unified_cpp_js_src8.o 
> Unified_cpp_js_src9.o   -lpthread  -Wl,-rpath,/__________________ -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -B /usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/js/src/build/unix/gold -Wl,-version-script,symverscript    -Wl,-rpath-link,../../dist/bin -Wl,-rpath-link,/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/lib   ../../memory/fallible/libfallible.a ../../config/external/ffi/libffi.a ../../config/external/icu/libicu.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a ../../intl/icu/target/lib/libicui18n.so ../../intl/icu/target/lib/libicuuc.so ../../intl/icu/target/lib/libicudata.so ../../nsprpub/lib/ds/libplds4.so ../../nsprpub/lib/libc/src/libplc4.so ../../nsprpub/pr/src/libnspr4.so    -lm -lsocket -ldl  -lm -ldl
> ../../config/nsinstall -R -m 
> 644 'libjs_static.a' '../../dist/lib'
> chmod +x libmozjs.so
> strip  libmozjs.so
> ../../config/nsinstall -R -m 644 'libmozjs.so' '../../dist/bin'
> ../../config/nsinstall -R -m 644 'libmozjs.so' '../../dist/lib'
> ../../config/nsinstall -R -m 
> 644 'libmozjs.so' '../../dist/sdk/lib'
> make[5]: Leaving directory 
> `/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/js/src'
> make[4]: Leaving directory 
> `/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir'
> make[3]: *** [compile] Error 2
> make[3]: Leaving directory 
> `/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir'
> make[2]: *** [default] Error 2
> make[2]: Leaving directory 
> `/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir'
> make[1]: *** [realbuild] Error 2
> make[1]: Leaving directory 
> `/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon'
> make: *** [build] Error 2
> make: Leaving directory 
> `/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon'
> error: Bad exit status from /usr/src/tmp/rpm-tmp.25662 (%build)
>
>
> RPM build errors:
>    Bad exit status from /usr/src/tmp/rpm-tmp.25662 (%build)
> Command exited with non-zero status 1
> 274.49user 4518.29system 28:02.01elapsed 284%CPU 
> (0avgtext+0avgdata 1381484maxresident)k
> 23472inputs+0outputs (167major+80604010minor)pagefaults 0swaps
> hsh-rebuild: rebuild of `pkg.tar' failed.

Best regards,
Ivan

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

[Ivan Zakharyaschev]

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

On Sat, 3 Dec 2016, Hihin Ruslan wrote:

>  В сообщении от 2 декабря 2016 Ivan Zakharyaschev написал(a):

>> Чтобы всё было хорошо и красиво, при моём поверхнстном взгляде
>> на последнюю сборку 27.0.2-alt1 мне кажется, что не хватает
>> аналогичного (как у всех других библиотек, которые он носит с
>> собой) RUNPATH у libsoftokn3.so:
> Вот это почему-то пока не получается. Пока получилось или собрать

Я заинтересовался, в чём там хитрость с одной библиотекой.

Посмотрел лог поледней сборки 
http://git.altlinux.org/tasks/archive/done/_169/173812/build/100/x86_64/log 
. Понял, что это библиотека из состава libnss. Посмотрел .spec 
https://packages.altlinux.org/en/Sisyphus/srpms/palemoon/spec , увидел, 
что rpath передаётся через LDFLAGS. В логе видно, что до сборки libnss оно 
не доезжает (перекрывается):

make[5]: Entering directory 
`/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/config/external/nss'
rm -f libnss.a
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/_virtualenv/bin/python 
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/config/expandlibs_gen.py -o 
libnss.a.desc
mkdir -p '../../../security/nss/lib/ckfw/builtins/'
LDFLAGS=-Wl,--build-id make -C 
/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/security/nss/lib libs  CC=' 
gcc' SOURCE_MD_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist 
SOURCE_MDHEADERS_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/nspr 
DIST=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist 
NSPR_INCLUDE_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/nspr 
NSPR_LIB_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/lib 
MOZILLA_CLIENT=1 NO_MDUPDATE=1 NSS_ENABLE_ECC=1 SQLITE_LIB_NAME=mozsqlite3 
SQLITE_INCLUDE_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include 
topsrcdir='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon' 
BUILD='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/security/$(subst 
$(topsrcdir)/security/,,$(CURDIR))' BUILD_TREE='$(BUILD)' 
OBJDIR='$(BUILD)' DEPENDENCIES='$(BUILD)/.deps' 
SINGLE_SHLIB_DIR='$(BUILD)' 
SOURCE_XP_DIR=/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist 
BUILD_OPT=1 OPT_CODE_SIZE=1 NS_USE_GCC=1 USE_64=1 NSS_ENABLE_ZLIB= 
PROGRAMS= CHECKLOC= FREEBL_NO_DEPEND=0 FREEBL_LOWHASH=1 
NSS_NO_PKCS11_BYPASS=1 
PUBLIC_EXPORT_DIR='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/dist/include/$(MODULE)' 
SOURCE_XPHEADERS_DIR='$(SOURCE_XP_DIR)/include/$(MODULE)' 
MODULE_INCLUDES='$(addprefix -I$(SOURCE_XP_DIR)/include/,$(REQUIRES))' 
MAKE_OBJDIR='$(INSTALL) -D $(OBJDIR)' TARGETS='$(LIBRARY) 
$(SHARED_LIBRARY) $(PROGRAM)' 
NSINSTALL='/usr/src/RPM/BUILD/palemoon-27.0.2/palemoon/objdir/config/nsinstall'

Подумал, что это вообще не хорошо, если ставить перед собой задачу носить 
свой libnss с собой, что у всех библиотек из его состава не будет 
RPATH/RUNPATH и lib.req проставит все их зависимости между собой на 
системные библиотеки из состава libnss (оно попадает в сборочную среду). 
Как оно в реальности будет работать, я даже не знаю: системные или свои 
библиотеки будут загружаться... В общем, непредсказуемая путаница. (fgrep 
softok /ALT/Sisyphus/{noarch,x86_64}/base/contents_index показывает, что 
подобным образом устроен и пакет firefox-gost, но там не ставят 
RPATH/RUNPATH. Зависимостей на системные libnss там, правда, тоже не 
генерируют. Наверное, это работает благодаря другим механизмам, но плохо 
поддаётся автоматической проверке с помощью verify-elf.)

(А если не ставить перед собой такую задачу -- использовать свой libnss, 
то и паковать эти библиотеки не стоит.)

С помощью git grep LDFLAGS нашёл в исходниках место, где перекрывают 
LDFLAGS:

palemoon/security/build/Makefile.in-ifneq (,$(filter 
%--build-id,$(LDFLAGS)))
palemoon/security/build/Makefile.in:DEFAULT_GMAKE_ENV = 
LDFLAGS=-Wl,--build-id
palemoon/security/build/Makefile.in-endif
palemoon/security/build/Makefile.in-
--
palemoon/security/build/Makefile.in-
palemoon/security/build/Makefile.in-$(foreach p,libs export 
private_export,$(addprefix $(p)-,$(NSS_DIRS))):
palemoon/security/build/Makefile.in:    $(DEFAULT_GMAKE_ENV) $(MAKE) -C 
$(NSS_SRCDIR)/security/$* $(@:-$*=) $(DEFAULT_GMAKE_FLAGS)
palemoon/security/build/Makefile.in-

А в Google находится патч, убирающий это для сборки для RH, правда, без 
комментария, зачем это им было нужно:

https://git.centos.org/blob/rpms!firefox.git/4cf60e2cb865301a78018acf20fec7760c8927a9/SOURCES!build-el5-nss.patch

diff -up mozilla-aurora/config/external/nss/Makefile.in.build-el5-nss 
mozilla-aurora/config/external/nss/Makefile.in
--- mozilla-aurora/config/external/nss/Makefile.in.build-el5-nss 
2016-01-26 10:25:01.770613169 +0100
+++ mozilla-aurora/config/external/nss/Makefile.in	2016-01-26 
10:25:12.824599219 +0100
@@ -298,7 +298,7 @@ NSS_DIRS += \
  endif

  ifneq (,$(filter %--build-id,$(LDFLAGS)))
-DEFAULT_GMAKE_ENV = LDFLAGS=-Wl,--build-id
+#DEFAULT_GMAKE_ENV = LDFLAGS=-Wl,--build-id
  endif

  ifdef MOZ_FOLD_LIBS

Кажется, с этим патчем rpath из .spec доберётся и до библиотек nss. (Там 
их больше одной этой, но из-за того, что libnss была в сборочной среде, мы 
не видели сообщения про unresolved symbols про них.)

-- 
Best regards,
Ivan

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

[Hihin Ruslan]

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

Здравствуйте Ivan Zakharyaschev
  В сообщении от 4 декабря 2016 Ivan Zakharyaschev написал(a):
> А в Google находится патч, убирающий это для сборки для RH,
> правда, без комментария, зачем это им было нужно:
>
> https://git.centos.org/blob/rpms!firefox.git/4cf60e2cb865301a7
>8018acf20fec7760c8927a9/SOURCES!build-el5-nss.patch
Нашёл в коде:
palemoon/config/external/nss/moz.build 

" # TODO: The library name can be changed when bug 845217 is 
fixed."

А потом нашёл:

https://fossies.org/diffs/firefox/46.0.1.source_vs_47.0.source/config/external/nss/moz.build-diff.html

Не понял, где искать 845217, но похоже это связано. 
Как я понимаю, это "горячее".


-- 
  А ещё говорят так  (fortune): 
 
Pie are not square. Pie are round. Cornbread are square. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ivan Zakharyaschev]

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

On Sun, 4 Dec 2016, Hihin Ruslan wrote:

> Здравствуйте Ivan Zakharyaschev
>  В сообщении от 4 декабря 2016 Ivan Zakharyaschev написал(a):
>> А в Google находится патч, убирающий это для сборки для RH,
>> правда, без комментария, зачем это им было нужно:
>>
>> https://git.centos.org/blob/rpms!firefox.git/4cf60e2cb865301a7
>> 8018acf20fec7760c8927a9/SOURCES!build-el5-nss.patch
> Нашёл в коде:
> palemoon/config/external/nss/moz.build 
>
> " # TODO: The library name can be changed when bug 845217 is 
> fixed."

По-моему, это всё нас не очень сильно должно сейчас волновать, когда мы 
решаем простую задачу: передать-таки в сборку libnss опции для установки 
RPATH/RUNPATH (через LDFLAGS).

Приведённый мною короткий патч, наложенный в -alt1, должен решать эту 
задачу.

Ещё из замечаний к .spec -alt1 -- LD_LIBRARY_PATH в таком виде не надо 
выставлять, и вообще не надо выставлять (потому что в таком формате оно не 
работает -- см. man ld.so; и раз не работало, значит, и не нужно точно).

Другие изменения по сравнению с -alt1 у меня не возникает желания 
предложить.

Когда я писал предыдущее сообщение, я не видел Вашу новую сборку -alt2. Её 
внимательно изучать и комментировать не могу. Там видно по verify-elf, 
что замечаний стало только больше. Да и опечатка там: pat вместо path.

>
> А потом нашёл:
>
> https://fossies.org/diffs/firefox/46.0.1.source_vs_47.0.source/config/external/nss/moz.build-diff.html
>
> Не понял, где искать 845217, но похоже это связано. 
> Как я понимаю, это "горячее".


-- 
Best regards,
Ivan

[devel] [PATCH] verify-elf: honor RUNPATH, too ; was: Re: Проблема при сборке newmon 27.0

[Ivan Zakharyaschev]

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


On Sun, 27 Nov 2016, Ivan Zakharyaschev wrote:

>>  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, например.

Предлагаю патч для rpm. (Руслан, можете попробовать собрать, добавив в 
началао заданиясборку того же тега rpm, что в задании 173509.)

Subject: [PATCH] verify-elf: honor RUNPATH, too (like in lib.req.in:95 and debuginfo.req.in:76)

in addition to RPATH
---
  scripts/verify-elf.in | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/verify-elf.in b/scripts/verify-elf.in
index 316117f..6c30448 100755
--- a/scripts/verify-elf.in
+++ b/scripts/verify-elf.in
@@ -362,7 +362,7 @@ VerifyELF()
  		error_normal LINT "$f" 'eu-elflint failed'
  	fi

-	verify_rpath "$f" "$(printf %s "$objdump_info" |awk '{if ($1=="RPATH") print $2}')"
+	verify_rpath "$f" "$(printf %s "$objdump_info" |awk '{if ($1=="RPATH"||$1=="RUNPATH") print $2}')"

  	if [ -z "${t##*ELF* executable*}" -o -z "${t##*ELF* shared object*}" ]; then
  		verify_stack "$f"
@@ -376,7 +376,7 @@ VerifyELF()

  	if [ -z "${t##*ELF* executable*dynamically linked*}" -o -z "${t##*ELF* shared object*}" ]; then
  		verify_unresolved "$f" "$preload" "$fname" \
-			"$(printf %s "$objdump_info" |awk '{if ($1=="RPATH") print $2}' |tr -s : ' ' |sed -e "s|\$ORIGIN|${fname%/*}|g")"
+			"$(printf %s "$objdump_info" |awk '{if ($1=="RPATH"||$1=="RUNPATH") print $2}' |tr -s : ' ' |sed -e "s|\$ORIGIN|${fname%/*}|g")"
  		if [ -z "${t##*ELF 32-bit*}" ]; then
  			verify_lfs "$f"
  		fi
-- 


> 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
>> 
>

Re: [devel] [PATCH] verify-elf: honor RUNPATH, too ; was: Re: Проблема при сборке newmon 27.0

[Ivan Zakharyaschev]

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


On Sun, 27 Nov 2016, Ivan Zakharyaschev wrote:

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

Думаю, всё в порядке с этим измененем (с учётом улучшения, которое я 
привожу ниже). Теперь, например, при сборке tracker будет меньше 
предупреждений (там RUNPATH; но для чистоты от предупреждений можно будет 
ещё улучшить и ужесточить .spec). (Ещё при поиске примеров попался RUNPATH 
в elfutils, но он без пользы там.)

Проверил пересобираемость пары пакетов. coreutils и meshlab (там вообще-то 
тоже много предупреждений про плагины, которые можно было бы почистить с 
LD_PRELOAD для verify-elf, как например, в boost; ещё у меня давно был 
пример таких пакетов с плагинами -- запишу тут, чтобы можно было вернуться 
к проблеме: что-то вроде stk/lmms, но там получилось, что при сборке 
исполняемого файла как PIE ошибки verify-elf превращались в 
предупреждения, что является нежелательным поведением verify-elf вообще).

Решил улучшить это изменение -- ужесточить так, как на самом деле:

>From c8832527c5828c0d8532d9c44b52588e5c7b51aa Mon Sep 17 00:00:00 2001
From: Ivan Zakharyaschev <imz@altlinux.org>
Date: Tue, 29 Nov 2016 13:32:18 +0300
Subject: [PATCH] verify-elf: RUNPATH overrides RPATH for verify_unresolved

>From ld.so's documentation about the search order:

Using the directories specified in the DT_RPATH dynamic section
attribute of the binary if present and DT_RUNPATH attribute does not
exist. Use of DT_RPATH is deprecated.
---
  scripts/verify-elf.in | 9 ++++++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/scripts/verify-elf.in b/scripts/verify-elf.in
index 51ed9ce..412a30d 100755
--- a/scripts/verify-elf.in
+++ b/scripts/verify-elf.in
@@ -327,7 +327,7 @@ run_eu()

  VerifyELF()
  {
-	local f preload t objdump_info fname lint_info textrel
+	local f preload t objdump_info fname lint_info textrel rpath
  	f="$1"; shift
  	preload="$1"; shift
  	elf_segments=
@@ -376,8 +376,11 @@ VerifyELF()
  	fi

  	if [ -z "${t##*ELF* executable*dynamically linked*}" -o -z "${t##*ELF* shared object*}" ]; then
-		verify_unresolved "$f" "$preload" "$fname" \
-			"$(printf %s "$objdump_info" |awk '{if ($1=="RPATH"||$1=="RUNPATH") print $2}' |tr -s : ' ' |sed -e "s|\$ORIGIN|${fname%/*}|g")"
+        	rpath="$(printf %s "$objdump_info" |awk '{if ($1=="RUNPATH") print $2}' |tr -s : ' ' |sed -e "s|\$ORIGIN|${fname%/*}|g")"
+        	if [ -z "$rpath" ]; then
+        		rpath="$(printf %s "$objdump_info" |awk '{if ($1=="RPATH") print $2}' |tr -s : ' ' |sed -e "s|\$ORIGIN|${fname%/*}|g")"
+        	fi
+		verify_unresolved "$f" "$preload" "$fname" "$rpath"
  		if [ -z "${t##*ELF 32-bit*}" ]; then
  			verify_lfs "$f"
  		fi
-- 
2.7.4


> началао заданиясборку того же тега rpm, что в задании 173509.)
>
> Subject: [PATCH] verify-elf: honor RUNPATH, too (like in lib.req.in:95 and 
> debuginfo.req.in:76)
>
> in addition to RPATH
> ---
>  scripts/verify-elf.in | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/verify-elf.in b/scripts/verify-elf.in
> index 316117f..6c30448 100755
> --- a/scripts/verify-elf.in
> +++ b/scripts/verify-elf.in
> @@ -362,7 +362,7 @@ VerifyELF()
> 	 	error_normal LINT "$f" 'eu-elflint failed'
> 	 fi
>
> -	verify_rpath "$f" "$(printf %s "$objdump_info" |awk '{if 
> ($1=="RPATH") print $2}')"
> +	verify_rpath "$f" "$(printf %s "$objdump_info" |awk '{if 
> ($1=="RPATH"||$1=="RUNPATH") print $2}')"
>
> 	 if [ -z "${t##*ELF* executable*}" -o -z "${t##*ELF* shared object*}"
> 	 ]; then
> 		verify_stack "$f"
> @@ -376,7 +376,7 @@ VerifyELF()
>
> 	 if [ -z "${t##*ELF* executable*dynamically linked*}" -o -z
> 	 "${t##*ELF* shared object*}" ]; then
> 		verify_unresolved "$f" "$preload" "$fname" \
> -			"$(printf %s "$objdump_info" |awk '{if ($1=="RPATH") 
> print $2}' |tr -s : ' ' |sed -e "s|\$ORIGIN|${fname%/*}|g")"
> +			"$(printf %s "$objdump_info" |awk '{if 
> ($1=="RPATH"||$1=="RUNPATH") print $2}' |tr -s : ' ' |sed -e 
> "s|\$ORIGIN|${fname%/*}|g")"
> 		 if [ -z "${t##*ELF 32-bit*}" ]; then
> 		 	verify_lfs "$f"
> 		fi
> -- 
>
>
>> 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
>> > 
>> 
>

Re: [devel] Что такое runpath ?

[Hihin Ruslan]

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

Здравствуйте Alexey Tourbin
  В сообщении от 13 ноября 2016 Alexey Tourbin написал(a):
> > ...
> > 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 , нахожу:

http://stackoverflow.com/questions/7967848/use-rpath-but-not-runpath
	
"problem is, RUNPATH is recommended over RPATH, and RPATH is 
deprecated, but RUNPATH is currently not supported by all 
systems. so what I do today to make application work? as Qt 
article show, when using plugins it is useful to use RPATH more 
than RUNPATH. so the whole situation is very confusing here" 

Со своим знанием английского, понимаю только то, что эта какая-то 
новая фича, которая заменяет RPATH.
Правильно-ли я понимаю, что у нас пока (??) он не поддерживается 
(RPM ??? )  и мне надо разбираться, почему у меня где-то 
включился соответствующий ключ? Как я понял, если стоят оба 
ключа - собирать и RUNPATH и RPATH, то собирается RPATH, a 
chrpath умеет превращать RPATH в RUNPATH, но не наоборот?

Просто объясните - в каком направлении двигаться - удалять 
RUNPATH, или вешать багу на наш rpm ?

PS Может он не только rpm не поддерживается, но и вообще эта фича 
у нас не работает? 


-- 
  А ещё говорят так  (fortune): 
 
Be free and open and breezy! Enjoy! Things won't get any better 
so get used to it. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Что такое runpath ?

[Hihin Ruslan]

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

Здравствуйте Hihin Ruslan
  В сообщении от 19 ноября 2016 Hihin Ruslan написал(a):

Описка:
> Как я понял, если стоят оба
> ключа - собирать и RUNPATH и RPATH, то собирается RPATH, a
> chrpath умеет превращать RPATH в RUNPATH, но не наоборот?

Как я понял:

- если стоят оба ключа - собирать и RUNPATH и RPATH, то 
собирается RUNPATH. 

- chrpath умеет превращать RPATH в RUNPATH, но не умеет наоборот.


-- 
  А ещё говорят так  (fortune): 
 
It is better to have loved a short man than never to have loved a 
tall. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Что такое runpath ?

[Hihin Ruslan]

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

Здравствуйте Hihin Ruslan
  В сообщении от 19 ноября 2016 Hihin Ruslan написал(a):

Вот ещё:

https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638

-- 
  А ещё говорят так  (fortune): 
 
If you want your program to be readable, consider supplying the 
argument. -- Larry Wall in the perl man page 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Что такое runpath ?

[Ivan Zakharyaschev]

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


On Sat, 19 Nov 2016, Hihin Ruslan wrote:

> Правильно-ли я понимаю, что у нас пока (??) он не поддерживается 
> (RPM ??? )  и мне надо разбираться, почему у меня где-то 
> включился соответствующий ключ? Как я понял, если стоят оба 
> ключа - собирать и RUNPATH и RPATH, то собирается RPATH, a 
> chrpath умеет превращать RPATH в RUNPATH, но не наоборот?
>
> Просто объясните - в каком направлении двигаться - удалять 
> RUNPATH, или вешать багу на наш rpm ?
>
> PS Может он не только rpm не поддерживается, но и вообще эта фича 
> у нас не работает?

А может быть, RUNPATH работает и поддерживается. И тот бинарник, где Вы 
его наблюдаете, тоже работает и проходит verify-elf.

А не проходит через verify-elf другой бинарник, который возникает во время 
сборки, а не тот, который Вы рассматривали с помощью objdump.

-- 
Best regards,
Ivan