Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk