https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Gaius Mulley from comment #11)
> > > > when a module has the same name but a different interface are the
> > > symbols distinct (i.e. mangled differently)?
> > >
> > > no. So, as you say, the ordering of the static link works fine. I
> > > had assumed that dynamic libraries also adhered to a similar ordering.
> > > From what we are observing it seems that all the ctors fire but the
> > > API integrity is preserved due to library ordering? (Or have I
> > > misunderstood dynamic linking?). (Or worse this might be true on
> > > gnu/linux but not on other platforms?).
> >
> > comment #6 seems to indicate possible issues on linux too? (or I
> > misunderstand)
> >
> > To find out what's actually happening will mean digging through the init in
> > the debugger ..
>
> One additional thought, perhaps lazy binding could be responsible; usually
> Darwin will not bind symbols on load, but on first use (speeds up startup).
> However there is an option to force bind-on-load (when I get a chance, will
> try that
That did not resolve the problem.
Actually, to come back to the first conversation we had (about the
cross-linking issue) .. the underlying problem is a layering one.
Assuming that multiple symbols with the same name is not reliable in one
process...
... and we cannot (easily) rename one set....
the simplest solution is:
- define a libm2com.so (containing the modules common to iso and pim.
- make each of libm2iso and libm2pim depend on libm2com.
so we have
if (iso)
libs = m2iso,m2com
else
libs = m2pim,m2com
That means we can get rid of the sledgehammer of "undefined, dynamic_lookup"
and we have no run-time symbols clashes.
We have suggested this before in various discussions .. and I guess it is a
bunch of configure work .. but I am beginning to think it is going to be a lot
less work than trying to solve the unknown issues we have now.
(we can, of course, make the default fscaffold-static as a work-around) but
then scaffold-dynamic is essentially unusable still.)
