trunk build failure on Solaris 2.6

trunk build failure on Solaris 2.6

[Katsumi Yamaoka]

Hi,

I don't know at all what's going on but this change

2007-10-17  Chong Yidong  <cyd@stupidchicken.com>

	* configure.in (HAVE_RES_INIT): Define if res_init() exists.
	(HAVE_LIBRESOLV): Also define if we are using res_init().

makes Solaris 2.6 with Gcc 3.3 use res_init and fail to build
Emacs trunk.

config.log
==========
configure:19614: checking for res_init
[...]
configure:19693: result: no
configure:19704: checking for res_init with -lresolv
configure:19729: gcc -o conftest -I/usr/local/include -I/usr/local/X11/include\
 -g -O2 -I/usr/local/include -I/usr/local/X11/include -L/usr/local/lib\
 -L/usr/local/X11/lib conftest.c -lmail -lm -lXext -lXmu -lXt -lSM -lICE -lX11\
 -lsocket -lnsl -lkstat -lresolv >&5
configure:19735: $? = 0
configure:19751: result: yes

make bootstrap
==============
gcc [...] -o temacs [...]
Undefined  first referenced
 symbol        in file
res_init       process.o  (symbol belongs to implicit dependency /usr/lib/libresolv.so.2)
ld: fatal: Symbol referencing errors. No output written to temacs

Removing the `#define HAVE_RES_INIT 1' line in config.h does the
trick.  Does adding something to s/sol2*.h solve it?  Sorry, I
have no Solaris machine other than 2.6 (this is in the office,
so I cannot fiddle it in the week end).

Regards,

Re: trunk build failure on Solaris 2.6

[William Xu]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I don't know at all what's going on but this change
>
> 2007-10-17  Chong Yidong  <cyd@stupidchicken.com>
>
> 	* configure.in (HAVE_RES_INIT): Define if res_init() exists.
> 	(HAVE_LIBRESOLV): Also define if we are using res_init().
>
> makes Solaris 2.6 with Gcc 3.3 use res_init and fail to build
> Emacs trunk.

Looks like same as (on macosx): <A8B2926F-C93C-41A3-8FFA-A85BFC448DC5@meer.net>

I also encounter this on my macosx..

-- 
William

http://williamxu.net9.org

Re: trunk build failure on Solaris 2.6

[Chong Yidong]

Does compilation complete with this patch applied?

*** trunk/configure~	2007-10-18 22:58:26.000000000 -0400
--- trunk/configure	2007-10-18 23:11:38.000000000 -0400
***************
*** 20236,20241 ****
--- 20236,20242 ----
  
  # Do we need libresolv (due to res_init or Hesiod)?
  if test "$resolv" = yes ; then
+   LIBS="$LIBS -lresolv"
  
  cat >>confdefs.h <<\_ACEOF
  #define HAVE_LIBRESOLV 1
*** trunk/configure.in.~1.477.~	2007-10-17 11:49:43.000000000 -0400
--- trunk/configure.in	2007-10-18 23:08:44.000000000 -0400
***************
*** 2818,2823 ****
--- 2818,2824 ----
  
  # Do we need libresolv (due to res_init or Hesiod)?
  if test "$resolv" = yes ; then
+   LIBS="$LIBS -lresolv"
    AC_DEFINE(HAVE_LIBRESOLV, 1,
              [Define to 1 if you have the resolv library (-lresolv).])
  fi

Re: trunk build failure on Solaris 2.6

[William Xu]

Chong Yidong <cyd@stupidchicken.com> writes:

> Does compilation complete with this patch applied?

Still same error here: 

gcc  -prebind -framework Carbon -framework QuickTime -Xlinker -headerpad
-Xlinker 690  -o temacs pre-crt0.o dispnew.o frame.o scroll.o xdisp.o
window.o charset.o coding.o category.o ccl.o cm.o term.o terminal.o
xfaces.o   emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o
filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o
cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o
data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o
abbrev.o syntax.o unexmacosx.o bytecode.o process.o callproc.o
region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o
textprop.o composite.o md5.o  mac.o macterm.o macfns.o macmenu.o
macselect.o fontset.o fringe.o image.o  terminfo.o lastfile.o
-lncurses   
/usr/bin/ld: warning prebinding disabled because of undefined symbols
/usr/bin/ld: Undefined symbols:
_res_9_init
collect2: ld returned 1 exit status
make[2]: *** [temacs] Error 1
make[1]: *** [bootstrap-build] Error 2
make: *** [bootstrap] Error 2

-- 
William

http://williamxu.net9.org

Re: trunk build failure on Solaris 2.6

[Chong Yidong]

William Xu <william.xwl@gmail.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Does compilation complete with this patch applied?
>
> Still same error here: 

How about if you revert the previous patch I posted, and use this one?

*** trunk/src/Makefile.in.~1.355.~	2007-10-12 13:33:38.000000000 -0400
--- trunk/src/Makefile.in	2007-10-19 00:21:18.000000000 -0400
***************
*** 459,464 ****
--- 459,471 ----
  #define LIBGPM
  #endif /* not HAVE_GPM */
  
+ #if HAVE_LIBRESOLV
+ #ifndef LIBRESOLV
+ #define LIBRESOLV -lresolv
+ #endif /* not defined LIBRESOLV */
+ #else /* not HAVE_LIBRESOLV */
+ #define LIBRESOLV
+ #endif /* not HAVE_LIBRESOLV */
  
  LIBSOUND= @LIBSOUND@
  CFLAGS_SOUND= @CFLAGS_SOUND@
***************
*** 940,946 ****
     duplicated symbols.  If the standard libraries were compiled
     with GCC, we might need gnulib again after them.  */
  LIBES = $(LOADLIBES) $(LIBS) $(LIBX) $(LIBSOUND) $(RSVG_LIBS) LIBGPM \
!    LIBS_SYSTEM LIBS_MACHINE LIBS_TERMCAP \
     LIBS_DEBUG $(GETLOADAVG_LIBS) $(GNULIB_VAR) LIB_MATH LIB_STANDARD \
     $(GNULIB_VAR)
  
--- 947,953 ----
     duplicated symbols.  If the standard libraries were compiled
     with GCC, we might need gnulib again after them.  */
  LIBES = $(LOADLIBES) $(LIBS) $(LIBX) $(LIBSOUND) $(RSVG_LIBS) LIBGPM \
!    LIBRESOLV LIBS_SYSTEM LIBS_MACHINE LIBS_TERMCAP \
     LIBS_DEBUG $(GETLOADAVG_LIBS) $(GNULIB_VAR) LIB_MATH LIB_STANDARD \
     $(GNULIB_VAR)

Re: trunk build failure on Solaris 2.6

[Katsumi Yamaoka]

>>>>> Chong Yidong wrote:

> Does compilation complete with this patch applied?

Thanks, but it made no difference.

config.log
==========
configure:19614: checking for res_init
configure:19670: gcc -o conftest [...]
Undefined  first referenced
 symbol        in file
res_init       /var/tmp//cca3IgC2.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure:19676: $? = 1
configure: failed program was:
[...]
configure:19693: result: no

configure:19704: checking for res_init with -lresolv
[...]
configure:19751: result: yes

Because of the latter(?), HAVE_RES_INIT was set in src/config.h
as before and building Emacs failed.

Regards,

Re: trunk build failure on Solaris 2.6

[William Xu]

Chong Yidong <cyd@stupidchicken.com> writes:

> How about if you revert the previous patch I posted, and use this one?

Sadly, same error..

-- 
William

http://williamxu.net9.org

Re: trunk build failure on Solaris 2.6

[Cyrus Harmon]

FWIW, I see the same error building on MacOS X 10.4.10

Cyrus

On Oct 18, 2007, at 8:51 PM, William Xu wrote:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Does compilation complete with this patch applied?
>
> Still same error here:
>
> gcc  -prebind -framework Carbon -framework QuickTime -Xlinker - 
> headerpad
> -Xlinker 690  -o temacs pre-crt0.o dispnew.o frame.o scroll.o xdisp.o
> window.o charset.o coding.o category.o ccl.o cm.o term.o terminal.o
> xfaces.o   emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o
> filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o
> cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o
> data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o  
> lread.o
> abbrev.o syntax.o unexmacosx.o bytecode.o process.o callproc.o
> region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o
> textprop.o composite.o md5.o  mac.o macterm.o macfns.o macmenu.o
> macselect.o fontset.o fringe.o image.o  terminfo.o lastfile.o
> -lncurses
> /usr/bin/ld: warning prebinding disabled because of undefined symbols
> /usr/bin/ld: Undefined symbols:
> _res_9_init
> collect2: ld returned 1 exit status
> make[2]: *** [temacs] Error 1
> make[1]: *** [bootstrap-build] Error 2
> make: *** [bootstrap] Error 2
>
> -- 
> William
>
> http://williamxu.net9.org
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: trunk build failure on Solaris 2.6

[Chong Yidong]

William Xu <william.xwl@gmail.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> How about if you revert the previous patch I posted, and use this one?
>
> Sadly, same error..

Did you run configure again after patching?

Re: trunk build failure on Solaris 2.6

[William Xu]

Chong Yidong <cyd@stupidchicken.com> writes:

> Did you run configure again after patching?

No, i didn't, since it looks like that `make bootstrap' would rerun
configure automatically?

Anyway, with your src/Makefile.in patch, i manually configure again,
then bootstrap, still fail.

-- 
William

http://williamxu.net9.org

Re: trunk build failure on Solaris 2.6

[Chong Yidong]

Could you try the following patch on Solaris?

William Xu said it didn't work on the Mac, but I am not familiar with
the mac build system; I'd like to first see if it works on a non-gnu
Unix.

*** trunk/src/Makefile.in.~1.355.~	2007-10-12 13:33:38.000000000 -0400
--- trunk/src/Makefile.in	2007-10-19 00:21:18.000000000 -0400
***************
*** 459,464 ****
--- 459,471 ----
  #define LIBGPM
  #endif /* not HAVE_GPM */
  
+ #if HAVE_LIBRESOLV
+ #ifndef LIBRESOLV
+ #define LIBRESOLV -lresolv
+ #endif /* not defined LIBRESOLV */
+ #else /* not HAVE_LIBRESOLV */
+ #define LIBRESOLV
+ #endif /* not HAVE_LIBRESOLV */
  
  LIBSOUND= @LIBSOUND@
  CFLAGS_SOUND= @CFLAGS_SOUND@
***************
*** 940,946 ****
     duplicated symbols.  If the standard libraries were compiled
     with GCC, we might need gnulib again after them.  */
  LIBES = $(LOADLIBES) $(LIBS) $(LIBX) $(LIBSOUND) $(RSVG_LIBS) LIBGPM \
!    LIBS_SYSTEM LIBS_MACHINE LIBS_TERMCAP \
     LIBS_DEBUG $(GETLOADAVG_LIBS) $(GNULIB_VAR) LIB_MATH LIB_STANDARD \
     $(GNULIB_VAR)
  
--- 947,953 ----
     duplicated symbols.  If the standard libraries were compiled
     with GCC, we might need gnulib again after them.  */
  LIBES = $(LOADLIBES) $(LIBS) $(LIBX) $(LIBSOUND) $(RSVG_LIBS) LIBGPM \
!    LIBRESOLV LIBS_SYSTEM LIBS_MACHINE LIBS_TERMCAP \
     LIBS_DEBUG $(GETLOADAVG_LIBS) $(GNULIB_VAR) LIB_MATH LIB_STANDARD \
     $(GNULIB_VAR)

Re: trunk build failure on Solaris 2.6

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Could you try the following patch on Solaris?

It works for me on solaris sparc-sun-solaris2.9, -lresolv is added to
the link line for temacs.

Re: trunk build failure on Solaris 2.6

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>   > Could you try the following patch on Solaris?
>
> It works for me on solaris sparc-sun-solaris2.9, -lresolv is added to
> the link line for temacs.

Thanks.  I've checked in the patch to Makefile.in adding -lresolv.

Could a Mac maintainer try to find out why it's not working on that
platform?

Re: trunk build failure on Solaris 2.6

[Evil Boris]

Dan Nicolaescu <dann <at> ics.uci.edu> writes:

> It works for me on solaris sparc-sun-solaris2.9, -lresolv is added to
> the link line for temacs.

Had same problem on Solaris 2.7 on SPARC.  With the most recent update linking
temacs succeeds.

Re: trunk build failure on Solaris 2.6

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 19 Oct 2007 16:42:33 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> Could a Mac maintainer try to find out why it's not working on that
> platform?

As address queries via getaddrinfo are normally forwarded to a daemon
called lookupd on Mac OS X, I suspect it doesn't make sense to call
res_init before getaddrinfo on that platform in the first place.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: trunk build failure on Solaris 2.6

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Fri, 19 Oct 2007 16:42:33 -0400, Chong Yidong <cyd@stupidchicken.com> said:
>
>> Could a Mac maintainer try to find out why it's not working on that
>> platform?
>
> As address queries via getaddrinfo are normally forwarded to a
> daemon called lookupd on Mac OS X, I suspect it doesn't make sense
> to call res_init before getaddrinfo on that platform in the first
> place.

Then this bit of code in the configure script should fail, but it
apparently succeeds; that's why HAVE_LIBRESOLV is defined.

  LIBS="$LIBS -lresolv"
  AC_MSG_CHECKING(for res_init with -lresolv)
  AC_TRY_LINK([#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h> ],
    [res_init();],
    have_res_init=yes, have_res_init=no)

Re: trunk build failure on Solaris 2.6

[William Xu]

Chong Yidong <cyd@stupidchicken.com> writes:

> Could a Mac maintainer try to find out why it's not working on that
> platform?

This may be a fix: <786A49C2-4433-47BA-97F3-1C35A0C3ADEF@Freenet.DE>

-- 
William

http://williamxu.net9.org

Re: trunk build failure on Solaris 2.6

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 20 Oct 2007 13:05:52 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>>>>>> On Fri, 19 Oct 2007 16:42:33 -0400, Chong Yidong
>>>>>>> <cyd@stupidchicken.com> said:
>> 
>>> Could a Mac maintainer try to find out why it's not working on
>>> that platform?
>> 
>> As address queries via getaddrinfo are normally forwarded to a
>> daemon called lookupd on Mac OS X, I suspect it doesn't make sense
>> to call res_init before getaddrinfo on that platform in the first
>> place.

> Then this bit of code in the configure script should fail, but it
> apparently succeeds; that's why HAVE_LIBRESOLV is defined.

I was not talking about how the configure script works, but whether
the `res_init' call makes sense on Mac OS X in the first place.

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.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: trunk build failure on Solaris 2.6

[William Xu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> 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.

BTW, I think this may be related.

I added -lresolv manually to make emacs compile, and with the newly
built emacs, it hangs when i try to `gnus-group-get-new-news' in Gnus
Group buffer. (See backtrace in the end)

And i find if i revert the following changes in process.c, then no problem.

,----[ process.c ]
| Link to libs for calling res_init() if available.
| (Fmake_network_process): Call res_init() before getaddrinfo or
| gethostbyname, if possible.
`----

---------------------------------8<------------------------------------- 
^Z
Program received signal SIGTSTP, Stopped (user).
0xffff8390 in ___gettimeofday () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:182
182     /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h: No such file or directory.
        in /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h
(gdb) bt
#0  0xffff8390 in ___gettimeofday () at /System/Library/Frameworks/System.framework/PrivateHeaders/ppc/cpu_capabilities.h:182
#1  0x90005278 in gettimeofday ()
#2  0x00134d80 in wait_reading_process_output (time_limit=0, microsecs=100000, read_kbd=-1, do_display=0, wait_for_cell=58721289, wait_proc=0x8666180, just_wait_proc=0) at /Users/william/repo/cvs/emacs/src/process.c:4370
#3  0x001372cc in Faccept_process_output (process=113491, seconds=0, millisec=1578, just_this_one=1464069094) at /Users/william/repo/cvs/emacs/src/process.c:3986
#4  0x000fa36c in Ffuncall (nargs=-1073756032, args=0xbfffcbe0) at /Users/william/repo/cvs/emacs/src/eval.c:3027
#5  0x0012c54c in Fbyte_code (bytestr=113491, vector=-1073754992, maxdepth=56) at /Users/william/repo/cvs/emacs/src/bytecode.c:679
#6  0x000f9dac in funcall_lambda (fun=34852084, nargs=1, arg_vector=0xbfffce84) at /Users/william/repo/cvs/emacs/src/eval.c:3204
#7  0x000fa4bc in Ffuncall (nargs=-1073756032, args=0x2ea65d9) at /Users/william/repo/cvs/emacs/src/eval.c:3074
#8  0x0012c54c in Fbyte_code (bytestr=113491, vector=-1073754496, maxdepth=40) at /Users/william/repo/cvs/emacs/src/bytecode.c:679
#9  0x000f9dac in funcall_lambda (fun=141105348, nargs=1, arg_vector=0xbfffd074) at /Users/william/repo/cvs/emacs/src/eval.c:3204
...

Lisp Backtrace:
"accept-process-output" (0xbfffcc94)
"nnheader-accept-process-output" (0xbfffce84)
"nntp-accept-process-output" (0xbfffd074)
"nntp-open-connection" (0xbfffd264)
"nntp-open-server" (0xbfffd454)
"byte-code" (0xbfffd524)
"gnus-open-server" (0xbfffdb44)
"byte-code" (0xbfffdc14)
"gnus-activate-group" (0xbfffe244)
"gnus-get-unread-articles" (0xbfffe444)
"gnus-group-get-new-news" (0xbfffe590)
0x20d609d Lisp type 5
"call-interactively" (0xbfffea38)
(gdb) 
---------------------------------8<------------------------------------- 

-- 
William

http://williamxu.net9.org

Re: trunk build failure on Solaris 2.6

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> 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?

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 <cyd@stupidchicken.com> wrote:
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> 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

Re: trunk build failure on Solaris 2.6

[Richard Stallman]

    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

Instead of treating changes and build options as black boxes, can you
look at them as code?  Which lines of code in that change actually
cause the problem -- and how?