Re: trunk build failure on Solaris 2.6

[Mark Aufflick]

I tried all sorts of combinations of #undefs in src/s/darwin.h and
reconfiguring but the correct combination of build options never
eventuated.

As Yamamoto-san did, I simply manually reversed the following
changeset to src/process.c:

http://cvs.savannah.gnu.org/viewvc/emacs/src/process.c?root=emacs&r1=1.520&r2=1.521

I also had to comment out the assertion on line 454 of unexmacosx.c:

/*      assert (filesize <= ranges->size); */

Not sure how much outside the range the dump was, but subsequently the
make bootstrap continued. I am on ppc and I hazarded that the risc
binary dumps would be substantially bigger than those on ix86.

Predictably though, you can't get away with hacks like that and my
emacs-bootstrap binary fails to launch, dieing with the error:

bootstrap-emacs: Cannot allocate memory

more troubleshooting to be done!

Mark.

On 10/23/07, Chong Yidong <address@hidden> wrote:
> YAMAMOTO Mitsuharu <address@hidden> writes:
>
> > The intention of the `res_init' call before getaddrinfo is, as
> > mentioned in configure.in, to detect /etc/resolv.conf changes by
> > initializing some internal states of the resolver routine executed in
> > the Emacs process.  But on Mac OS X, and possibly also on some other
> > platforms, the actual resolution is performed by an external process,
> > and thus the Emacs process is not responsible to detect the
> > /etc/resolv.conf changes.  On such platforms, the `res_init' call does
> > not make sense whether or not the configure script detects the
> > existence of that symbol.
>
> In that case, could you add mac makefile (I believe this is s/darwin.h
> but am not sure) undefining LIBRESOLV?
>

-- 
Mark Aufflick
  contact info at http://mark.aufflick.com/about/contact