This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
----- Original Message -----
From: "Martin v. Loewis" <martin@v.loewis.de>
> > > In this specific case, any Python extension would be a "program"
> > > (though free-standing, since it has a different entry point).
> >
> > So, what happens when multiple "programs" link to the same shared
library?
>
> Each object in the shared library should still exist only once.
Good, then we agree!
> That
> means that some objects can change their state "spontaneously", from
> the view of a "program",
Hmm, what does that mean? In my proposal there is no "state change" AFAICT.
> but apart from that, ODR and everything is
> preserved.
>
> > > You probably cannot convince compiler vendors to follow
> > > what you consider a reasonable semantics unless you specify what that
> > > semantics is, and contribute code or money to change their
> > > implementations.
> >
> > There's one other way: the pressure of standards. However, that takes a
> > long time, and seldom works without a reference implementation...
>
> I think it should never work without a reference implementation:
I agree. However, in practice things have sometimes gone differently.
> > I think you misunderstand me. What you wrote doesn't contradict item 4:
> > since the graph is bidirectional, if A is reachable from B then B is
> > reachable from A. I don't care /which/ definition is chosen - they're
> > required to be the same anyway - I only care that they're shared.
>
> I see. If that is what Solaris does, it sounds reasonable indeed. If
> Solaris does something else, I'd like to see that approach confronted
> with your specification.
Sorry, could you explain? What would it mean to confront the Solaris
approach with my specification?
-Dave