Problem resolving problem with pwrite64() unresolved symbol

[Pierre Lemay_1]

Hello everyone,

I am trying to use an application that generate an error saying that dld.sl can't resolve the pwrite64() symbol on my HP 11 machine. I have been told that the patch PHKL_20349 would resolved this.

I have downloaded the recommand patch from HP which include patch PHKL_25475 and a bunch of derived patches as suggested by HP web site. Once downloaded, I have executed the create_depot_hp-ux_11 which created the depot and run swinstall to install the complete bundle from that new depot location.

The patches have been installed, kernel recompiled, machine reboot,etc., but once done I still have the same problem with my application.

Then I have done the same thing with patch PHKL_28202 since this is the "most recent" patch while PHKL_25475 what the "recommended" one.

I have installed that patch the same way and once the machine rebooted I could see that I still have the same problem...

Doing a chatr on the binary that is causing me problem I can see this:

shared executable
shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined
shared library list:
dynamic /lib/libpthread.1
dynamic /lib/libm.2
dynamic /lib/librt.2
dynamic /lib/libcl.2
dynamic /lib/libc.2
shared library binding:
deferred

Which library should normally contains the pwrite64() function and how to verify if a library contains it?

Could it be possible that another libc.sl got updated by the patch installation?

Any suggestion/comments on howI can resolve this pwrite64() symbol will be much appreciated.

thanks,

- Pierre

[Dietmar Konermann · Accepted solution]

Pierre,

installing the kernel patch would be the correct action for unresolved symbols during kernel build.

You get the error during while exectuing an user process... so you need to patch the required shared library. In the case of pwrite64() this would be the libc patch, for 11.00 PHCO_27731.

Best regards...
Dietmar.

[Steven E. Protter]

Unresolved symbols during a kernel build means the patches you installed did not go in properly.

This could require you to go to your backup system file in the /stand directory, rebuild the kernel to check if it builds and then reinstall the patch depot you created on itrc.

I don't see an unresolved symbols warning in your message but the first response indicates it, and I want you to know that you can not solve your problem unless you can sucessfully generate a new kernel.


P

[Dietmar Konermann]

Steven, I don't believe Pierre has a kernel build problem at all. :-)

He has a binary reqesting the pwrite64() function. And this is delivered by libc.2:

# nm /usr/lib/libc.2 |grep "^pwrite64.*code"
pwrite64 | 1105240|extern|code |$CODE$

[Pierre Lemay_1]

Dietmar,

I did what you have suggested and it solved my problem. thank you so much, I don't know how I would have been able to figure this out without your help.

Another question (may I?), if I do the following command, I receive this output:

calahu43# nm -a libc.sl | grep pwrite64
__pwrite64 | 1033152|extern|code |$CODE$
pwrite64 | 1033152|extern|code |$CODE$
pwrite64 | 1033152|extern|entry |


I haven't done the command BEFORE applying the patch but if I would have done so, what would be the expected output? Will the nm|grep returns nothing?

The reason I am asking this is because I am not sure of the "extern" meaning. Those it means the pwrite64 is being used and requires to be defined externaly, or does it mean that it is defined in this library and available external.

I will have to install my program on several machines and I need to find a way to know if a patch is required or not. I am wandering if the "nm |grep pwrite64" is a good way..

thanks,

- Pierre

[Dietmar Konermann]

Hi, Pierre!

Indeed, you can look with nm(1) at a binary's name list. If you see "extern" and "code" then it contains code, that is externally visible. "undef" would mean that this binary reqeusts the symbol to be resolved from somewhere else.

Concerning the pwrite/pwrite64 syscalls, they were added to 11.00 with patches. You need libc patch PHCO_20765 or newer. The kernel patch introducing full support for those syscalls is PHKL_20349.

Best regards...
Dietmar.