RE: [boost] Re: shared_object added to files

From: Jeff Garland (jeff_at_[hidden])
Date: 2001-12-17 20:04:34

> As I explained it's not designed for implicitly loaded shared
> libraries, but rather for libraries explicitly loaded at runtime.
> In this case you generally don't want to use C++ functions, but
> rather "C" linkage functions that return pointers to C++ abstract
> base classes (so that all calls are made through the vtable).

Ok, but you can still use the described technique AFAIK for the part of whole
class instead of going one function at a time and dropping down to C linkage.
But I'll take you at your word that you have some real need to prevent the
visibility of individual methods....

> > Order of initialization of file scope statics in shared libraries
> is impossible
> > to control.  The usual wrapper function or init object approaches
> must be
> > applied.
>
> But when you load your library at runtime you at least have control
> over what order the libraries initialise themselves in.  It's then up
> to you to keep all dependent file-scope objects in the same file.

I still don't like this approach b/c it forces file level coupling not otherwise
created by the design.  The wrapper function/init-object approaches always work
and don't force these dependencies.  And again, I'll take you at your word that
you have a really good reason to want to figure out the order of library loading
instead of letting the linker/os just do it for you.

> Unix has no way that I'm aware of for specifying that an entry point
> with external linkage should NOT be exported from a shared object.
> To me this is a mistake, as for instance in a recent project where we

To me this is a feature :-)

> compiled some old code into a shared object that was used purely for
> reading files from an older software version.  The shared object made
> use of older versions of some our library classes, that were not
> compatible with the newer versions.  Under Windows this was no
> problem, but under some flavours of Unix for instance, the destructor
> for the wrong version of the class was getting called and causing
> mayhem.  We had to rename the class to avoid the problem.

Unless I'm misunderstanding (probably), this is the result of an invalid build.
You needed to compile the older classes against the newer versions not the older
versions?  And I take it you had to have 2 versions of the .so file available or
the destructor was inlined otherwise you wouldn't have had this problem....

> I'd still like to find a solution to this, if anyone has one, by the
> way...

You might take a look at this paper for some ideas.  The code is out there
somewhere too....

http://www.usenix.org/publications/library/proceedings/usenix98/full_papers/hjal
mtysson/hjalmtysson_html/hjalmtysson.html

Jeff