Re: `exec shield' test in configure too strict?

[Jan D.]

Stefan wrote:

> > That would involve detetcting that the core dump from temacs is due
> > to exactly this problem.  I think that is hard to do.  Or do you suggest
> > that any temacs core dump should give a message about etc/PROBLEMS?
>
>
> We can output the message even if the build succeeds.

You lost me, what message?  The one in configure or the hypotetical new one 
after temacs dumps core?

> I.e. just transform the current error into a warning.

I've done that.


> > > Trying to predict whether it's going to work or not doesn't seem to make
> > > much sense here since it doesn't allow us to resolve any problem we can't
> > > solve otherwise.
>
>
> > It is so much better to get this message at configure time rather than
> > very late in the build stage.
>
>
> I don't see the big improvement here.  We're talking about a case where
> Emacs's build fails.  It should be rare and we want to know about those
> cases so we can fix them, so early or late detection is really not a big
> deal so long as the warning is clear and visible enough.

You maybe never built Emacs on a machine where the build takes 20 minutes :-)

If exec-shield and/or its effects, like randomized heap start, becomes more 
widespread this will be a very common case.  I would not be surprised if 
something like it will be incorporated in to the Linux kernel proper, and not 
just for Fedora as it is now (and some unofficial Debian patches seems to 
exist).  The undump part is not so hard to fix, but it also requires a redesign 
(more or less) of malloc, and that is harder.  Specifically malloc must be able 
to handle a heap that is not contiguous.

        Jan D.