Operating System - HP-UX
1833891 Members
2386 Online
110063 Solutions
New Discussion

Re : Can Someone pls help

 
Vincent_5
Super Advisor

Re : Can Someone pls help

I have a problem after upgrading hp-ux os version 10.20 to 11:00 and than I started installing Oracle & other third party software and I'm encountering the following error in library loading and could not startup the Named server meant for the
Accounting application.

Error Message
pcoda /usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /lib/libc.sl /usr/lib/dld.sl: Exec format error initSyscalls: cannot load C library from "/lib/libc.sl".


Please help???

Regards
Vincent

nothing is better than to know more
3 REPLIES 3
Umapathy S
Honored Contributor

Re: Re : Can Someone pls help

Check this thread.
https://community.hpe.com/t5/General/Upgrading-hp-ux-10-20-to-11-00/td-p/2582311

HTH
Umapathy

Arise Awake and Stop NOT till the goal is Reached!
Steve Steel
Honored Contributor

Re: Re : Can Someone pls help

Hi

You can use the LD_PRELOAD environment variable to load a shared library
that contains thread-local storage to avoid the following error when loading
the library dynamically:

/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local
Storage: /usr/lib/libpthread.1
The load order and symbol resolution order may be different in a PA32
program than in the same PA64 program because the dynamic loader uses
depth-first search order in PA32 mode and breadth-first search order in PA64
mode.
The dynamic loader uses the LD_PRELOAD environment variable even if you use
the +noenvvar in the link line. This insures that LD_PRELOAD is enabled even
in a +compat link. The LD_PRELOAD variable is always enabled except for
setuid and setgid programs.

Note: Using LD_PRELOAD can cause a core dump when used with applications
which mix shared and archived libraries, especially when both the shared
library and the application are built with aC++ or use libc.

You can specify multiple libraries as part of the LD_PRELOAD environment
variable. Separate the libraries by spaces or colons as in LD_LIBRARY_PATH.
(Multi-byte support is not provided as part of parsing the LD_PRELOAD
library list). You can specify LD_PRELOAD libraries with absolute paths or
relative paths. The LD_PRELOAD libraries can also consist of just the
library names, in which case the dynamic loader uses the directory path list
in the environment variables LD_LIBRARY_PATH and/or SHLIB_PATH or the
embedded path list (if enabled) to search for the libraries.

The dynamic loader does not issue an error or warning message if it cannot
find a library specified by LD_PRELOAD. However, if it does not find a
dependent of the LD_PRELOAD libraries, the dynamic loader issues the same
error message as if the LD_PRELOAD library is specified in the link line.
==============================================


Improving Shared Library Performance
This section describes methods you can use to improve the run-time
performance of shared libraries. If, after using the methods described here,
you are still not satisfied with the performance of your program with shared
libraries, try linking with archive libraries instead to see if it improves
performance. In general, though, archive libraries will not provide great
performance improvements over shared libraries.

Loading Shared Libraries with the LD_PRELOAD Environment Variable
NOTE: The LD_PRELOAD feature is disabled for seteuid/setegid programs, such
as passwd. See ld(1) for more details. This feature is not available to
fully-bound static executables.
The LD_PRELOAD environment variable allows you to load additional shared
libraries at program startup. LD_PRELOAD provides a colon- separated or
space-separated list of shared libraries that the dynamic loader can
interpret. The dynamic loader, dld.sl, loads the specified shared libraries
as if the program had been linked explicitly with the shared libraries in
LD_PRELOAD before any other dependents of the program.

At startup time, the dynamic loader implicitly loads one or more libraries,
if found, specified in the LD_PRELOAD environment. It uses the same load
order and symbol resolution order as if the library had been explicitly
linked as the first library in the link line when building the executable.
For example, given an executable built with the following link line:


Steve Steel
If you want truly to understand something, try to change it. (Kurt Lewin)
Indira Aramandla
Honored Contributor

Re: Re : Can Someone pls help

Hi,

There is a LD_PRELOAD library loading mechanism available for HP-UX 11.X in a patched /usr/lib/dld.sl.
If you apply patch PHSS_23440 (PHSS_23441 for 11i), then you can set the LD_PRELOAD environment variable to make a program pull in X.sl or any other shared library.
E.g. export LD_PRELOAD=/usr/lib/libpthread.sl:/usr/lib/libcl.sl
That is done at startup as if the program were linked with the library. It is described in the patched "man dld.sl".

Reason:- The error Can't shl_load() a library containing Thread Local Storage: /lib/libc.sl /usr/lib/dld.sl: may be due to ?????????.

You are attempting to dynamically load the Oracle shared library (libclntsh.sl) on HP-UX and are receiving the following error: You may be attempting to load the library yourself via shl_load or dlopen OR you may be using some 3rd party product which does this OR you may be using another Oracle product which does this (e.g. external procedures or the JDBC OCI driver).

Some third party products which are known to have problems with this error include IBM MQSeries and Perl. However, it could occur for ANY product that loads our shared library dynamically at runtime.


Note : - HP-UX has a restriction which prohibits dynamically loading any shared library which uses thread local storage. Libraries which use thread local storage must be loaded at application startup.

Solution
If you have the ability to relink the executable (e.g. this is your own code or some Oracle product for which a makefile has been provided), determine which of the above libraries apply to your situation and relink the executable, adding those libraries to the link line. To verify that the libraries will be loaded at startup, use 'chatr' (which shows runtime dependencies) against the resulting executable.

If you don't have the ability to relink the executable (e.g. this is occurring with an Oracle product for which you have no makefile or 3rd party product), you will need to contact the vendor for the product in question. They may be able to provide a version of the product which has been linked with the appropriate libraries.

I Hope this helps

Never give up, Keep Trying