This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]