[devel] gear и hasher: ошибка

[devel] gear и hasher: ошибка

[Anton Farygin]

Вроде как раньше я такого не наблюдал, а теперь вылезло:

$ gear --hasher -- hsh ~/hasher/
Components: hasher
Processing pkglists... hasher done
Processing srclists...  hasher done
Creating component releases... done
Updating global release file... done
Appending MD5Sum... hasher done
All your base are belong to us!!!
Preparing packages for installation...
hostinfo-2.2-alt2
libssl-0.9.7g-alt4
libssl-devel-0.9.7g-alt4
zlib-devel-1.2.3-alt3
gcc-c++-common-1.4.10-alt1
gcc-fortran-common-1.4.10-alt1
libstdc++4.1-4.1.1-alt5
libstdc++4.1-devel-4.1.1-alt5
gcc4.1-c++-4.1.1-alt5
libgfortran4.1-4.1.1-alt5
libgfortran4.1-devel-4.1.1-alt5
libgmp-4.1.4-alt4
libmpfr-2.2.0-alt1
gcc4.1-fortran-4.1.1-alt5
groff-base-1.19.2-alt2
libidn-0.6.3-alt1
libidn-devel-0.6.3-alt1
Building target platforms: x86_64
Building for target x86_64
Wrote: /usr/src/in/srpm/curl-7.15.5-alt1.src.rpm
./curl-7.15.5-alt1.src.rpm: wrong PACKAGER: Automated package hasher 
<hasher@localhost>
ERROR: you have problems with packager name
rebuild: pkg.tar: sisyphus_check failed.

Как прописать PACKAGER, не подскажете ? ~/.rpmmacros прописан, но не 
помогает ;(

Rgds,
Rider

Re: [devel] gear и hasher: ошибка

[Dmitry V. Levin]

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

On Wed, Sep 13, 2006 at 04:46:54PM +0400, Anton Farygin wrote:
> Вроде как раньше я такого не наблюдал, а теперь вылезло:
> 
> $ gear --hasher -- hsh ~/hasher/
[...]
> ./curl-7.15.5-alt1.src.rpm: wrong PACKAGER: Automated package hasher 
> <hasher@localhost>
> ERROR: you have problems with packager name
> rebuild: pkg.tar: sisyphus_check failed.
> 
> Как прописать PACKAGER, не подскажете ? ~/.rpmmacros прописан, но не 
> помогает ;(

См. /usr/share/doc/gear-1.0.2/QUICKSTART.ru_RU.KOI8-R, ключевое слово
Packager.

Кроме того, есть ещё один workaround: hsh --packager.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] gear и hasher: ошибка

[Anton Farygin]

Dmitry V. Levin wrote:
> On Wed, Sep 13, 2006 at 04:46:54PM +0400, Anton Farygin wrote:
>> Вроде как раньше я такого не наблюдал, а теперь вылезло:
>>
>> $ gear --hasher -- hsh ~/hasher/
> [...]
>> ./curl-7.15.5-alt1.src.rpm: wrong PACKAGER: Automated package hasher 
>> <hasher@localhost>
>> ERROR: you have problems with packager name
>> rebuild: pkg.tar: sisyphus_check failed.
>>
>> Как прописать PACKAGER, не подскажете ? ~/.rpmmacros прописан, но не 
>> помогает ;(
> 
> См. /usr/share/doc/gear-1.0.2/QUICKSTART.ru_RU.KOI8-R, ключевое слово
> Packager.
> 
> Кроме того, есть ещё один workaround: hsh --packager.

Ага.. спасибо, то, что и искалось.. всего-то полтора месяца gear не 
запускал, а изменений масса ;)

Rgds,
Rider

Re: [devel] gear и hasher: ошибка

[Dmitry V. Levin]

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

On Wed, Sep 13, 2006 at 05:06:56PM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Wed, Sep 13, 2006 at 04:46:54PM +0400, Anton Farygin wrote:
> >> Вроде как раньше я такого не наблюдал, а теперь вылезло:
> >>
> >> $ gear --hasher -- hsh ~/hasher/
> > [...]
> >> ./curl-7.15.5-alt1.src.rpm: wrong PACKAGER: Automated package hasher 
> >> <hasher@localhost>
> >> ERROR: you have problems with packager name
> >> rebuild: pkg.tar: sisyphus_check failed.
> >>
> >> Как прописать PACKAGER, не подскажете ? ~/.rpmmacros прописан, но не 
> >> помогает ;(
> > 
> > См. /usr/share/doc/gear-1.0.2/QUICKSTART.ru_RU.KOI8-R, ключевое слово
> > Packager.
> > 
> > Кроме того, есть ещё один workaround: hsh --packager.
> 
> Ага.. спасибо, то, что и искалось.. всего-то полтора месяца gear не 
> запускал, а изменений масса ;)

Дело не совсем в этом, тебе просто раньше не приходилось запускать
gear --hasher :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] gear и hasher: ошибка

[Anton Farygin]

Dmitry V. Levin wrote:
> On Wed, Sep 13, 2006 at 05:06:56PM +0400, Anton Farygin wrote:
>> Dmitry V. Levin wrote:
>>> On Wed, Sep 13, 2006 at 04:46:54PM +0400, Anton Farygin wrote:
>>>> Вроде как раньше я такого не наблюдал, а теперь вылезло:
>>>>
>>>> $ gear --hasher -- hsh ~/hasher/
>>> [...]
>>>> ./curl-7.15.5-alt1.src.rpm: wrong PACKAGER: Automated package hasher 
>>>> <hasher@localhost>
>>>> ERROR: you have problems with packager name
>>>> rebuild: pkg.tar: sisyphus_check failed.
>>>>
>>>> Как прописать PACKAGER, не подскажете ? ~/.rpmmacros прописан, но не 
>>>> помогает ;(
>>> См. /usr/share/doc/gear-1.0.2/QUICKSTART.ru_RU.KOI8-R, ключевое слово
>>> Packager.
>>>
>>> Кроме того, есть ещё один workaround: hsh --packager.
>> Ага.. спасибо, то, что и искалось.. всего-то полтора месяца gear не 
>> запускал, а изменений масса ;)
> 
> Дело не совсем в этом, тебе просто раньше не приходилось запускать
> gear --hasher :)

да, кстати вполне может быть..

кстати, запускал я его по весьма интересной причине - глючит verify-elf, 
если пакет собирать в хост системе и этот глюк не вылезает в hasher'е 
(что естественно).

Глюк заключается в том, что verify-elf запускает ldd -r на бинарник, 
который слинкован с библиотекой из новой версии пакета. А в ней появился 
новый символ (без смены soname).. соответственно новый бинарник очень 
хочет этот новый символ, который старая библиотека не представляет.. ну 
и verify-elf на этом вылетает. Как бы его научить искать библиотеки 
сначала в %buildroot, а уже потом - в системе ?

Rgds,
Rider

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Wed, Sep 13, 2006 at 05:21:26PM +0400, Anton Farygin wrote:
[...]
> кстати, запускал я его по весьма интересной причине - глючит verify-elf, 
> если пакет собирать в хост системе и этот глюк не вылезает в hasher'е 
> (что естественно).
> 
> Глюк заключается в том, что verify-elf запускает ldd -r на бинарник, 
> который слинкован с библиотекой из новой версии пакета. А в ней появился 
> новый символ (без смены soname).. соответственно новый бинарник очень 
> хочет этот новый символ, который старая библиотека не представляет.. ну 
> и verify-elf на этом вылетает. Как бы его научить искать библиотеки 
> сначала в %buildroot, а уже потом - в системе ?

Вообще-то я предпринимал определённые усилия по вычислению правильного
LD_LIBRARY_PATH, чтобы системные библиотеки проверялись в последнюю
очередь.  Ты можешь добавить "set -x" в системный /usr/lib/rpm/verify-elf
и посмотреть, что там происходит на самом деле?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Anton Farygin]

Dmitry V. Levin wrote:
> On Wed, Sep 13, 2006 at 05:21:26PM +0400, Anton Farygin wrote:
> [...]
>> кстати, запускал я его по весьма интересной причине - глючит verify-elf, 
>> если пакет собирать в хост системе и этот глюк не вылезает в hasher'е 
>> (что естественно).
>>
>> Глюк заключается в том, что verify-elf запускает ldd -r на бинарник, 
>> который слинкован с библиотекой из новой версии пакета. А в ней появился 
>> новый символ (без смены soname).. соответственно новый бинарник очень 
>> хочет этот новый символ, который старая библиотека не представляет.. ну 
>> и verify-elf на этом вылетает. Как бы его научить искать библиотеки 
>> сначала в %buildroot, а уже потом - в системе ?
> 
> Вообще-то я предпринимал определённые усилия по вычислению правильного
> LD_LIBRARY_PATH, чтобы системные библиотеки проверялись в последнюю
> очередь.  Ты можешь добавить "set -x" в системный /usr/lib/rpm/verify-elf
> и посмотреть, что там происходит на самом деле?

конечно.

Там выполняется вот такая команда:
  $ RPM_BUILD_ROOT=/home/rider/git.alt/curl/TMP/curl-buildroot/usr 
/usr/lib/rpm/ldd --undefined -- ./usr/bin/curl 
/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64
         libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002ab157ae0000)
         libz.so.1 => /lib64/libz.so.1 (0x00002ab157c33000)
         libc.so.6 => /lib64/libc.so.6 (0x00002ab157d48000)
         libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002ab157f6e000)
         libssl.so.4 => /lib64/libssl.so.4 (0x00002ab1581a0000)
         libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002ab1583d7000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00002ab158719000)
         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
undefined symbol: curl_easy_escape      (./usr/bin/curl)

Возникает ощущение, что о втором аргументе ldd ничего не знает.

Rgds,
Rider

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Wed, Sep 13, 2006 at 06:24:29PM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Wed, Sep 13, 2006 at 05:21:26PM +0400, Anton Farygin wrote:
> > [...]
> >> кстати, запускал я его по весьма интересной причине - глючит verify-elf, 
> >> если пакет собирать в хост системе и этот глюк не вылезает в hasher'е 
> >> (что естественно).
> >>
> >> Глюк заключается в том, что verify-elf запускает ldd -r на бинарник, 
> >> который слинкован с библиотекой из новой версии пакета. А в ней появился 
> >> новый символ (без смены soname).. соответственно новый бинарник очень 
> >> хочет этот новый символ, который старая библиотека не представляет.. ну 
> >> и verify-elf на этом вылетает. Как бы его научить искать библиотеки 
> >> сначала в %buildroot, а уже потом - в системе ?
> > 
> > Вообще-то я предпринимал определённые усилия по вычислению правильного
> > LD_LIBRARY_PATH, чтобы системные библиотеки проверялись в последнюю
> > очередь.  Ты можешь добавить "set -x" в системный /usr/lib/rpm/verify-elf
> > и посмотреть, что там происходит на самом деле?
> 
> конечно.
> 
> Там выполняется вот такая команда:
>   $ RPM_BUILD_ROOT=/home/rider/git.alt/curl/TMP/curl-buildroot/usr 
> /usr/lib/rpm/ldd --undefined -- ./usr/bin/curl 
> /home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64

Неплохая команда. :)

> Возникает ощущение, что о втором аргументе ldd ничего не знает.

"set -x" в /usr/lib/rpm/verify-elf больше не нужен, попробуй теперь
посмотреть отладочный вывод у /usr/lib/rpm/ldd.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Anton Farygin]

Dmitry V. Levin wrote:
> On Wed, Sep 13, 2006 at 06:24:29PM +0400, Anton Farygin wrote:
>> Dmitry V. Levin wrote:
>>> On Wed, Sep 13, 2006 at 05:21:26PM +0400, Anton Farygin wrote:
>>> [...]
>>>> кстати, запускал я его по весьма интересной причине - глючит verify-elf, 
>>>> если пакет собирать в хост системе и этот глюк не вылезает в hasher'е 
>>>> (что естественно).
>>>>
>>>> Глюк заключается в том, что verify-elf запускает ldd -r на бинарник, 
>>>> который слинкован с библиотекой из новой версии пакета. А в ней появился 
>>>> новый символ (без смены soname).. соответственно новый бинарник очень 
>>>> хочет этот новый символ, который старая библиотека не представляет.. ну 
>>>> и verify-elf на этом вылетает. Как бы его научить искать библиотеки 
>>>> сначала в %buildroot, а уже потом - в системе ?
>>> Вообще-то я предпринимал определённые усилия по вычислению правильного
>>> LD_LIBRARY_PATH, чтобы системные библиотеки проверялись в последнюю
>>> очередь.  Ты можешь добавить "set -x" в системный /usr/lib/rpm/verify-elf
>>> и посмотреть, что там происходит на самом деле?
>> конечно.
>>
>> Там выполняется вот такая команда:
>> Возникает ощущение, что о втором аргументе ldd ничего не знает.
> 
> "set -x" в /usr/lib/rpm/verify-elf больше не нужен, попробуй теперь
> посмотреть отладочный вывод у /usr/lib/rpm/ldd.

/lib64/ld-linux-x86-64.so.2 --library-path 
/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64 
./usr/bin/curl
         libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002b5081dc3000)
         libz.so.1 => /lib64/libz.so.1 (0x00002b5081f16000)
         libc.so.6 => /lib64/libc.so.6 (0x00002b508202b000)
         libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b5082251000)
         libssl.so.4 => /lib64/libssl.so.4 (0x00002b5082483000)
         libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002b50826ba000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00002b50829fc000)
         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
undefined symbol: curl_easy_escape      (./usr/bin/curl)


Т.е. - он то знает, а вот
/lib64/ld-linux-x86-64.so.2 почему-то это всё игнорирует ;(

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Wed, Sep 13, 2006 at 07:11:30PM +0400, Anton Farygin wrote:
[...]
> /lib64/ld-linux-x86-64.so.2 --library-path 
> /home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64 
> ./usr/bin/curl
>          libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002b5081dc3000)
>          libz.so.1 => /lib64/libz.so.1 (0x00002b5081f16000)
>          libc.so.6 => /lib64/libc.so.6 (0x00002b508202b000)
>          libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b5082251000)
>          libssl.so.4 => /lib64/libssl.so.4 (0x00002b5082483000)
>          libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002b50826ba000)
>          libdl.so.2 => /lib64/libdl.so.2 (0x00002b50829fc000)
>          /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
> undefined symbol: curl_easy_escape      (./usr/bin/curl)
> 
> 
> Т.е. - он то знает, а вот
> /lib64/ld-linux-x86-64.so.2 почему-то это всё игнорирует ;(

Причина, скорее всего, внутри ./usr/bin/curl; покажи мне, пожалуйста,
вывод от
readelf -d /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl
?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Anton Farygin]

Dmitry V. Levin wrote:
> On Wed, Sep 13, 2006 at 07:11:30PM +0400, Anton Farygin wrote:
> [...]
>> /lib64/ld-linux-x86-64.so.2 --library-path 
>> /home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64 
>> ./usr/bin/curl
>>          libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002b5081dc3000)
>>          libz.so.1 => /lib64/libz.so.1 (0x00002b5081f16000)
>>          libc.so.6 => /lib64/libc.so.6 (0x00002b508202b000)
>>          libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b5082251000)
>>          libssl.so.4 => /lib64/libssl.so.4 (0x00002b5082483000)
>>          libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002b50826ba000)
>>          libdl.so.2 => /lib64/libdl.so.2 (0x00002b50829fc000)
>>          /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
>> undefined symbol: curl_easy_escape      (./usr/bin/curl)
>>
>>
>> Т.е. - он то знает, а вот
>> /lib64/ld-linux-x86-64.so.2 почему-то это всё игнорирует ;(
> 
> Причина, скорее всего, внутри ./usr/bin/curl; покажи мне, пожалуйста,
> вывод от
> readelf -d /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl
> ?

$ readelf -d /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl

Dynamic section at offset 0x16458 contains 23 entries:
   Tag        Type                         Name/Value
  0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.3]
  0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
  0x000000000000000f (RPATH)              Library rpath: [/usr/lib64]
  0x000000000000000c (INIT)               0x401c38
  0x000000000000000d (FINI)               0x409088
  0x0000000000000004 (HASH)               0x400240
  0x0000000000000005 (STRTAB)             0x400f48
  0x0000000000000006 (SYMTAB)             0x400648
  0x000000000000000a (STRSZ)              1027 (bytes)
  0x000000000000000b (SYMENT)             24 (bytes)
  0x0000000000000015 (DEBUG)              0x0
  0x0000000000000003 (PLTGOT)             0x616620
  0x0000000000000002 (PLTRELSZ)           1944 (bytes)
  0x0000000000000014 (PLTREL)             RELA
  0x0000000000000017 (JMPREL)             0x4014a0
  0x0000000000000007 (RELA)               0x401440
  0x0000000000000008 (RELASZ)             96 (bytes)
  0x0000000000000009 (RELAENT)            24 (bytes)
  0x000000006ffffffe (VERNEED)            0x401410
  0x000000006fffffff (VERNEEDNUM)         1
  0x000000006ffffff0 (VERSYM)             0x40134c
  0x0000000000000000 (NULL)               0x0

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 09:49:23AM +0400, Anton Farygin wrote:
> Dmitry V. Levin wrote:
> > On Wed, Sep 13, 2006 at 07:11:30PM +0400, Anton Farygin wrote:
> > [...]
> >> /lib64/ld-linux-x86-64.so.2 --library-path 
> >> /home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64 
> >> ./usr/bin/curl
> >>          libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002b5081dc3000)
> >>          libz.so.1 => /lib64/libz.so.1 (0x00002b5081f16000)
> >>          libc.so.6 => /lib64/libc.so.6 (0x00002b508202b000)
> >>          libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b5082251000)
> >>          libssl.so.4 => /lib64/libssl.so.4 (0x00002b5082483000)
> >>          libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002b50826ba000)
> >>          libdl.so.2 => /lib64/libdl.so.2 (0x00002b50829fc000)
> >>          /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
> >> undefined symbol: curl_easy_escape      (./usr/bin/curl)
> >>
> >>
> >> Т.е. - он то знает, а вот
> >> /lib64/ld-linux-x86-64.so.2 почему-то это всё игнорирует ;(
> > 
> > Причина, скорее всего, внутри ./usr/bin/curl; покажи мне, пожалуйста,
> > вывод от
> > readelf -d /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl
> > ?
> 
> $ readelf -d /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl
> 
> Dynamic section at offset 0x16458 contains 23 entries:
>    Tag        Type                         Name/Value
>   0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.3]
>   0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
>   0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>   0x000000000000000f (RPATH)              Library rpath: [/usr/lib64]

Вот и причина.  Убери этот RPATH, пожалуйста.
А я добавлю параметр --inhibit-rpath в команду вызова ld.so.

/lib64/ld-linux-x86-64.so.2 --inhibit-rpath --library-path то_что_у_тебя_было /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl будет работать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Thu, Sep 14, 2006 at 10:08:25PM +0300, Michael Shigorin wrote:
> On Thu, Sep 14, 2006 at 04:25:12PM +0400, Dmitry V. Levin wrote:
> > А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
> 
> А этот антикомар сильно кусается, по предварительным оценкам? :)

Если правильно составить --library-path, то не кусается.
Мне, очевидно, недостаточно просто --inhibit-rpath добавить,
придётся адаптировать алгоритм вычисления --library-path.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Alexey Tourbin]

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

On Thu, Sep 14, 2006 at 11:11:44PM +0400, Dmitry V. Levin wrote:
> On Thu, Sep 14, 2006 at 10:08:25PM +0300, Michael Shigorin wrote:
> > On Thu, Sep 14, 2006 at 04:25:12PM +0400, Dmitry V. Levin wrote:
> > > А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
> > 
> > А этот антикомар сильно кусается, по предварительным оценкам? :)
> 
> Если правильно составить --library-path, то не кусается.
> Мне, очевидно, недостаточно просто --inhibit-rpath добавить,
> придётся адаптировать алгоритм вычисления --library-path.

Я ещё год назад говорил что --inhibit-rpath придется делать и даже
алгоритм предлагал!

[-- Attachment #1.2: verify_elfsym --]
[-- Type: text/plain, Size: 3172 bytes --]

#!/bin/sh -ef

. /usr/lib/rpm/functions
[ -z "$RPM_BUILD_ROOT" ] || ValidateBuildRoot

RTLD=/lib/ld-linux.so.2
RTLD_libpath=/lib:/usr/lib:/usr/X11R6/lib

elf1_libpath()
{
	local elf="$1" libpath="$RTLD_libpath"
	[ -z "$LD_LIBRARY_PATH" ] ||
		libpath="$LD_LIBRARY_PATH:$libpath"
	[ -z "$RPM_FINDPROV_LIB_PATH" ] ||
		libpath="$RPM_FINDPROV_LIB_PATH:$libpath"
	local info= rpath=
	info="$(objdump -p "$elf")" || return
	rpath="$(echo "$info" |awk '($1=="RPATH"){printf "%s:", $2}')"
	[ -z "$rpath" ] ||
		libpath="$rpath$libpath"
	if [ -n "$RPM_BUILD_ROOT" ]; then
		local BR_libpath= path= IFS=:
		for path in $libpath; do
			BR_libpath="$BR_libpath:$RPM_BUILD_ROOT$path"
		done
		libpath="${BR_libpath#:}:$libpath"
	fi
	echo "$libpath"
}

elf1_ldd()
{
	local elf="$1" libpath=
	libpath="$(elf1_libpath "$elf")" || return
	LD_TRACE_LOADED_OBJECTS=1 LD_WARN=1 LD_BIND_NOW=1 LD_VERBOSE= \
		"$RTLD" --library-path "$libpath" --inhibit-rpath "$elf" "$elf"
}

elf1_undefined_symbols()
{
	local elf="$1" out=
	if ! out="$(elf1_ldd "$elf" 2>&1)"; then
		echo "$PROG: $elf: ldd failed:" >&2
		echo "$out" >&2
		return 2
	fi
	if [ -n "$out" -a -z "${out##* not found*}" ]; then
		echo "$PROG: $elf: unresolved dependencies:" >&2
		echo "$out" |grep -F ' not found' >&2
		return 1
	fi
	if [ -n "$out" -a -z "${out##*undefined symbol:*}" ]; then
		echo "$out" |awk '/^undefined symbol:/ {
			gsub("^[(]|[)]$", "", $NF)
			print $3 "\t" $NF }'
	fi
}

elf1_verify_strict()
{
	local elf="$1" err=
	err="$(elf1_undefined_symbols "$elf")" || return 2
	[ -n "$err" ] || return 0
	local sym= obj=
	while IFS=$'\t' read -r sym obj; do
		[ "$obj" = "$elf" ] &&
			echo "$PROG: $elf: undefined symbol: $sym" >&2 ||
			echo "$PROG: $elf: undefined symbol: $sym ($obj)" >&2
	done <<<"$err"
	return 1
}

elf1_verify_relaxed()
{
	local elf="$1" symtab="$2" err=
	err="$(elf1_undefined_symbols "$elf")" || return 2
	[ -n "$err" ] || return 0
	local rc=0 sym= obj=
	while IFS=$'\t' read -r sym obj; do
		if [ "$obj" != "$elf" ]; then
			echo "$PROG: $elf: undefined symbol: $sym ($obj)" >&2
			rc=1
		elif ! bloom -e "$sym" "$symtab"; then
			echo "$PROG: $elf: undefined symbol: $sym" >&2
			rc=1
		fi
	done <<<"$err"
	return $rc
}	

: ${VERIFY_ELF_SYM:=normal}
case "$VERIFY_ELF_SYM" in
	strict|normal|relaxed) : ;;
	no|none|skip) exit 0 ;;
	*) Fatal "Unrecognized $PROG method: $VERIFY_ELF_SYM" ;;
esac

rc=0 symtab="$1"
shift

for elf; do
	if ! type="$(file -bL "$elf")"; then
		echo "$PROG: $elf: $type" >&2
		rc=1
		continue
	fi
		
	[ -n "$type" ] || continue
	[ -z "${type##*ELF*dynamic*}" -o -z "${type##*ELF*shared*}" ] || continue

	if [ "$VERIFY_ELF_SYM" = strict ]; then
		elf1_verify_strict "$elf" || rc=1
	elif [ "$VERIFY_ELF_SYM" = relaxed ]; then
		elf1_verify_relaxed "$elf" "$symtab" || rc=1
	elif [ -z "${type##*ELF*executable*}" ]; then
		elf1_verify_strict "$elf" || rc=1
	elif [ -z "${type##*ELF*shared*}" -a -z "${elf##*/lib/lib*.so*}" ]; then
		elf1_verify_strict "$elf" || rc=1
	else
		elf1_verify_relaxed "$elf" "$symtab" || rc=1
	fi	
done
exit $rc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Fri, Sep 15, 2006 at 02:04:16AM +0400, Alexey Tourbin wrote:
> On Thu, Sep 14, 2006 at 11:11:44PM +0400, Dmitry V. Levin wrote:
> > On Thu, Sep 14, 2006 at 10:08:25PM +0300, Michael Shigorin wrote:
> > > On Thu, Sep 14, 2006 at 04:25:12PM +0400, Dmitry V. Levin wrote:
> > > > А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
> > > 
> > > А этот антикомар сильно кусается, по предварительным оценкам? :)
> > 
> > Если правильно составить --library-path, то не кусается.
> > Мне, очевидно, недостаточно просто --inhibit-rpath добавить,
> > придётся адаптировать алгоритм вычисления --library-path.
> 
> Я ещё год назад говорил что --inhibit-rpath придется делать и даже
> алгоритм предлагал!

Видел я его, когда делал verify-elf.  Хотелось сделать попроще, как обычно...
Собственно говоря, всё необходимое уже есть.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Sep 14, 2006 at 09:49:23AM +0400, Anton Farygin wrote:
>> Dmitry V. Levin wrote:
>>> On Wed, Sep 13, 2006 at 07:11:30PM +0400, Anton Farygin wrote:
>>> [...]
>>>> /lib64/ld-linux-x86-64.so.2 --library-path 
>>>> /home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/lib64:/home/rider/git.alt/curl/TMP/curl-buildroot/usr/X11R6/lib64 
>>>> ./usr/bin/curl
>>>>          libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x00002b5081dc3000)
>>>>          libz.so.1 => /lib64/libz.so.1 (0x00002b5081f16000)
>>>>          libc.so.6 => /lib64/libc.so.6 (0x00002b508202b000)
>>>>          libidn.so.11 => /usr/lib64/libidn.so.11 (0x00002b5082251000)
>>>>          libssl.so.4 => /lib64/libssl.so.4 (0x00002b5082483000)
>>>>          libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002b50826ba000)
>>>>          libdl.so.2 => /lib64/libdl.so.2 (0x00002b50829fc000)
>>>>          /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
>>>> undefined symbol: curl_easy_escape      (./usr/bin/curl)
>>>>
>>>>
>>>> Т.е. - он то знает, а вот
>>>> /lib64/ld-linux-x86-64.so.2 почему-то это всё игнорирует ;(
>>> Причина, скорее всего, внутри ./usr/bin/curl; покажи мне, пожалуйста,
>>> вывод от
>>> readelf -d /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl
>>> ?
>> $ readelf -d /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl
>>
>> Dynamic section at offset 0x16458 contains 23 entries:
>>    Tag        Type                         Name/Value
>>   0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.3]
>>   0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
>>   0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>   0x000000000000000f (RPATH)              Library rpath: [/usr/lib64]
> 
> Вот и причина.  Убери этот RPATH, пожалуйста.
> А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
> 
> /lib64/ld-linux-x86-64.so.2 --inhibit-rpath --library-path то_что_у_тебя_было /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl будет работать.

Параметр ты пока ещё похоже не добавил, а с rpath тут не всё так просто ;(

насколько я понял - rpath вылезает из aclocal.m4 Но вот по какой причине 
и как с этим бороться - я не понимаю.

Вижу в aclocal.m4:
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'

Соответственно это попадает в configure.in а уже оттуда - в Makefile.

перегенерация aclocal не помогает ;(

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Thu, Sep 21, 2006 at 10:09:06AM +0400, Anton Farygin wrote:
> > Вот и причина.  Убери этот RPATH, пожалуйста.
> > А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
> > 
> > /lib64/ld-linux-x86-64.so.2 --inhibit-rpath --library-path то_что_у_тебя_было /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl будет работать.
> 
> Параметр ты пока ещё похоже не добавил,

Добавлю обязательно.

> а с rpath тут не всё так просто ;(
> 
> насколько я понял - rpath вылезает из aclocal.m4 Но вот по какой причине 
> и как с этим бороться - я не понимаю.

Файл aclocal.m4 формируется при запуске aclocal.
Осталось найти источник, из которого это берётся.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Anton Farygin]

Dmitry V. Levin wrote:
> On Thu, Sep 21, 2006 at 10:09:06AM +0400, Anton Farygin wrote:
>>> Вот и причина.  Убери этот RPATH, пожалуйста.
>>> А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
>>>
>>> /lib64/ld-linux-x86-64.so.2 --inhibit-rpath --library-path то_что_у_тебя_было /home/rider/git.alt/curl/TMP/curl-buildroot/usr/bin/curl будет работать.
>> Параметр ты пока ещё похоже не добавил,
> 
> Добавлю обязательно.
> 
>> а с rpath тут не всё так просто ;(
>>
>> насколько я понял - rpath вылезает из aclocal.m4 Но вот по какой причине 
>> и как с этим бороться - я не понимаю.
> 
> Файл aclocal.m4 формируется при запуске aclocal.
> Осталось найти источник, из которого это берётся.

Я нашёл только одно упоминание переменной hardcode_libdir_flag_spec:
/usr/share/aclocal/lib-link.m4:dnl libext, shlibext, 
hardcode_libdir_flag_spec, hardcode_libdir_separator,
/usr/share/aclocal/lib-link.m4: 
hardcode_libdir_flag_spec="$acl_cv_hardcode_libdir_flag_spec"
/usr/share/aclocal/lib-link.m4:                  if test -n 
"$hardcode_libdir_flag_spec" && test "$hardcode_minus_L" = no; then
/usr/share/aclocal/lib-link.m4:      dnl Note: hardcode_libdir_flag_spec 
uses $libdir and $wl.
/usr/share/aclocal/lib-link.m4:      eval 
flag=\"$hardcode_libdir_flag_spec\"
/usr/share/aclocal/lib-link.m4:        eval 
flag=\"$hardcode_libdir_flag_spec\"

Re: [devel] verify-elf

[Dmitry V. Levin]

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

On Fri, Sep 15, 2006 at 02:36:22AM +0400, Dmitry V. Levin wrote:
> On Fri, Sep 15, 2006 at 02:04:16AM +0400, Alexey Tourbin wrote:
> > On Thu, Sep 14, 2006 at 11:11:44PM +0400, Dmitry V. Levin wrote:
> > > On Thu, Sep 14, 2006 at 10:08:25PM +0300, Michael Shigorin wrote:
> > > > On Thu, Sep 14, 2006 at 04:25:12PM +0400, Dmitry V. Levin wrote:
> > > > > А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
> > > > 
> > > > А этот антикомар сильно кусается, по предварительным оценкам? :)
> > > 
> > > Если правильно составить --library-path, то не кусается.
> > > Мне, очевидно, недостаточно просто --inhibit-rpath добавить,
> > > придётся адаптировать алгоритм вычисления --library-path.
> > 
> > Я ещё год назад говорил что --inhibit-rpath придется делать и даже
> > алгоритм предлагал!
> 
> Видел я его, когда делал verify-elf.  Хотелось сделать попроще, как обычно...
> Собственно говоря, всё необходимое уже есть.

Оказывается, ты предлагал заведомо мёртвую идею.
Дело в том что ключ --inhibit-rpath работает совершенно не так, как мы
предполагали, см.
http://sourceware.org/ml/bug-glibc/2000-01/msg00047.html

В том виде, в котором реализован ключ --inhibit-rpath, это совершенно
бесполезный для решения наших задач инструмент.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Alexey Tourbin]

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

On Thu, Sep 21, 2006 at 08:13:09PM +0400, Dmitry V. Levin wrote:
> On Fri, Sep 15, 2006 at 02:36:22AM +0400, Dmitry V. Levin wrote:
> > On Fri, Sep 15, 2006 at 02:04:16AM +0400, Alexey Tourbin wrote:
> > > On Thu, Sep 14, 2006 at 11:11:44PM +0400, Dmitry V. Levin wrote:
> > > > On Thu, Sep 14, 2006 at 10:08:25PM +0300, Michael Shigorin wrote:
> > > > > On Thu, Sep 14, 2006 at 04:25:12PM +0400, Dmitry V. Levin wrote:
> > > > > > А я добавлю параметр --inhibit-rpath в команду вызова ld.so.
> > > > > 
> > > > > А этот антикомар сильно кусается, по предварительным оценкам? :)
> > > > 
> > > > Если правильно составить --library-path, то не кусается.
> > > > Мне, очевидно, недостаточно просто --inhibit-rpath добавить,
> > > > придётся адаптировать алгоритм вычисления --library-path.
> > > 
> > > Я ещё год назад говорил что --inhibit-rpath придется делать и даже
> > > алгоритм предлагал!
> > 
> > Видел я его, когда делал verify-elf.  Хотелось сделать попроще, как обычно...
> > Собственно говоря, всё необходимое уже есть.
> 
> Оказывается, ты предлагал заведомо мёртвую идею.
> Дело в том что ключ --inhibit-rpath работает совершенно не так, как мы
> предполагали, см.
> http://sourceware.org/ml/bug-glibc/2000-01/msg00047.html
> 
> В том виде, в котором реализован ключ --inhibit-rpath, это совершенно
> бесполезный для решения наших задач инструмент.

Тогда нужно реализовать собственную опцию ld.so --buildroot=$RPM_BUILD_ROOT.
Смысл этой опции в том, что она должна глобально/рекурсивно при обработке
любого rpath прежде всего смотреть в $RPM_BUILD_ROOT/rpath.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] verify-elf

[Alexey Tourbin]

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

On Thu, Sep 21, 2006 at 08:13:09PM +0400, Dmitry V. Levin wrote:
> > > Я ещё год назад говорил что --inhibit-rpath придется делать и даже
> > > алгоритм предлагал!
> > 
> > Видел я его, когда делал verify-elf.  Хотелось сделать попроще, как обычно...
> > Собственно говоря, всё необходимое уже есть.
> 
> Оказывается, ты предлагал заведомо мёртвую идею.
> Дело в том что ключ --inhibit-rpath работает совершенно не так, как мы
> предполагали, см.
> http://sourceware.org/ml/bug-glibc/2000-01/msg00047.html

The requested URL /ml/bug-glibc/2000-01/msg00047.html was not found on this server.

> В том виде, в котором реализован ключ --inhibit-rpath, это совершенно
> бесполезный для решения наших задач инструмент.

А что делает --inhibit-rpath?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]