shl_load() error

[Susan Markley]

Hi,
I posted this message a couple hours ago and it never showed up on the forum so I might have made an error. If you are seeing this for the second time, my apologies.

I built a module for perl using HP's f77. It builds fine but gives this error when I try to access it:
/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /usr/lib/libcl.2
I spoke to the developers of the module and they have never tried it with HP. I would really like to get this built but I am unclear as to where the error is. Does anyone have any suggestions?

Thank you for your help,
Susan

[Marcel Eken_2 · Accepted solution]

Hi Susan,

I am not a programmer, but i have found the following in our documentation which might solve your problem:

Thread local storage (TLS) is a section of contiguous memory that is created
for each thread running in a program, this memory is only addressable by a
specific thread.

TLS is created for the first thread in a process differently between a 32 and
a 64 bit process. For a 32 bit process the dynamic loader initialises TLS, and
for a 64 bit process it is initialised by libc. Because TLS in a 32 and a 64
bit process is initialised before the user code in the program starts to
execute its size has to be known.

TLS is fixed in size because of this, its size is the sum of the sizes of all
the variables defined in TLS. The man page for dld.sl(5) contains more
information on how TLS is calculated.

The C/C++ __thread storage modifier is used to define a variable as being in
TLS. For example:

__thread int my_errno;

Would define the variable my_errno as being kept in TLS, this means that
each thread in the program (if it is multi-threaded) will see a different
my_errno in each thread. The main reason TLS is used in programs is that it
has very little impact on the structure of existing source code, and it is
much easier to code for than thread specific data keys created via
pthread_key_create(3T).

The main restriction with TLS is that if you place TLS inside a shared
library you cannot use shl_load or dlopen to load the library dynamically.
From the diagnostics section of the shl_load(3) man page:

If a library cannot be loaded, shl_load() returns NULL and sets errno
to indicate the error. This includes trying to shl_load() a library
containing thread local storage. All other functions return -1 on
error and set errno.

The other restriction is that if a library containing TLS is listed as a
dependancy of library that a program tries to shl_load it will fail to load
unless the library with TLS has been linked against the program. The man page
for shl_load(3) in the warnings section says:

Use caution when building shared libraries with external library
dependencies. Any library that contains Thread Local Storage (TLS)
should not be used as a dependency. If a dependent library contains
TLS, and it is not loaded during program startup (that is, not linked
against the executable), the dynamic loader fails to perform the
operation.

The workaround to not being able to shl_load a shared library containing TLS
can be seen in the following example:

#include
#include
#include

main()
{
shl_load("/usr/lib/libcl.2", BIND_DEFERRED, NULL);
printf("errno is %in", errno);
}

$ cc testing.c -o testing
$ ./testing
/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local
Storage: /usr/lib/libcl.2
/usr/lib/dld.sl: Exec format error
errno is 8
$ cc testing.c -o testing -lcl
$ ./testing
errno is 0

The program does not produce an error when libcl.sl (-lcl) has been linked
directly against the program. This method does not require any changes to
the code only to the compilation flags (or makefile) as shl_load will ignore
any request to load a library that is already loaded.

[Guy Mengel]

I have had the same exact problem using the Oracle DBI drivers for perl.
Simply add the pthread and cl libraries when building perl. Note:
You MUST rebuild perl to get rid of this issue, if you are using a binary
then you must get the sources and recompile adding the libraries
-lpthread -lcl when asked for the library information. Note2: This is NOT building
a "threaded" perl either, unless you need threads you should be answering "no" to
building a threaded perl.

Hope this helps
Guy

[Susan Markley]

I just rebuild perl w/ -lcl and -lthread then PDL and it passed all the tests.

Whahoo!

Thanks,
Susan

PS - do you know why -lthread is necessary, not just -lcl?