RE: [boost] Re: shared_object added to files

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-12-17 22:17:03

> I'm not sure what you mean here.  In this case I'm not talking about
> the need to prevent visibility, just that you don't want to access
> C++ functions directly because of name-mangling.  Using a single C
> linkage function and then using virtual functions solves this nicely.

Clearly we aren't on the same track here and I don't really think it is
important to get back on....

> How can the linker/OS figure out the order of explicit library
> loading?

Because when an unresolved symbol is referenced the library is loaded.  The
order is discovered dynamically at run time...

>I'm not aware of any OS that lets you say "now load up all
> these libraries in any order you like".  But I wouldn't generally

If you do a dlopen on a shared library that would not automatically load and
then call a function that depends on another shared library, which was known to
the linker, the os can load the second library automatically.

> > To me this is a feature :-)
>
> Hmm...selling a lack of a something as a feature...you should be in
> marketing :o)

Lack of a bad thing (programmer hassle in this case) is easy to sell as a
feature :-)

> No, we had two regular (non-shared) libraries, both containing
> ...
> for the one module to "accidentally" make calls into the other,
> presumably because there is a global symbol table that gets patched
> when you do a dlopen.

Thx for explaining -- if everything had been in shared libraries this wouldn't
have happened.  So the Unix dynamic library export mechanism is not the source
of your trouble....

> All of which is getting very off-topic, but oh well... :o)

Sorry, my fault.  I did take a look at your files and this is useful
functionality for those that want a cross-platform abstraction for dynamic
library file loading.  I think a name like dynamic_library_loader would be more
descriptive than shared_object...

Jeff