Fail when running a binary file

[H.H.]

The binary file was created on HP-UX 11.11 PA-RISC and it is "PA-RISC2.0 shared executable dynamically linked -not stripped". Using this binary on machine when it was created is successful

Once I run this binary on another machine, which is HP-UX Itanium running in HP-UX PA-RISC 11.11 emulation mode, my utility fails and generates the core dump. The problem point is calling pthread_mutexattr_getprotocol() from /lib/libpthread.1

I checked this binary and libpthread library on the build machine:
1. $ file /bin/binary
/bin/binary: PA-RISC2.0 shared executable dynamically linked -not stripped
2. $ file /lib/libpthread.1
/lib/libpthread.1: PA-RISC1.1 shared library -not stripped
3. $ ldd -s /bin/binary


On another machine:
1. $ file /bin/binary
/bin/binary: PA-RISC2.0 shared executable dynamically linked -not stripped
2. $ file /lib/libpthread.1
/lib/libpthread.1: PA-RISC1.1 shared library -not stripped
3. $ ldd -s /bin/binary
ldd: Invalid file type: "/bin/binary". Shared executable or shared library expected.

Why ldd on another machine says "Shared executable or shared library expected" when actually the binary is shared executable as "file" command prints?

thanks

[Steven E. Protter]

Shalom,

Key issue:
ldd: Invalid file type: "/bin/binary". Shared executable or shared library expected.

This program was compiled expecting something to be there that is not.

It needs to be recompiled normally.

SEP

[Dennis Handly]

>3. $ ldd -s /bin/binary
ldd: Invalid file type: "/bin/binary". Shared executable or shared library expected.

This is NOT how to use linker tools on PA binaries on IPF.

The proper way is:
SDKROOT=/usr/ccs/pa ldd -s /bin/binary

Unfortunately there are N other problems that prevent this from working. I don't know if the latest linker patch fixes it. I have mentioned this issue to the linker team.

>Why ldd on another machine says "Shared executable or shared library expected"

Because you are using the IPF ldd, not the PA32 ldd.

>SEP: This program was compiled expecting something to be there that is not.

The problem is with the user or the tool not the program.

>It needs to be recompiled normally.

Yes, recompiling natively will also help.

[H.H.]

> SDKROOT=/usr/ccs/pa ldd -s /bin/binary
In some reasons above command is silent. I simply modified it:
DKROOT=/usr/ccs/pa eval ldd -s /bin/binary

and got the same error:
ldd: Invalid file type: "/bin/binary". Shared executable or shared library expected.

> Because you are using the IPF ldd, not the PA32 ldd
It seems in the above case (with SDKROOT variable) I used PA32 ldd. Correct?

> The problem is with the user or the tool not the program.
Could you please give me a clues to solve this problem?

thanks

[Dennis Handly]

> SDKROOT=/usr/ccs/pa ldd -s /bin/binary
>In some reasons above command is silent.

Those are EXACTLY the N reasons it still doesn't work.

>I simply modified it:
SDKROOT=/usr/ccs/pa eval ldd -s /bin/binary

Why would you use eval?

>It seems in the above case (with SDKROOT variable) I used PA32 ldd. Correct?

Not really, there are N files missing, including the message catalog.

But neither of these will solve your pthread_mutexattr_getprotocol abort.

>Could you please give me a clues to solve this problem?

It is too complicated but tusc is your friend.
You should first see if the latest linker patch fixes it. If not, you should report the problem to the Response Center.

Any reason you can't make do with chatr(1)?

[Dennis Handly]

>ME: Those are EXACTLY the N reasons it still doesn't work.

It looks like I documented the N steps in these threads:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1210111
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1201952

Here is the Aries troubleshooting tips document about SDKROOT:
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=c935c7b31d779110VgnVCM100000275d6e10RCRD