Segmentation fault when link to libc.sl

[zfm_1]

I’m compiling on HP-UX itanium B.11.23 U ia64, and my application need to link to libc.sl, when i link to this shared lib the application doesn’t start and result in Segmentation fault, the core file shows
(gdb) bt
#0 0xc000000000036930:1 in strcpy+0x31 () from /usr/lib/hpux64/dld.so
#1 0xc0000000000583e0:0 in _dlopen+0xac0 () from /usr/lib/hpux64/dld.so
#2 0xc000000000394010:0 in __dlopen+0xf0 () from /usr/lib/hpux64/libdl.so.1
#3 0xc000000000393a60:0 in dlopen+0x40 () from /usr/lib/hpux64/libdl.so.1
#4 0xc0000000000583e0:0 in _dlopen+0xac0 () from /usr/lib/hpux64/dld.so

However when I remove the libc.sl form the linking option the application start ok, my compilation option line include
-g0 +objdebug -AA +W67,612,336,2815,2830 +We652,829 +p +DD64 -mt -D_REENTRANT

thanks for help in advance

[Steven Schweda]

> [...] my application need to link to
> libc.sl, [...]

What makes you say that?

> [...] when i link to this shared lib [...]

How, exactly, did you do this? Actual
commands are often more helpful than vague
descriptions.

> However when I remove the libc.sl form the
> linking option the application start ok,

So, it would appear that you _don't_ need to
link (explicitly) with libc.sl. The C
compiler should know where to find the right
libc without any help ("help"?) from you.

> [...] my compilation option line include
> [...]

The whole command would be better than an
excerpt.

Is there any chance that you're mixing 32-bit
code with 64-bit code?

[Dennis Handly · Accepted solution]

>I'm compiling on HP-UX Integrity B.11.23 and my application need to link to libc.sl,

(That's libc.so on Integrity.)

You should never ever link with -lc. This is done automatically for you by the driver. Especially don't add it to shlibs. And you especially don't want that -lc before -lpthread.

>when I remove the libc.so from the linking option the application start ok

That's because you have libc and some other lib that is calling dlopen in a static initializer and libc is linked in the wrong order. It must be last.

You can also install PHSS_38134 to solve the problem:
QXCR1000771352: accessing TLS data in shared library initializer aborts application

>Steven: > my application need to link to libc.sl
>What makes you say that?

Every application needs libc. But on Integrity, they should let the driver add it.

>Actual commands are often more helpful than vague descriptions.

Yes, would need to see the dependent shlib graph. But since I've seen the problem over and over and told them how to fix QXCR1000771352, it isn't needed.

>The C driver should know where to find the right libc

Exactly.

>Is there any chance that you're mixing 32-bit code with 64-bit code?

Nothing so simple. :-)

[zfm_1]

Actually I am porting an application form SUN to HP, that was linked to libsocket.so on SUN, and as I did not found libsocket.so on HP, I searched the HP forum and I found that libc.sl should replace libsocket.so on HP, that is why I need to link to it.
However I understand from Dennis and Steven that I have to let the driver add it.
Thanks for your help

[Dennis Handly]

>I understand from Dennis and Steven that I have to let the driver add it.

I forgot to mention, we now remind you not to do that:
aCC: warning 983: The -lc library specified on the command line is also added automatically by the compiler driver.

[zfm_1]

thanks very much for your help