shl_load() and TLS (32-bit)

[Clif Day]

We're using shl_load() and have been successful until now:

/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


Sure enough, man shl_load says it does not
work with thread local storage. So we tried
dlopen(), but apparently it's not supported
on 32 bits. We have no control over the
library that contains TLS. Is there a workaround? Will this be supported in the future? Thanks.

Clif

[Mike Stroyan · Accepted solution]

The only options are to link the a.out with those
libraries that use TLS or to remove those library
dependencies from your shared library. There
won't be any way to shl_load TLS in the near future.

There aren't many system provided shared libraries
that use TLS. The only ones that you may want
to link into an a.out are libcl.sl and libpthread.sl. Of
course, if you link in libpthread.sl then your code
should be prepared to run in a threaded environment.

The a.out does not necessarily need to be directly
linked with the shared library containing TLS. If
the a.out is linked with "libmiddle.sl" and you can
add libcl.sl to the link line for libmiddle.sl, then it
will cause libcl.sl to be loaded at startup time before
your call to shl_load some library that needs libcl.sl.
If you are a little devious you can use "chatr +s enable"
and SHLIB_PATH to make an a.out load your private
version of libc.2 which pulls in both /usr/lib/libc.2
and /usr/lib/libcl.2.