Executable fails with /usr/lib/dld.sl: Unresolved symbol error

[Arjan van Stiphout_1]

LS,

I have to install our application on a HP-UX 11.00 box with the June 2000 patch installed.

Our application makes uses of Pro Cobol and Oracle 8.1.6.

After installation of the OS, the HP-UX patch, and Oracle and ProCobol, our application runs without any problems.

However, after installing Oracle 8.1.7 (in a separate Oracle_Home) our application does not work any more.

The following error pops up upon running:

$crtablesm
/usr/lib/dld.sl: Unresolved symbol: nameTypeHash (storage) from crtablesm
Abort(coredump)

When I issue a chatr against the executable (crtablesm) I find:

/opt/app/marc/product/8.2.8.0/bin/crtablesm:
shared executable
shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined
shared library list:
dynamic /linux-fs1/oracle/product/8.1.6/lib/libclntsh.sl.8.0
dynamic /lib/librt.2
dynamic /lib/libpthread.1
dynamic /lib/libnss_dns.1
dynamic /lib/libdld.2
dynamic /lib/libm.2
dynamic /lib/libc.2
dynamic /lib/libcl.2
dynamic /opt/cobol/cobdir/coblib/liboops.1
dynamic /opt/cobol/cobdir/coblib/libmfo.1
dynamic /opt/cobol/cobdir/coblib/libmbcs.1
dynamic /opt/cobol/cobdir/coblib/libfhutil.1
dynamic /opt/cobol/cobdir/coblib/libcobol.1
dynamic /opt/cobol/cobdir/coblib/libcrtn.1
dynamic /opt/cobol/cobdir/coblib/libsupp.1
dynamic /opt/cobol/cobdir/coblib/libscreen.1
dynamic /opt/cobol/cobdir/coblib/libosx.1
dynamic /opt/cobol/cobdir/coblib/libisstubs.1
shared library binding:
deferred
global hash table disabled
plabel caching disabled
shared vtable support disabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
data page size: D (default)
instruction page size: D (default)

All these shared libraries exist and are to be found in the SHLIB_PATH

I conducted a nm |grep nameTypeHash against all the shared libraries, but without any result.

Even when the SHLIB_PATH is NOT set, the error mentioned above pops up.

Does anybody know which shared library contains nameTypeHash?

I've already reinstalled and recompiled Oracle, without any result.

All the Cobol libraries are untouched; I really have the feeling my Oracle 8.1.7 installation touched the standard shared libraries somehow.

Any help would be greatly appreciated!

Thanks to you all!

Arjan

[Arjan van Stiphout_1]

Sorry.. A small update:

I found out that nameTypeHash exists in crtablesm itself:

$nm $MARC_HOME/bin/crtablesm | grep -i type
Name Value Scope Type Subspace
$in_type |1073766155|static|data |$DATA$
$nam_type |1073766569|static|data |$DATA$
$nameTypeHash |1073766556|static|data |$DATA$
$out_key_type |1073766780|static|data |$DATA$
$out_type |1073766802|static|data |$DATA$
$registration_ret_type|1073767191|static|data |$DATA$
$request_types |1073767213|static|data |$DATA$
db_trantype | 120840|extern|entry |
db_trantype | 120864|extern|code |$CODE$
in_type | |undef |data |
nam_type | |undef |data |
nameTypeHash | |undef |data |
out_key_type | |undef |data |
out_type | |undef |data |
registration_ret_type| |undef |data |
request_types | |undef |data |

Now the questions is, why does /usr/lib/dld.sl still claim it is not there?

Many thanks in advance!

[Rgomes]

Hi,

I guess you need to install libc cumulative patch.

regards,
Richard

[Arjan van Stiphout_1]

Thanks for your reply.

I will install the patch, but can you explain why this executable worked before and not anymore after the Oracle 8.1.7 installation?

Does this installation somehow affect the shared libraries on the box?

Again, thanks for your reply.

Arjan

[H.Merijn Brand (procura]

It could be that it worked, because the symbol was never used before the change. Most objects act very dynamically, and until the object that references the unknown symbol is actually called, it is not important for it to exist at all.

For example, 'wget' can be used quite well for both http: and ftp: URL's, even with no openssl installed, but when you call wget with https: URL's, and opensll cannot be found, it'll crash with a similar note

Check the program's dependencies with

# ldd crtablesm

and, as you already did

# chatr crtablesm

Now check if all the mentioned libs exist and are of the correct type (32 and 64bit libs don't mix)

If one is missing, but could be found somewhere else in $SHLIB_PATH, make sure that all the objects that could refer to it hav $SHLIB_PATH search enabled with chatr. This might even mean that you have to change properties on an existing Oracle library!

Enjoy, Have FUN! H.Merijn

[Arjan van Stiphout_1]

As asked, I've checked all the shared libraries; please see the output of ldd crtablesm:

ldd $MARC_HOME/bin/crtablesm
/opt/cobol/cobdir/coblib/libisstubs.1 => /opt/app/cobol/cobdir/coblib/libisstubs.1
/opt/cobol/cobdir/coblib/libosx.1 => /opt/app/cobol/cobdir/coblib/libosx.1
/opt/cobol/cobdir/coblib/libscreen.1 => /opt/app/cobol/cobdir/coblib/libscreen.1
/opt/cobol/cobdir/coblib/libsupp.1 => /opt/app/cobol/cobdir/coblib/libsupp.1
/opt/cobol/cobdir/coblib/libcrtn.1 => /opt/app/cobol/cobdir/coblib/libcrtn.1
/opt/cobol/cobdir/coblib/libcobol.1 => /opt/app/cobol/cobdir/coblib/libcobol.1
/opt/cobol/cobdir/coblib/libfhutil.1 => /opt/app/cobol/cobdir/coblib/libfhutil.1
/opt/cobol/cobdir/coblib/libmbcs.1 => /opt/app/cobol/cobdir/coblib/libmbcs.1
/opt/cobol/cobdir/coblib/libmfo.1 => /opt/app/cobol/cobdir/coblib/libmfo.1
/opt/cobol/cobdir/coblib/liboops.1 => /opt/app/cobol/cobdir/coblib/liboops.1
/lib/libcl.2 => /lib/libcl.2
/usr/lib/libisamstub.1 => /usr/lib/libisamstub.1
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libdld.2 => /usr/lib/libdld.2
/lib/libc.2 => /lib/libc.2
/lib/libm.2 => /lib/libm.2
/lib/libdld.2 => /lib/libdld.2
/lib/libnss_dns.1 => /lib/libnss_dns.1
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libc.2 => /usr/lib/libc.2
/lib/libpthread.1 => /lib/libpthread.1
/lib/librt.2 => /lib/librt.2
/linux-fs1/oracle/product/8.1.6/lib/libclntsh.sl.8.0 => /opt/app/oracle/product/8.1.6/lib/libclntsh.sl.8.0
/usr/lib/libcl.2 => /usr/lib/libcl.2
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libm.2 => /usr/lib/libm.2
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libnss_dns.1 => /usr/lib/libnss_dns.1
/usr/lib/libpthread.1 => /usr/lib/libpthread.1
/usr/lib/librt.2 => /usr/lib/librt.2
/opt/app/oracle/product/8.1.6/lib/libwtc8.sl => /opt/app/oracle/product/8.1.6/lib/libwtc8.sl
/usr/lib/libc.2 => /usr/lib/libc.2
/opt/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl => /
opt/app/oracle/product/8.1.6/JRE/lib/PA_RISC/native_threads/libjava.sl
/usr/lib/libcl.2 => /usr/lib/libcl.2
/usr/lib/libm.2 => /usr/lib/libm.2

I've checked all the libraries and found that they are all there. I do not know how to check if they are 64 or 32 bit, but since I only installed 32 bit software, they must be 32 bit. I am more than happy to check.

In my first post I did not mention that the application actually crashes with a coredump.

I used wdb to find out why it crashes, but since it is a compiled executable, I could only come up with the "assembly line" at which it crashes; however that was not very useful.

This is the second time I run into this problem; last time I was able to fix it by reinstalling the box from scratch, but, of course, that doesn't really tell me the root cause of the problem.

I am a bit weary to install the cumulative patch for libc since that caused me to have the exact same problem a couple of months ago.

Any suggestions would be appreciated.
Many thanks in advance.

Have a good weekend for now!

Arjan