[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MS-Windows build broken in Fmake_network_process

From: Eli Zaretskii
Subject: MS-Windows build broken in Fmake_network_process
Date: Fri, 26 Mar 2010 18:22:36 +0300

This change:

    revno: 99750
    author: Helmut Eller <address@hidden>
    committer: YAMAMOTO Mitsuharu <address@hidden>
    branch nick: trunk
    timestamp: Thu 2010-03-25 17:48:52 +0900
      Call `select' for interrupted `connect' rather than creating new socket 

breaks the MS-Windows build:

The compiler emits a warning, and the linker errors out:

  gcc -I. -c -gdwarf-2 -g3  -mtune=pentium4 -O2     -Demacs=1 -DHAVE_CONFIG_H 
-I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o oo-spd/i386/process.o process.c
  process.c: In function `Fmake_network_process':
  process.c:3663: warning: passing arg 4 of `getsockopt' from incompatible 
pointer type

  oo-spd/i386/temacs1.a(process.o)(.text+0x3297): In function 
  D:\gnu\bzr\emacs\trunk\src/process.c:3663: undefined reference to 

The compiler warning is because the prototype on Windows is:

  int getsockopt(SOCKET, int, int, char*, int*);

The linker error is because we would need to link against yet another
library to get this function.  But I don't think we should do that.
I'm actually bewildered why this code:

            int len = sizeof xerrno;
            eassert (FD_ISSET (s, &fdset));
            if (getsockopt (s, SOL_SOCKET, SO_ERROR, &xerrno, &len) == -1)
              report_file_error ("getsockopt failed", Qnil);

was used unconditionally when a very similar code in
wait_reading_process_output is clearly marked with a comment saying
not to use it except on GNU/Linux:

  #ifdef GNU_LINUX
                /* getsockopt(,,SO_ERROR,,) is said to hang on some systems.
                   So only use it on systems where it is known to work.  */
                  int xlen = sizeof(xerrno);
                  if (getsockopt(channel, SOL_SOCKET, SO_ERROR, &xerrno, &xlen))
                    xerrno = errno;

Would you please provide an alternative code (similar to what the
#else branch does in wait_reading_process_output) that will not use

reply via email to

[Prev in Thread] Current Thread [Next in Thread]