GNU bug report logs - #9960
Compiling Emacs trunk with MSVC

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: mario <at> lassnig.net, cyd <at> gnu.org, 9772 <at> debbugs.gnu.org, 9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
Subject: bug#9960: OSX breakage
Date: Tue, 29 Nov 2011 18:39:56 +0200

> Date: Tue, 29 Nov 2011 01:28:30 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>, mario <at> lassnig.net, 
>  9772 <at> debbugs.gnu.org, 9960 <at> debbugs.gnu.org, 10155 <at> debbugs.gnu.org
> 
> On 11/28/11 21:00, Chong Yidong wrote:
> > As Eli pointed out in the discussion on bug#10155, there is already code
> > in lib/unistd.in.h that apparently ought to handle this, but itsn't
> > working.
> 
> Here's a proposed patch to fix that, by having Emacs use Gnulib's
> environ module.  This syncs from Gnulib, and so it also brings
> in the patches for Bug#9772 and Bug#9960.  (It is possible to
> pull out just the environ fix by hand, but that's an error-prone process
> and I'd rather avoid it.)  I have tested this on Fedora 15,
> but not on OSX nor on Windows.

FWIW, I'd very much prefer not to install such large changes a day or
two before the next pretest.  If the only practical way of fixing this
within gnulib is the proposed changeset, I'd say let's just add a
declaration of environ conditioned on OS X and FreeBSD.  I don't like
this solution, but I think on balance it has less potential for
destabilizing the build.

Previous Next

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