Re: shared_object added to files

From: mfdylan (dylan_at_[hidden])
Date: 2001-12-17 20:29:36

--- In boost_at_y..., "Jeff Garland" <jeff_at_c...> wrote:
> 
> 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....

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.

> >
> > 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.
> 
How can the linker/OS figure out the order of explicit library 
loading?  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 
make use of a technique of loading libraries in a particular order in 
order to get file-scope object initialisation to happen in a 
particular order.  I have however used a scheme whereby "lower level" 
shared libaries are all loaded and manually initialised first (by 
this I mean look up a function symbol called e.g. "initialize" then 
call it), then gone on to load higher level shared libraries that 
rely on the lower level libraries having been already initialised.

> > 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 :-)

Hmm...selling a lack of a something as a feature...you should be in 
marketing :o)  

> 
> > 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....
> 

No, we had two regular (non-shared) libraries, both containing 
classes with the same names but different, incompatible versions.
If you linked them against separate executables and had one call the 
other, there would be never any chance of mismatched calls.
But under Unix, if you link one version of the library against your 
executable and another version of the library with a shared object 
that you load explicitly at runtime (which we do), then it's possible 
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.

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

Dylan