GNU bug report logs - #12242
Emacs 24.2 RC1 build fails on OpenBSD

Previous Next

Full log

View this message in rfc822 format

From: Chong Yidong <cyd <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12242 <at> debbugs.gnu.org, jca <at> wxcvbn.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, Kenichi Handa <handa <at> m17n.org>
Subject: bug#12242: Emacs 24.2 RC1 build fails on OpenBSD
Date: Thu, 23 Aug 2012 22:24:19 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Unfortunately, using r_alloc_freeze/r_alloc_thaw doesn't seem to be
> workable in practice, either.  I tried to use it, and the best patch I
> could come up with (got me through several bootstraps with different
> compiler switches) is below.  It is (a) butt-ugly, and (b) very
> fragile, for the reasons I explain below.
>
> So it sounds like the only practical way out of this mess is to step
> back one notch and talk about bug #11519, which was the cause for
> inhibiting relocations while maybe_unify_char is in progress.  At the
> time, Handa-san promised to work on removing unify_char, but I guess
> that job is not yet done, since it isn't even on the trunk.  Ken'ichi,
> what would it take to do this now?

I don't think it is feasible to rework maybe_unify_char, and test that
fix, and still have a reasonably timely 24.2 release.

Let us consider outright reversion of 108048.  What would be the effect?
Given a choice between a bug (Bug#11519) which is also in 24.1, and
failure-to-compile on OpenBSD as a new regression, the former is far
preferable, unless you can point out some consequence that is more
serious that the discussion in Bug#11519 implies.

Also, if we revert 108048, should we revert 108020 (which is in 24.1) as
well?  Could you explain what problem 108020 causes which 108048 is
supposed to fix?  Does it have symptoms?

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.