shl_load and dependent library unresolved symbols

[Chris J_1]

I am trying to build a shared library which gets loaded into Apache using shl_load with the BIND_IMMEDIATE flag.

The shared library I am building depends on a third party shared library (from Oracle) which apparently has some problems with unresolved symbols.

If I modify Apache to use the BIND_DEFERRED flag, my shared library is able to load and run without issue (even the routines that use the third party library work). I would prefer, however, to leave the Apache build unmodified unless it is absolutely necessary.

Is there a way I can build my shared library so that when loaded using shl_load and BIND_IMMEDIATE, once the symbols in my shared library have been resolved (and the symbols I reference) the ones in the dependent library that can't be resolved are ignored?

I've attached some example files that represent the problem and mimic the relationship between Apache, my library and the Oracle library.

I am working with Oracle on this but they have suggested that it may have more to do with the way my shared library is built than a problem in their library. I've read through the linker and libraries user's guide but I didn't spot any build options that look like they would solve my problem.

Thanks,
Chris

[Dennis Handly · Accepted solution]

I'm wondering why Apache is using BIND_IMMEDIATE? Are they trying to insure that it won't abort later?

>Is there a way I can build my shared library ...the ones in the dependent library that can't be resolved are ignored?

No. All you can do is add stubs into your lib for those Oracle unsats.

What are those unsats that occur? If they come from Oracle, I don't see how they are a problem with your lib??? Did they explain that?

[Chris J_1]

Dennis,

I assume Apache is trying to prevent a later abort as well as prevent delays in resolving the symbol once the child process starts serving requests (although I would imagine that the symbol resolution would be a fairly small overhead compared to the other processing).

After working with Oracle, we discovered that the shared library I was building was being linked to a shared library that wasn't needed. When using chatr on my shared library, the library with the unresolved symbols showed up in the dependency list.

We didn't solve why the symbols weren't resolved in their library but removing it from the link line solved the issue. I did learn that the unnecessary library was for use with C++ while our library is in C. My assumption is that the missing symbols reference items in an unloaded C++ library (a quick scan of docs makes me think they might be found here: /usr/lib/libC.sl). I haven't had the pleasure of using C++ to this point I could not say for sure.

Thanks for the input and confirming that there is nothing I can do in my library to change the binding behavior when shl_load is used.

Chris

[Chris J_1]

See previous message for resolution information.

[Dennis Handly]

>(a quick scan of docs makes me think they might be found here: /usr/lib/libC.sl). I haven't had the pleasure of using C++ to this point I could not say for sure.

(libC.sl is only for obsolete cfront, don't you dare use it.)

If you want the info for aC++, see:
http://www.docs.hp.com/en/7762/5991-4874/distributing.htm#linking

This will list the aC++ libs that you could add to resolve those symbols. (If you listed the unsat symbols it would have been obvious to me.) But your solution of removing unneeded libs is better.