[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

[iains at gcc dot gnu.org]

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