Problem z post_check_so

[Marek Marczykowski]

On 04/27/11 14:00, Marek Marczykowski wrote:
> On 04/27/11 13:34, Artur Frysiak wrote:
>> On Wed, Apr 27, 2011 at 13:07, Marek Marczykowski
>> <marmarek w staszic.waw.pl> wrote:
>>> Hej,
>>>
>>> Problem wygląda tak:
>>>
>>> + __spec_install_post_chrpath
>>> Remove RPATH from 37 executable binaries and shared object files.
>>> remove-rpath: /usr/lib64 in
>>> /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0
>>> + __spec_install_post_check_so
>>> Searching for shared objects with unresolved symbols...
>>> Unresolved symbols found in:
>>> /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0
>>>        oh_evt_queue_push
>>>        oh_event_free
>>> (...)
>>>
>>> A przyczyna jest tu:
>>> ldd
>>> /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0
>>>        linux-vdso.so.1 =>  (0x00007fff58bf7000)
>>>        libopenhpiutils.so.2 =>
>>> /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/libopenhpiutils.so.2
>>> (0x00007fcfd6d4d000)
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> (...)
>>>
>>> (tu oczywiście ustawiłem LD_LIBRARY_PATH)
>>>
>>> To jest bug w macros.build, czy ja coś źle robię?
>>
>> Marek, zrób "ldd -r" na tym libipmi
>>
>> Pokaż też:
>> objdump -p  /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0|grep
>> NEEDED
> 
> $ objdump -p
> /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0|grep
> NEEDED
>   NEEDED               libopenhpiutils.so.2
>   NEEDED               libOpenIPMIposix.so.0
>   NEEDED               libOpenIPMI.so.0
>   NEEDED               libglib-2.0.so.0
>   NEEDED               libpthread.so.0
>   NEEDED               libc.so.6
> $
> LD_LIBRARY_PATH=/home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/
> ldd -r
> /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0
>         linux-vdso.so.1 =>  (0x00007fff84dff000)
>         libopenhpiutils.so.2 =>
> /home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/libopenhpiutils.so.2
> (0x00007f16f031a000)
>         libOpenIPMIposix.so.0 => /usr/lib64/libOpenIPMIposix.so.0
> (0x00007f16f010b000)
>         libOpenIPMI.so.0 => /usr/lib64/libOpenIPMI.so.0 (0x00007f16efe02000)
>         libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f16efb13000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f16ef8f5000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007f16ef567000)
>         libgdbm.so.3 => /usr/lib64/libgdbm.so.3 (0x00007f16ef362000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007f16ef0de000)
>         libOpenIPMIutils.so.0 => /usr/lib64/libOpenIPMIutils.so.0
> (0x00007f16eeed6000)
>         libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f16eeb24000)
>         libpcre.so.0 => /lib64/libpcre.so.0 (0x00007f16ee8e7000)
>         librt.so.1 => /lib64/librt.so.1 (0x00007f16ee6df000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f16f0773000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007f16ee4db000)
> undefined symbol: oh_evt_queue_push
> (/home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0)
> undefined symbol: oh_event_free
> (/home/users/marmarek/tmp/openhpi-2.16.0-root-marmarek/usr/lib64/openhpi/libipmi.so.2.16.0)
> 
> Czyli faktycznie coś jest nie tak...

Już widzę. Te symbole są dostarczane przez binarkę openhpid...
[marmarek w arachnid openhpi-2.16.0]$ objdump -T openhpid/.libs/openhpid
|grep oh_evt_queue_push
0000000000444cb0 g    DF .text  0000000000000008  Base
oh_evt_queue_push

Jest jakiś elegancki sposób na obejście tego, czy trzeba wyłączyć
sprawdzanie symboli na tych bibliotekach? Bo to nie tylko libipmi, tylko
praktycznie wszystkie pluginy do openhpi.

-- 
Pozdrawiam / Best Regards,
Marek Marczykowski          |   gg:2873965      | RLU #390519
marmarek at staszic waw pl  | xmpp:marmarek at staszic waw pl

-------------- nast�pna cz��� ---------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5890 bytes
Desc: S/MIME Cryptographic Signature
URL: </mailman/pipermail/pld-devel-pl/attachments/20110427/cbe6e2ea/attachment.p7s>