windows build failure

windows build failure

[Sean Sieger]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

gcc  -std=gnu99 -DHAVE_CONFIG_H -I. -I/c/trunk/lib -I../src -I/c/trunk/src
  -mt
une=pentium4   -DUSE_CRT_DLL=1 -I /c/trunk/nt/inc    -g3 -O2 -gdwarf-2 -MT
getti
meofday.o -MD -MP -MF .deps/gettimeofday.Tpo -c -o gettimeofday.o
gettimeofday.c

gettimeofday.c:102:1: error: conflicting types for 'gettimeofday'
 gettimeofday (struct timeval *restrict tv, void *restrict tz)
 ^
In file included from gettimeofday.c:23:0:
c:/trunk/nt/inc/sys/time.h:45:5: note: previous declaration of
'gettimeofday' wa
s here
 int gettimeofday (struct timeval *__restrict, struct timezone *__restrict);
     ^
make[3]: *** [gettimeofday.o] Error 1
make[3]: Leaving directory `/c/trunk/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/c/trunk/lib'
make[1]: *** [lib] Error 2
make[1]: Leaving directory `/c/trunk'
make: *** [bootstrap] Error 2

[-- Attachment #2: Type: text/html, Size: 1088 bytes --]

Re: windows build failure

[Eli Zaretskii]

> Date: Tue, 17 Sep 2013 17:45:40 -0400
> From: Sean Sieger <sean.sieger@gmail.com>
> 
> gcc  -std=gnu99 -DHAVE_CONFIG_H -I. -I/c/trunk/lib -I../src -I/c/trunk/src -mtune=pentium4   -DUSE_CRT_DLL=1 -I /c/trunk/nt/inc    -g3 -O2 -gdwarf-2 -MT gettimeofday.o -MD -MP -MF .deps/gettimeofday.Tpo -c -o gettimeofday.o gettimeofday.c
> 
> gettimeofday.c:102:1: error: conflicting types for 'gettimeofday'
>  gettimeofday (struct timeval *restrict tv, void *restrict tz)
>  ^
> In file included from gettimeofday.c:23:0:
> c:/trunk/nt/inc/sys/time.h:45:5: note: previous declaration of 'gettimeofday' was here
>  int gettimeofday (struct timeval *__restrict, struct timezone *__restrict);
>      ^

lib/gettimeofday.c is not supposed to be compiled on Windows (because
Emacs on Windows provides its own implementation of that function).
You should see these two lines (far apart) in your output from
configure:

 checking for gettimeofday... yes
 checking for gettimeofday with POSIX signature... almost

and src/config.h should have this:

  /* Define to 1 if you have the `gettimeofday' function. */
  #define HAVE_GETTIMEOFDAY 1

If you have different results, look in config.log for the details.

Btw, what port of GCC and what runtime library and headers are you
using?

Re: windows build failure

[Dani Moncayo]

>> gcc  -std=gnu99 -DHAVE_CONFIG_H -I. -I/c/trunk/lib -I../src -I/c/trunk/src -mtune=pentium4   -DUSE_CRT_DLL=1 -I /c/trunk/nt/inc    -g3 -O2 -gdwarf-2 -MT gettimeofday.o -MD -MP -MF .deps/gettimeofday.Tpo -c -o gettimeofday.o gettimeofday.c
>>
>> gettimeofday.c:102:1: error: conflicting types for 'gettimeofday'
>>  gettimeofday (struct timeval *restrict tv, void *restrict tz)
>>  ^
>> In file included from gettimeofday.c:23:0:
>> c:/trunk/nt/inc/sys/time.h:45:5: note: previous declaration of 'gettimeofday' was here
>>  int gettimeofday (struct timeval *__restrict, struct timezone *__restrict);
>>      ^
>
> lib/gettimeofday.c is not supposed to be compiled on Windows (because
> Emacs on Windows provides its own implementation of that function).
> You should see these two lines (far apart) in your output from
> configure:
>
>  checking for gettimeofday... yes
>  checking for gettimeofday with POSIX signature... almost
>
> and src/config.h should have this:
>
>   /* Define to 1 if you have the `gettimeofday' function. */
>   #define HAVE_GETTIMEOFDAY 1
>
> If you have different results, look in config.log for the details.
>
> Btw, what port of GCC and what runtime library and headers are you
> using?

I guess he's using the latest released versions (mingwrt-4.0), because
his error is the same I already reported:

  http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00726.html



-- 
Dani Moncayo

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 18 Sep 2013 08:56:31 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> I guess he's using the latest released versions (mingwrt-4.0), because
> his error is the same I already reported:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00726.html

Maybe so, but without seeing the config.log portions that are relevant
to the gettimeofday tests, it is impossible to say what went wrong.

And if Sean does use version 4.0, he's in for much more trouble than
this one.

MINGW RUNTIME VERSION 4 IS BINARY INCOMPATIBLE WITH EVERY IMAGE AND
OTHER 3RD PARTY LIBRARY OUT THERE!  DO NOT USE IT IF YOU CARE ABOUT
YOUR EMACS AND ABOUT YOUR SANITY!  (Or rebuild every library yourself
with this new runtime.)

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    MINGW RUNTIME VERSION 4 IS BINARY INCOMPATIBLE WITH EVERY IMAGE AND
    OTHER 3RD PARTY LIBRARY OUT THERE!  DO NOT USE IT IF YOU CARE ABOUT
    YOUR EMACS AND ABOUT YOUR SANITY!  (Or rebuild every library yourself
    with this new runtime.)

So which MinGW/MSYS to use, then?

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Wed, 18 Sep 2013 08:37:52 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     MINGW RUNTIME VERSION 4 IS BINARY INCOMPATIBLE WITH EVERY IMAGE AND
>     OTHER 3RD PARTY LIBRARY OUT THERE!  DO NOT USE IT IF YOU CARE ABOUT
>     YOUR EMACS AND ABOUT YOUR SANITY!  (Or rebuild every library yourself
>     with this new runtime.)
> 
> So which MinGW/MSYS to use, then?

MSYS is not an issue, only the MinGW runtime (headers and libraries)
is.

MinGW runtime version 3.20 is the latest of the 3.x series, it should
be OK (I use it one of my machines).

Not sure about GCC, though -- it is not supposed to be a problem,
unless the produced executable depends on some DLL that comes with
GCC.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 18 Sep 2013 08:28:53 -0400
> From: Sean Sieger <sean.sieger@gmail.com>
> 
> > lib/gettimeofday.c is not supposed to be compiled on Windows (because
> > Emacs on Windows provides its own implementation of that function).
> > You should see these two lines (far apart) in your output from
> > configure:
> >
> >  checking for gettimeofday... yes
> >  checking for gettimeofday with POSIX signature... almost
> >
> 
> I do.
> 
> and src/config.h should have this:
> >
> >   /* Define to 1 if you have the `gettimeofday' function. */
> >   #define HAVE_GETTIMEOFDAY 1
> >
> 
> It does.

Then I don't understand why you get this.  Perhaps '__restrict' and
'restrict' are not the same for some reason.  Do you have this in
src/config.h:

  #define restrict __restrict

?

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > and src/config.h should have this:
    > >
    > >   /* Define to 1 if you have the `gettimeofday' function. */
    > >   #define HAVE_GETTIMEOFDAY 1
    > >
    > 
    > It does.

    Then I don't understand why you get this.  Perhaps '__restrict' and
    'restrict' are not the same for some reason.  Do you have this in
    src/config.h:

      #define restrict __restrict

    ?

Yep.

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Wed, 18 Sep 2013 09:08:32 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     > and src/config.h should have this:
>     > >
>     > >   /* Define to 1 if you have the `gettimeofday' function. */
>     > >   #define HAVE_GETTIMEOFDAY 1
>     > >
>     > 
>     > It does.
> 
>     Then I don't understand why you get this.  Perhaps '__restrict' and
>     'restrict' are not the same for some reason.  Do you have this in
>     src/config.h:
> 
>       #define restrict __restrict
> 
>     ?
> 
> Yep.

Weird.  What about lib/Makefile, do you have these there:

  HAVE_GETTIMEOFDAY = 1
  REPLACE_GETTIMEOFDAY = 0

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:


    >     'restrict' are not the same for some reason.  Do you have this in
    >     src/config.h:
    > 
    >       #define restrict __restrict
    > 
    >     ?
    > 
    > Yep.

    Weird.  What about lib/Makefile, do you have these there:

      HAVE_GETTIMEOFDAY = 1
      REPLACE_GETTIMEOFDAY = 0

HAVE_GETTIMEOFDAY = 1
REPLACE_GETTIMEOFDAY = 1
                       ^

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Wed, 18 Sep 2013 09:25:44 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> 
>     >     'restrict' are not the same for some reason.  Do you have this in
>     >     src/config.h:
>     > 
>     >       #define restrict __restrict
>     > 
>     >     ?
>     > 
>     > Yep.
> 
>     Weird.  What about lib/Makefile, do you have these there:
> 
>       HAVE_GETTIMEOFDAY = 1
>       REPLACE_GETTIMEOFDAY = 0
> 
> HAVE_GETTIMEOFDAY = 1
> REPLACE_GETTIMEOFDAY = 1

That's expected, but the question is why.

The tests done on gettimeofday are in m4/gettimeofday.m4.  Can you
spot, using config.log, which of the tests fail and forces
REPLACE_GETTIMEOFDAY to be set to 1?

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > HAVE_GETTIMEOFDAY = 1
    > REPLACE_GETTIMEOFDAY = 1

    That's expected, but the question is why.

    The tests done on gettimeofday are in m4/gettimeofday.m4.  Can you
    spot, using config.log, which of the tests fail and forces
    REPLACE_GETTIMEOFDAY to be set to 1?

Yes, of course, over and again,

    configure: failed program was:
    | /* confdefs.h */

Does that help?

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Wed, 18 Sep 2013 11:15:40 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     > HAVE_GETTIMEOFDAY = 1
>     > REPLACE_GETTIMEOFDAY = 1
> 
>     That's expected, but the question is why.
> 
>     The tests done on gettimeofday are in m4/gettimeofday.m4.  Can you
>     spot, using config.log, which of the tests fail and forces
>     REPLACE_GETTIMEOFDAY to be set to 1?
> 
> Yes, of course, over and again,
> 
>     configure: failed program was:
>     | /* confdefs.h */
> 
> Does that help?

No.  How can it?  I need to see the failed program and the error
messages from the compiler.  Please show these _only_ for the tests
that come from gettimeofday.m4.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    No.  How can it?  I need to see the failed program and the error
    messages from the compiler.  Please show these _only_ for the tests
    that come from gettimeofday.m4.

Sorry.

I already started building a new MinGW.  I had a working one and was
building the trunk in-place a month ago, but wrecked it unpacking
ezwinports in the wrong place.  I haven't been able to recreate it
since.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > HAVE_GETTIMEOFDAY = 1
    > REPLACE_GETTIMEOFDAY = 1

    That's expected, but the question is why.

    The tests done on gettimeofday are in m4/gettimeofday.m4.  Can you
    spot, using config.log, which of the tests fail and forces
    REPLACE_GETTIMEOFDAY to be set to 1?

m4/gettimeofday.m4:

  if test $ac_cv_func_gettimeofday != yes; then
    HAVE_GETTIMEOFDAY=0

config.log:

  ac_cv_func_gettimeofday=yes

m4/gettimeofday.m4:

  elif test $gl_cv_func_gettimeofday_posix_signature != yes; then
    REPLACE_GETTIMEOFDAY=1

config.log:

  gl_cv_func_gettimeofday_posix_signature=almost

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Thu, 19 Sep 2013 10:14:17 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     > HAVE_GETTIMEOFDAY = 1
>     > REPLACE_GETTIMEOFDAY = 1
> 
>     That's expected, but the question is why.
> 
>     The tests done on gettimeofday are in m4/gettimeofday.m4.  Can you
>     spot, using config.log, which of the tests fail and forces
>     REPLACE_GETTIMEOFDAY to be set to 1?
> 
> m4/gettimeofday.m4:
> 
>   if test $ac_cv_func_gettimeofday != yes; then
>     HAVE_GETTIMEOFDAY=0
> 
> config.log:
> 
>   ac_cv_func_gettimeofday=yes
> 
> m4/gettimeofday.m4:
> 
>   elif test $gl_cv_func_gettimeofday_posix_signature != yes; then
>     REPLACE_GETTIMEOFDAY=1
> 
> config.log:
> 
>   gl_cv_func_gettimeofday_posix_signature=almost

In the last "elif test" you show only part of the truth.  The whole
truth is this:

    if test $gl_cv_func_gettimeofday_posix_signature = almost; then
      gl_gettimeofday_timezone='struct timezone'
    elif test $gl_cv_func_gettimeofday_posix_signature != yes; then
      REPLACE_GETTIMEOFDAY=1

So "almost" does not trigger REPLACE_GETTIMEOFDAY=1, and the mystery
is not resolved.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    In the last "elif test" you show only part of the truth.  The whole
    truth is this:

        if test $gl_cv_func_gettimeofday_posix_signature = almost; then
          gl_gettimeofday_timezone='struct timezone'
        elif test $gl_cv_func_gettimeofday_posix_signature != yes; then
          REPLACE_GETTIMEOFDAY=1

    So "almost" does not trigger REPLACE_GETTIMEOFDAY=1, and the mystery
    is not resolved.

Is this it?

m4/gettimeofday.m4:

  if test $REPLACE_STRUCT_TIMEVAL = 1; then
    REPLACE_GETTIMEOFDAY=1
  fi

config.log:

  REPLACE_STRUCT_TIMEVAL='1'

Like in the bootstrap error:

gcc  -std=gnu99 -DHAVE_CONFIG_H -I. -I/c/trunk/lib -I../src -I/c/trunk/src   -mt
une=pentium4   -DUSE_CRT_DLL=1 -I /c/trunk/nt/inc    -g3 -O2 -gdwarf-2 -MT getti
meofday.o -MD -MP -MF .deps/gettimeofday.Tpo -c -o gettimeofday.o gettimeofday.c

gettimeofday.c:102:1: error: conflicting types for 'gettimeofday'
 gettimeofday (struct timeval *restrict tv, void *restrict tz)
 ^
In file included from gettimeofday.c:23:0:
c:/trunk/nt/inc/sys/time.h:45:5: note: previous declaration of 'gettimeofday' wa
s here
 int gettimeofday (struct timeval *__restrict, struct timezone *__restrict);
     ^
make[3]: *** [gettimeofday.o] Error 1
make[3]: Leaving directory `/c/trunk/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/c/trunk/lib'
make[1]: *** [lib] Error 2
make[1]: Leaving directory `/c/trunk'
make: *** [bootstrap] Error 2

?

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Thu, 19 Sep 2013 13:33:36 -0400
> 
> m4/gettimeofday.m4:
> 
>   if test $REPLACE_STRUCT_TIMEVAL = 1; then
>     REPLACE_GETTIMEOFDAY=1
>   fi
> 
> config.log:
> 
>   REPLACE_STRUCT_TIMEVAL='1'

Could be.  What does your config.log say for this test:

  checking for wide-enough struct timeval.tv_sec member

If the test fails, please show the test program and the error
messages.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > From: Sean Sieger <sean.sieger@gmail.com>
    > Date: Thu, 19 Sep 2013 13:33:36 -0400
    > 
    > m4/gettimeofday.m4:
    > 
    >   if test $REPLACE_STRUCT_TIMEVAL = 1; then
    >     REPLACE_GETTIMEOFDAY=1
    >   fi
    > 
    > config.log:
    > 
    >   REPLACE_STRUCT_TIMEVAL='1'

    Could be.  What does your config.log say for this test:

      checking for wide-enough struct timeval.tv_sec member

    If the test fails, please show the test program and the error
    messages.


configure:19854: checking for wide-enough struct timeval.tv_sec member
configure:19881: gcc -I /c/trunk/nt/inc -std=gnu99 -c -g3 -O2 -gdwarf-2 -mtune=pentium4   conftest.c >&5
conftest.c: In function 'main':
conftest.c:137:27: error: size of array 'verify_tv_sec_type' is negative
               typedef int verify_tv_sec_type[
                           ^
configure:19881: $? = 1
configure: failed program was:
| /* confdefs.h */

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Thu, 19 Sep 2013 16:25:01 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     > From: Sean Sieger <sean.sieger@gmail.com>
>     > Date: Thu, 19 Sep 2013 13:33:36 -0400
>     > 
>     > m4/gettimeofday.m4:
>     > 
>     >   if test $REPLACE_STRUCT_TIMEVAL = 1; then
>     >     REPLACE_GETTIMEOFDAY=1
>     >   fi
>     > 
>     > config.log:
>     > 
>     >   REPLACE_STRUCT_TIMEVAL='1'
> 
>     Could be.  What does your config.log say for this test:
> 
>       checking for wide-enough struct timeval.tv_sec member
> 
>     If the test fails, please show the test program and the error
>     messages.
> 
> 
> configure:19854: checking for wide-enough struct timeval.tv_sec member
> configure:19881: gcc -I /c/trunk/nt/inc -std=gnu99 -c -g3 -O2 -gdwarf-2 -mtune=pentium4   conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:137:27: error: size of array 'verify_tv_sec_type' is negative
>                typedef int verify_tv_sec_type[
>                            ^
> configure:19881: $? = 1

Yes, that's it, thanks.  This happens because MinGW runtime 4.x
switched to a 64-bit time_t type by default, but 'struct timeval'
defined in winsock2.h and sys/time.h still uses 'long tv_sec'.  This
causes the gnulib tests to decide we need to replace 'struct timeval'
with a Posix-compliant definition, and also replace gettimeofday.

This particular problem for Emacs build should now be fixed: I forced
the configure script to accept the MinGW definition of 'struct
timeval' without testing.

Btw, the switch to 64-bit time_t (or, more accurately, the
corresponding switch to 64-bit time functions) is one of the few
changes in MinGW 4.x that cause binary incompatibility with previous
versions.  So my recommendation not to use MinGW 4.x, especially if
you are running Emacs on XP, still stands.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:
    Yes, that's it, thanks.  This happens because MinGW runtime 4.x
    switched to a 64-bit time_t type by default, but 'struct timeval'
    defined in winsock2.h and sys/time.h still uses 'long tv_sec'.  This
    causes the gnulib tests to decide we need to replace 'struct timeval'
    with a Posix-compliant definition, and also replace gettimeofday.

    This particular problem for Emacs build should now be fixed: I forced
    the configure script to accept the MinGW definition of 'struct
    timeval' without testing.

And it is, thank you.  I built the trunk in place and installed it in
/mingw.

    Btw, the switch to 64-bit time_t (or, more accurately, the
    corresponding switch to 64-bit time functions) is one of the few
    changes in MinGW 4.x that cause binary incompatibility with previous
    versions.  So my recommendation not to use MinGW 4.x, especially if
    you are running Emacs on XP, still stands.

Well, I'll see how it goes.  I'm gonna try unpacking gtk, libxml2 and
gnutls over it next.  I stand forewarned.

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Fri, 20 Sep 2013 10:24:46 -0400
> 
>     Btw, the switch to 64-bit time_t (or, more accurately, the
>     corresponding switch to 64-bit time functions) is one of the few
>     changes in MinGW 4.x that cause binary incompatibility with previous
>     versions.  So my recommendation not to use MinGW 4.x, especially if
>     you are running Emacs on XP, still stands.
> 
> Well, I'll see how it goes.  I'm gonna try unpacking gtk, libxml2 and
> gnutls over it next.  I stand forewarned.

Does the below work as expected?

  emacs -Q c*.c

If you do this from the src directory, you should end up with visiting
the 14 C files that match the wildcard in the Emacs's src directory.
What do you get in Emacs linked with the new MinGW runtime?

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > From: Sean Sieger <sean.sieger@gmail.com>
    > Date: Fri, 20 Sep 2013 10:24:46 -0400
    > 
    >     Btw, the switch to 64-bit time_t (or, more accurately, the
    >     corresponding switch to 64-bit time functions) is one of the few
    >     changes in MinGW 4.x that cause binary incompatibility with previous
    >     versions.  So my recommendation not to use MinGW 4.x, especially if
    >     you are running Emacs on XP, still stands.
    > 
    > Well, I'll see how it goes.  I'm gonna try unpacking gtk, libxml2 and
    > gnutls over it next.  I stand forewarned.

    Does the below work as expected?

      emacs -Q c*.c

    If you do this from the src directory, you should end up with visiting
    the 14 C files that match the wildcard in the Emacs's src directory.
    What do you get in Emacs linked with the new MinGW runtime?

I do; and the same.  Is that good??  (:

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > From: Sean Sieger <sean.sieger@gmail.com>
    > Date: Fri, 20 Sep 2013 10:24:46 -0400
    > 
    >     Btw, the switch to 64-bit time_t (or, more accurately, the
    >     corresponding switch to 64-bit time functions) is one of the few
    >     changes in MinGW 4.x that cause binary incompatibility with previous
    >     versions.  So my recommendation not to use MinGW 4.x, especially if
    >     you are running Emacs on XP, still stands.
    > 
    > Well, I'll see how it goes.  I'm gonna try unpacking gtk, libxml2 and
    > gnutls over it next.  I stand forewarned.

    Does the below work as expected?

      emacs -Q c*.c

    If you do this from the src directory, you should end up with visiting
    the 14 C files that match the wildcard in the Emacs's src directory.
    What do you get in Emacs linked with the new MinGW runtime?

Wait, wait, wait ...

MinGW-Shell:

Sean@blah /c/trunk/src/
$ emacs -Q c*.c

... I get the correct result.

Command Prompt:

c:\trunk\src>emacs -Q c*.c

... nope, visits the non-existent, `c*.c'.

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Fri, 20 Sep 2013 12:34:28 -0400
> 
>     Does the below work as expected?
> 
>       emacs -Q c*.c
> 
>     If you do this from the src directory, you should end up with visiting
>     the 14 C files that match the wildcard in the Emacs's src directory.
>     What do you get in Emacs linked with the new MinGW runtime?
> 
> Wait, wait, wait ...
> 
> MinGW-Shell:
> 
> Sean@blah /c/trunk/src/
> $ emacs -Q c*.c
> 
> ... I get the correct result.

In the MSYS Bash, the shell does the wildcard expansion, that's why
you get correct results.

> Command Prompt:
> 
> c:\trunk\src>emacs -Q c*.c
> 
> ... nope, visits the non-existent, `c*.c'.

Right, as I expected.

Here's why: MinGW runtime v4.x changed the layout of 'struct dirent',
the structure returned by 'readdir', in an incompatible way.  Where
previously we had

  struct dirent
  {
	  long			d_ino;		/* Always zero. */
	  unsigned short	d_reclen;	/* Always zero. */
	  unsigned short	d_namlen;	/* Length of name in d_name. */
	  char			d_name[FILENAME_MAX]; /* File name. */
  };

we now have

  struct dirent
  {
	  long			d_ino;		/* Always zero. */
	  unsigned short	d_reclen;	/* Always zero. */
	  unsigned short	d_namlen;	/* Length of name in d_name. */

	  /* The following exactly mimic the layout of _finddata_t ...
	   */
	  unsigned		d_type;		/* File attributes */
	  time_t		d_time_create;
	  time_t		d_time_access;	/* always midnight local time */
	  time_t		d_time_write;
	  _fsize_t		d_size;
	  /*
	   * ...so that we may map a union of _finddata_t at the
	   * location of d_type (corresponding to _finddata_t.attrib),
	   * and thus map this directly to the _findfirst/_findnext
	   * returned field.
	   */
	  char			d_name[FILENAME_MAX]; /* File name. */
  };

As you see d_name[] moved, and is now at a different offset.

That in itself is already a bad idea, because linking a program with a
library that was compiled with an older version of dirent.h will now
produce a buggy program, which will look for the file name in a wrong
place.  However, it might still be OK for Emacs, because Emacs has its
own definition of 'struct dirent' and its own implementation of
'readdir', and thus does not use the ones provided by the MinGW
runtime.

But then the MinGW developers added insult to injury, by calling
'readdir' from the startup code.  This is an absolute no-no for a
library, because a C program can legitimately have an incompatible
function named 'readdir' that might even have nothing to do with
reading a directory.

What happens in Emacs as result is that the startup code calls the
Emacs implementation of 'readdir', which uses an incompatible 'struct
dirent', and the result is that globbing of wildcards is broken.

At the time, I tried to convince the MinGW developers not to do this,
here:

  http://sourceforge.net/mailarchive/message.php?msg_id=29278605
  http://sourceforge.net/mailarchive/message.php?msg_id=30712991
  http://sourceforge.net/mailarchive/message.php?msg_id=30715094
  http://sourceforge.net/mailarchive/message.php?msg_id=30854291

Evidently, I failed completely to convince them, as the incompatible
runtime went to print regardless, and the problems will now begin
unfolding before our eyes...

Re: windows build failure

[Eli Zaretskii]

> Date: Fri, 20 Sep 2013 20:40:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Sean Sieger <sean.sieger@gmail.com>
> > Date: Fri, 20 Sep 2013 12:34:28 -0400
> > 
> >     Does the below work as expected?
> > 
> >       emacs -Q c*.c
> > 
> >     If you do this from the src directory, you should end up with visiting
> >     the 14 C files that match the wildcard in the Emacs's src directory.
> >     What do you get in Emacs linked with the new MinGW runtime?
> > 
> > Wait, wait, wait ...
> > 
> > MinGW-Shell:
> > 
> > Sean@blah /c/trunk/src/
> > $ emacs -Q c*.c
> > 
> > ... I get the correct result.
> 
> In the MSYS Bash, the shell does the wildcard expansion, that's why
> you get correct results.
> 
> > Command Prompt:
> > 
> > c:\trunk\src>emacs -Q c*.c
> > 
> > ... nope, visits the non-existent, `c*.c'.
> 
> Right, as I expected.
> 
> Here's why: MinGW runtime v4.x changed the layout of 'struct dirent',
> the structure returned by 'readdir', in an incompatible way.  Where
> previously we had
> [...]
> What happens in Emacs as result is that the startup code calls the
> Emacs implementation of 'readdir', which uses an incompatible 'struct
> dirent', and the result is that globbing of wildcards is broken.

I tried to fix this problem in trunk revision 114637.  If you (or
someone else who would like to move to the new MinGW runtime) have
time, please re-test with v4.0 of the MinGW runtime.

Please also try the various time-related functions, such as
decode-time, encode-time, format-time-string, and
current-time-string.  This is because MinGW32 runtime 4.0 also moved
to using a 64-bit time_t type by default, which according to my
testing screws up Emacs, especially if it was built on Windows 7 and
then run on XP.  So for now, I forced the MinGW32 headers to use a
32-bit time_t type.  This needs to be thoroughly tested, though.

Thanks.

> At the time, I tried to convince the MinGW developers not to do this,
> here:
> 
>   http://sourceforge.net/mailarchive/message.php?msg_id=29278605
>   http://sourceforge.net/mailarchive/message.php?msg_id=30712991
>   http://sourceforge.net/mailarchive/message.php?msg_id=30715094
>   http://sourceforge.net/mailarchive/message.php?msg_id=30854291
> 
> Evidently, I failed completely to convince them, as the incompatible
> runtime went to print regardless, and the problems will now begin
> unfolding before our eyes...

Well, it turns out the MinGW developers might be listening after all,
at least to some of the arguments: I'm promised that the next release
of the runtime will not call opendir/readdir from the startup code.
We shall see...

Re: windows build failure

[Paul Eggert]

Eli Zaretskii wrote:
> This is because MinGW32 runtime 4.0 also moved
> to using a 64-bit time_t type by default, which according to my
> testing screws up Emacs

What screwups do you observe?  Are they limited to MinGW32
or might they affect POSIXish 32-bit hosts with 64-bit time_t?

The reason I'm asking is that on on 32-bit hosts,
Emacs's hacky representation of time values is
limited to time_t values in the range [- 2**45, 2**45),
and Emacs reports an error via time_overflow when asked
to compute a time out of that range, even if it is operating
on a platform with 64-bit time_t values.  So, if you set your
system clock to 1116918-05-14 19:20:32 UTC on such a host,
or otherwise deal with outlandish time stamps, Emacs will
have screwups, and it won't be trivial to fix this.

Re: windows build failure

[Eli Zaretskii]

> Date: Sat, 12 Oct 2013 08:55:14 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > This is because MinGW32 runtime 4.0 also moved
> > to using a 64-bit time_t type by default, which according to my
> > testing screws up Emacs
> 
> What screwups do you observe?

Functions that expect 32-bit time_t values and pointers to such values
get 64-bit values/pointers instead.

> Are they limited to MinGW32
> or might they affect POSIXish 32-bit hosts with 64-bit time_t?

The former, of course.  The problem is that MinGW developers tried to
find a way to adapt to the fact that the default system libc switched
to 64-bit time_t since Windows 7, but got confused between
compile-time decisions and run-time decisions.  So building Emacs on
Windows 7 and running it there might still work, but if the binary
gets installed on XP, there will be problems.

The only workaround I found was to force 32-bit time_t (which is what
previous MinGW runtime was using anyway).  MinGW developers promised
to fix that in the next release, but I will believe that when I see
it.

> The reason I'm asking is that on on 32-bit hosts,
> Emacs's hacky representation of time values is
> limited to time_t values in the range [- 2**45, 2**45),
> and Emacs reports an error via time_overflow when asked
> to compute a time out of that range, even if it is operating
> on a platform with 64-bit time_t values.  So, if you set your
> system clock to 1116918-05-14 19:20:32 UTC on such a host,
> or otherwise deal with outlandish time stamps, Emacs will
> have screwups, and it won't be trivial to fix this.

So you are saying that 32-bit hosts will be dead for Emacs in about
half a year (if I interpret that time stamp correctly), is that right?

Re: windows build failure

[Paul Eggert]

>> > if you set your
>> > system clock to 1116918-05-14 19:20:32 UTC on such a host,
>> > or otherwise deal with outlandish time stamps, Emacs will
>> > have screwups, and it won't be trivial to fix this.

> So you are saying that 32-bit hosts will be dead for Emacs in about
> half a year (if I interpret that time stamp correctly), is that right?

No, it's A.D. 1,116,918, i.e., more than a million years
from now.  Pretty outlandish, admittedly, but people often
use Emacs for outlandish things.  On my 64-bit host with
TZ=UTC0, (current-time-string '(536870912 0)) returns
"Sat May 14 19:20:32 1116918", the correct value;
on GNU/Linux x32, though, Emacs configured without --with-wide-int
will report an error even though that platform's 64-bit time_t
can represent that time stamp; this is because 536870912 doesn't
fit in an Emacs integer when EMACS_INT is 32 bits.

I expect that MinGW32 will behave like GNU/Linux x32 once you
get those time_t pointer bugs fixed.

Re: windows build failure

[Eli Zaretskii]

> Date: Sat, 12 Oct 2013 12:13:08 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> >> > if you set your
> >> > system clock to 1116918-05-14 19:20:32 UTC on such a host,
> >> > or otherwise deal with outlandish time stamps, Emacs will
> >> > have screwups, and it won't be trivial to fix this.
> 
> > So you are saying that 32-bit hosts will be dead for Emacs in about
> > half a year (if I interpret that time stamp correctly), is that right?
> 
> No, it's A.D. 1,116,918, i.e., more than a million years
> from now.

That's a relief.

> Pretty outlandish, admittedly, but people often
> use Emacs for outlandish things.  On my 64-bit host with
> TZ=UTC0, (current-time-string '(536870912 0)) returns
> "Sat May 14 19:20:32 1116918", the correct value;
> on GNU/Linux x32, though, Emacs configured without --with-wide-int
> will report an error even though that platform's 64-bit time_t
> can represent that time stamp; this is because 536870912 doesn't
> fit in an Emacs integer when EMACS_INT is 32 bits.

I get "Invalid time specification" with 536870912 on Windows.  But I
also get that error for any value beyond 32767 (that corresponds to
"Mon Jan 18 11:01:52 2038"), as I'd expect for a 32-bit time_t.  Am I
missing something?

Re: windows build failure

[Paul Eggert]

Eli Zaretskii wrote:
> I get "Invalid time specification" with 536870912 on Windows.  But I
> also get that error for any value beyond 32767 (that corresponds to
> "Mon Jan 18 11:01:52 2038"), as I'd expect for a 32-bit time_t.

Thats sounds correct for 32-bit time_t, and wrong for 64-bit time_t.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    I tried to fix this problem in trunk revision 114637.  If you (or
    someone else who would like to move to the new MinGW runtime) have
    time, please re-test with v4.0 of the MinGW runtime.

Yes, of course.  Monday morning.

    Please also try the various time-related functions, such as
    decode-time, encode-time, format-time-string, and
    current-time-string.  This is because MinGW32 runtime 4.0 also moved
    to using a 64-bit time_t type by default, which according to my
    testing screws up Emacs, especially if it was built on Windows 7 and
    then run on XP.  So for now, I forced the MinGW32 headers to use a
    32-bit time_t type.  This needs to be thoroughly tested, though.

    Thanks.

Thank you, Eli.

    Well, it turns out the MinGW developers might be listening after all,
    at least to some of the arguments: I'm promised that the next release
    of the runtime will not call opendir/readdir from the startup code.
    We shall see...

Yeah, I've been watching them.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    I tried to fix this problem in trunk revision 114637.  If you (or
    someone else who would like to move to the new MinGW runtime) have
    time, please re-test with v4.0 of the MinGW runtime.

Loading loadup.el (source)...
Using load-path (c:/trunk/lisp c:/trunk/lisp/emacs-lisp c:/trunk/lisp/language c
:/trunk/lisp/international c:/trunk/lisp/textmodes)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version...
Specified time is not representable
cd ../lisp; make -w compile-first EMACS=/c/trunk/src/bootstrap-emacs.exe
make[2]: Entering directory `/c/trunk/lisp'
make[2]: Nothing to be done for `compile-first'.
make[2]: Leaving directory `/c/trunk/lisp'
cd ../leim && make -w leim-list.el EMACS=/c/trunk/src/bootstrap-emacs.exe
make[2]: Entering directory `/c/trunk/leim'
make[2]: Leaving directory `/c/trunk/leim'
if test "no" = "yes"; then \
          rm -f emacs.exe; \
          ln temacs.exe emacs.exe; \
        else \
          LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump || exit 1; \
          test "X" = X ||  -zex emacs.exe; \
          rm -f bootstrap-emacs.exe; \
          ln emacs.exe bootstrap-emacs.exe; \
        fi
Loading loadup.el (source)...
Using load-path (c:/trunk/lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version...
Specified time is not representable
ln: accessing `emacs.exe': No such file or directory
make[1]: *** [emacs.exe] Error 1
make[1]: Leaving directory `/c/trunk/src'
make: *** [src] Error 2

    Please also try the various time-related functions, such as
    decode-time, encode-time, format-time-string, and
    current-time-string.  This is because MinGW32 runtime 4.0 also moved
    to using a 64-bit time_t type by default, which according to my
    testing screws up Emacs, especially if it was built on Windows 7 and
    then run on XP.  So for now, I forced the MinGW32 headers to use a
    32-bit time_t type.  This needs to be thoroughly tested, though.

    Thanks.

    Well, it turns out the MinGW developers might be listening after all,
    at least to some of the arguments: I'm promised that the next release
    of the runtime will not call opendir/readdir from the startup code.
    We shall see...

Next?

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Mon, 14 Oct 2013 08:41:25 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>     I tried to fix this problem in trunk revision 114637.  If you (or
>     someone else who would like to move to the new MinGW runtime) have
>     time, please re-test with v4.0 of the MinGW runtime.
> 
> Loading loadup.el (source)...
> Using load-path (c:/trunk/lisp c:/trunk/lisp/emacs-lisp c:/trunk/lisp/language c
> :/trunk/lisp/international c:/trunk/lisp/textmodes)
> Loading emacs-lisp/byte-run...
> Loading emacs-lisp/backquote...
> Loading subr...
> Loading version...
> Specified time is not representable
> cd ../lisp; make -w compile-first EMACS=/c/trunk/src/bootstrap-emacs.exe
> make[2]: Entering directory `/c/trunk/lisp'
> make[2]: Nothing to be done for `compile-first'.
> make[2]: Leaving directory `/c/trunk/lisp'
> cd ../leim && make -w leim-list.el EMACS=/c/trunk/src/bootstrap-emacs.exe
> make[2]: Entering directory `/c/trunk/leim'
> make[2]: Leaving directory `/c/trunk/leim'
> if test "no" = "yes"; then \
>           rm -f emacs.exe; \
>           ln temacs.exe emacs.exe; \
>         else \
>           LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump || exit 1; \
>           test "X" = X ||  -zex emacs.exe; \
>           rm -f bootstrap-emacs.exe; \
>           ln emacs.exe bootstrap-emacs.exe; \
>         fi
> Loading loadup.el (source)...
> Using load-path (c:/trunk/lisp)
> Loading emacs-lisp/byte-run...
> Loading emacs-lisp/backquote...
> Loading subr...
> Loading version...
> Specified time is not representable
> ln: accessing `emacs.exe': No such file or directory
> make[1]: *** [emacs.exe] Error 1
> make[1]: Leaving directory `/c/trunk/src'
> make: *** [src] Error 2
> 
>     Please also try the various time-related functions, such as
>     decode-time, encode-time, format-time-string, and
>     current-time-string.  This is because MinGW32 runtime 4.0 also moved
>     to using a 64-bit time_t type by default, which according to my
>     testing screws up Emacs, especially if it was built on Windows 7 and
>     then run on XP.  So for now, I forced the MinGW32 headers to use a
>     32-bit time_t type.  This needs to be thoroughly tested, though.
> 
>     Thanks.
> 
>     Well, it turns out the MinGW developers might be listening after all,
>     at least to some of the arguments: I'm promised that the next release
>     of the runtime will not call opendir/readdir from the startup code.
>     We shall see...
> 
> Next?

Next please try the latest trunk, where I tried to fix this.

Thanks.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    Next please try the latest trunk, where I tried to fix this.

    Thanks.

Built successfully.

Re: windows build failure

[Sean Sieger]

C:\trunk\src\emacs -Q c*.c

Gives the correct result.



Eli Zaretskii <eliz@gnu.org> writes:

    I tried to fix this problem in trunk revision 114637.  If you (or
    someone else who would like to move to the new MinGW runtime) have
    time, please re-test with v4.0 of the MinGW runtime.

    Please also try the various time-related functions, such as
    decode-time, encode-time, format-time-string, and
    current-time-string.  This is because MinGW32 runtime 4.0 also moved
    to using a 64-bit time_t type by default, which according to my
    testing screws up Emacs, especially if it was built on Windows 7 and
    then run on XP.  So for now, I forced the MinGW32 headers to use a
    32-bit time_t type.  This needs to be thoroughly tested, though.

    Thanks.

Sorry, how to `try' decode-time, encode-time, format-time-string, and
current-time-string?  I am reading *Help* on each ...

    > At the time, I tried to convince the MinGW developers not to do this,
    > here:
    >
    >   http://sourceforge.net/mailarchive/message.php?msg_id=29278605
    >   http://sourceforge.net/mailarchive/message.php?msg_id=30712991
    >   http://sourceforge.net/mailarchive/message.php?msg_id=30715094
    >   http://sourceforge.net/mailarchive/message.php?msg_id=30854291
    >
    > Evidently, I failed completely to convince them, as the incompatible
    > runtime went to print regardless, and the problems will now begin
    > unfolding before our eyes...

    Well, it turns out the MinGW developers might be listening after all,
    at least to some of the arguments: I'm promised that the next release
    of the runtime will not call opendir/readdir from the startup code.
    We shall see...

Thank you, Eli.

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Mon, 14 Oct 2013 14:02:56 -0400
> Cc: eliz@gnu.org
> 
> 
> C:\trunk\src\emacs -Q c*.c
> 
> Gives the correct result.

Great, thanks for testing.

>     Please also try the various time-related functions, such as
>     decode-time, encode-time, format-time-string, and
>     current-time-string.  This is because MinGW32 runtime 4.0 also moved
>     to using a 64-bit time_t type by default, which according to my
>     testing screws up Emacs, especially if it was built on Windows 7 and
>     then run on XP.  So for now, I forced the MinGW32 headers to use a
>     32-bit time_t type.  This needs to be thoroughly tested, though.
> 
>     Thanks.
> 
> Sorry, how to `try' decode-time, encode-time, format-time-string, and
> current-time-string?  I am reading *Help* on each ...

current-time-string is trivial: just call it, and see that the value
is reasonable.

format-time-string is not much harder, see its doc string.

decode-time can be tested by passing it what current-time returns, and
also the time-related info from file-attributes.

encode-time can be tested by passing it the result of decode-time.

In each case, please compare with the results of some older binary of
Emacs, as the differences could be subtle.

Thanks.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    current-time-string is trivial: just call it, and see that the value
    is reasonable.

GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-10-14 on 3249CTO:

(current-time-string) -> "Mon Oct 14 14:46:48 2013"

    format-time-string is not much harder, see its doc string.

(format-time-string "%Y%m%d %T") -> "20131014 14:58:43"

    decode-time can be tested by passing it what current-time returns, and
    also the time-related info from file-attributes.

(current-time) -> (21084 15790 948000 0)

How to use that with:

(decode-time)?

    encode-time can be tested by passing it the result of decode-time.

    In each case, please compare with the results of some older binary of
    Emacs, as the differences could be subtle.

GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-10-09 on 3249CTO:

(current-time-string) -> "Mon Oct 14 15:00:29 2013"
(format-time-string "%Y%m%d %T") -> "20131014 15:00:35"
(current-time) -> (21084 16293 20000 0)

    Thanks.

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Mon, 14 Oct 2013 15:06:40 -0400
> 
>     decode-time can be tested by passing it what current-time returns, and
>     also the time-related info from file-attributes.
> 
> (current-time) -> (21084 15790 948000 0)
> 
> How to use that with:
> 
> (decode-time)?

Like this:

   (decode-time (current-time))

>     In each case, please compare with the results of some older binary of
>     Emacs, as the differences could be subtle.
> 
> GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-10-09 on 3249CTO:
> 
> (current-time-string) -> "Mon Oct 14 15:00:29 2013"
> (format-time-string "%Y%m%d %T") -> "20131014 15:00:35"
> (current-time) -> (21084 16293 20000 0)

Results look reasonable, thanks.  It seems WSL 4.0 is a go.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    > From: Sean Sieger <sean.sieger@gmail.com>
    > Date: Mon, 14 Oct 2013 15:06:40 -0400
    > 
    >     decode-time can be tested by passing it what current-time returns, and
    >     also the time-related info from file-attributes.
    > 
    > (current-time) -> (21084 15790 948000 0)
    > 
    > How to use that with:
    > 
    > (decode-time)?

    Like this:

       (decode-time (current-time))

(decode-time (current-time)) -> (28 17 15 14 10 2013 1 t -14400)

and GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-10-09 on 3249CTO:

(decode-time (current-time)) -> (6 19 15 14 10 2013 1 t -14400)

    >     In each case, please compare with the results of some older binary of
    >     Emacs, as the differences could be subtle.
    > 
    > GNU Emacs 24.3.50.1 (i686-pc-mingw32) of 2013-10-09 on 3249CTO:
    > 
    > (current-time-string) -> "Mon Oct 14 15:00:29 2013"
    > (format-time-string "%Y%m%d %T") -> "20131014 15:00:35"
    > (current-time) -> (21084 16293 20000 0)

    Results look reasonable, thanks.  It seems WSL 4.0 is a go.

Oh, good.  I want to get to Chinatown to get the food, bye ...

windows build failure

[Sean Sieger]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

In file included from w32.c:33:0:
../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict' was here
make[3]: *** [oo-spd/i386/w32.o] Error 1
make[3]: Leaving directory `c:/trunk/src'
make[2]: *** [bootstrap-temacs-CMD] Error 2
make[2]: Leaving directory `c:/trunk/src'
make[1]: *** [bootstrap-temacs] Error 2
make[1]: Leaving directory `c:/trunk/src'
make: *** [bootstrap-gmake] Error 2

[-- Attachment #2: Type: text/html, Size: 618 bytes --]

Re: windows build failure

[Eli Zaretskii]

> Date: Sun, 26 May 2013 16:29:36 -0400
> From: Sean Sieger <sean.sieger@gmail.com>
> 
> In file included from w32.c:33:0:
> ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
> ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict' was here
> make[3]: *** [oo-spd/i386/w32.o] Error 1
> make[3]: Leaving directory `c:/trunk/src'
> make[2]: *** [bootstrap-temacs-CMD] Error 2
> make[2]: Leaving directory `c:/trunk/src'
> make[1]: *** [bootstrap-temacs] Error 2
> make[1]: Leaving directory `c:/trunk/src'
> make: *** [bootstrap-gmake] Error 2

Is this with today's bzr?  If so, what version of GCC is this, and
what does the macro-expanded nt/inc/sys/time.h look like?

I don't get this error.  Emacs builds for me on 2 different machines
with 2 different GCC versions.

Btw, I urge you to switch to the Posix build method, described in
nt/INSTALL.MSYS.

Re: windows build failure

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, I urge you to switch to the Posix build method, described in
> nt/INSTALL.MSYS.

Eli, do you have on mind to deprecate the Windows makefiles on a near
future? (~1 year or so).

That would imply deprecating the support for MSVC as well, right?

Re: windows build failure

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 27 May 2013 20:07:34 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, I urge you to switch to the Posix build method, described in
> > nt/INSTALL.MSYS.
> 
> Eli, do you have on mind to deprecate the Windows makefiles on a near
> future? (~1 year or so).

They are already deprecated, I announced that when I merged the Posix
build changes into the trunk, see

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00387.html

Perhaps you were asking whether makefile.w32-in files will be deleted.
I don't plan to do that, I think we better let them bitrot into
oblivion.  That would allow people to migrate in their own time.

> That would imply deprecating the support for MSVC as well, right?

Yes.  With at least 3 different distributions of GCC for Windows,
there doesn't seem to be a compelling reason to keep the MSVC support
alive, especially since doing so requires non-trivial efforts with
every new MSVC release.

What I'd like to do next in this department is make sure Emacs can be
built as a 64-bit executable using MinGW64 and the new Posix build
procedure.  People who have MinGW64 installed are encouraged to try
that and report any problems they have.

Thanks.

Re: windows build failure

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

Thanks for the detailed explanation. I'll migrate my build to MSYS/MinGW
then.

windows build failure

[Sean Sieger]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

On Monday, May 27, 2013, Eli Zaretskii wrote:

Btw, I urge you to switch to the Posix build method, described in
> nt/INSTALL.MSYS.
>

Will do.  Thank you for your time, Eli.

[-- Attachment #2: Type: text/html, Size: 372 bytes --]

Re: windows build failure

[Eli Zaretskii]

> Date: Tue, 28 May 2013 14:19:34 -0400
> From: Sean Sieger <sean.sieger@gmail.com>
> 
> Btw, I urge you to switch to the Posix build method, described in
> > nt/INSTALL.MSYS.
> >
> 
> Will do.  Thank you for your time, Eli.

I'd still like to know what broke your build.  Can you answer my
questions nonetheless, please?

Re: windows build failure

[rzl24ozi]

Sean Sieger <sean.sieger@gmail.com> writes:
> In file included from w32.c:33:0:
> ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
> ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict'
> was here
> make[3]: *** [oo-spd/i386/w32.o] Error 1
    :

When I try to build with non-Posix build method (run configure.bat and
make bootstrap under nt/ directory), got same error.

gcc version is TDM-GCC 4.7.1 32bit (http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.7.1-2.exe/download).

It looks like that 'restrict' in the prototype of gettimeofday() is
considered as variable name.

Macro-expanded nt/inc/sys/time.h look like as below.

	:
# 33 "w32.c" 2
# 1 "../nt/inc/sys/time.h" 1
# 16 "../nt/inc/sys/time.h"
struct timeval
{
  long tv_sec;
  long tv_usec;
};
# 31 "../nt/inc/sys/time.h"
struct timezone
{
  int tz_minuteswest;
  int tz_dsttime;
};





int gettimeofday (struct timeval *restrict, struct timezone *restrict);




struct itimerval
{
  struct timeval it_interval;
  struct timeval it_value;
};

int getitimer (int, struct itimerval *);
int setitimer (int, struct itimerval *, struct itimerval *);
# 34 "w32.c" 2
	:

Re: windows build failure

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Wed, 29 May 2013 22:15:58 +0900
> 
> Sean Sieger <sean.sieger@gmail.com> writes:
> > In file included from w32.c:33:0:
> > ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
> > ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict'
> > was here
> > make[3]: *** [oo-spd/i386/w32.o] Error 1
>     :
> 
> When I try to build with non-Posix build method (run configure.bat and
> make bootstrap under nt/ directory), got same error.
> 
> gcc version is TDM-GCC 4.7.1 32bit (http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.7.1-2.exe/download).

I built that version with GCC 4.7.2 from mingw.org, and didn't get the
problem.

> It looks like that 'restrict' in the prototype of gettimeofday() is
> considered as variable name.

That part is clear from the error message.  What is less clear is why
does that happen.  'restrict' is a keyword in C, so unless the
compiler has a bug, I don't understand why it barfs.  Maybe I'm
missing something here.

If you type this:

  cpp -dM < nul | fgrep restrict

what do you see?

Re: windows build failure

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> When I try to build with non-Posix build method (run configure.bat and
>> make bootstrap under nt/ directory), got same error.
>> 
>> gcc version is TDM-GCC 4.7.1 32bit (http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm-gcc-4.7.1-2.exe/download).
>
> I built that version with GCC 4.7.2 from mingw.org, and didn't get the
> problem.

Two days ago I tried the autotools-based build method with a fresh MSYS
install + MinGW-w64 4.7.2 (32 bits) and it complained with redefinitions
of some time-related functions. Then tried with MinGW's gcc 4.6.? and it
worked fine.

Maybe TDM is using the MinGW-w64 headers?

BTW, I had to install msys-coreutils-ext package with mingw-get for
avoiding hundreds of messages about non-existing chown executable while
on `make install'.

Apart from that and ignoring the big fat MSYS dependency, using the
autotools build on Windows was smooth enough. Thank you.

Re: windows build failure

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 29 May 2013 17:50:02 +0200
> 
> Two days ago I tried the autotools-based build method with a fresh MSYS
> install + MinGW-w64 4.7.2 (32 bits) and it complained with redefinitions
> of some time-related functions. Then tried with MinGW's gcc 4.6.? and it
> worked fine.

Please always report any such problems.  Otherwise, we stand no chance
of cleaning up the MSYS build with all the available toolchains.

> Maybe TDM is using the MinGW-w64 headers?

Maybe.  But the problem reported here was not with time functions, it
was with 'restrict' keyword that somehow is not interpreted as a
keyword.

> BTW, I had to install msys-coreutils-ext package with mingw-get for
> avoiding hundreds of messages about non-existing chown executable while
> on `make install'.

Yes, all the MSYS packages on the "Base" page should be installed in
full, to have a fully functional MSYS installation.

> Apart from that and ignoring the big fat MSYS dependency, using the
> autotools build on Windows was smooth enough. Thank you.

Thanks for trying it.

Re: windows build failure

[Paul Eggert]

On 05/29/13 08:21, Eli Zaretskii wrote:
> 'restrict' is a keyword in C, so unless the
> compiler has a bug

... or unless the compiler is operating in pre-C99 mode,
which is the default even with GCC 4.8.0.  The 'restrict'
keyword was introduced in C99.  'configure'
should be figuring this out, and adding the option
-std=gnu11 or whatever, but evidently this isn't working
for your correspondents.  Possibly the .h file is
being configured as if C99 were supported, but the compiler
itself is running in pre-C99 mode.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 29 May 2013 10:02:40 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 05/29/13 08:21, Eli Zaretskii wrote:
> > 'restrict' is a keyword in C, so unless the
> > compiler has a bug
> 
> ... or unless the compiler is operating in pre-C99 mode,
> which is the default even with GCC 4.8.0.  The 'restrict'
> keyword was introduced in C99.  'configure'
> should be figuring this out, and adding the option
> -std=gnu11 or whatever, but evidently this isn't working
> for your correspondents.  Possibly the .h file is
> being configured as if C99 were supported, but the compiler
> itself is running in pre-C99 mode.

What could cause such a discrepancy, when the configure script runs
the same compiler that is used in compilation?

Also, I see that the configure script puts -std=gnu99 on the GCC
command line, which should fix this, right?

Re: windows build failure

[Paul Eggert]

On 05/29/13 10:20, Eli Zaretskii wrote:
> the configure script puts -std=gnu99 on the GCC
> command line, which should fix this, right?

Yes, that's the idea.  Possibly the appropriate
'make' variable is not being used in a makefile.in
somewhere, though; that might explain the problem.
Or perhaps someone is invoking 'make' by hand and
is overriding CC or CFLAGS, and is forgetting to
include -std=gnu99 in the right spot.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 29 May 2013 11:55:26 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 05/29/13 10:20, Eli Zaretskii wrote:
> > the configure script puts -std=gnu99 on the GCC
> > command line, which should fix this, right?
> 
> Yes, that's the idea.  Possibly the appropriate
> 'make' variable is not being used in a makefile.in
> somewhere, though; that might explain the problem.
> Or perhaps someone is invoking 'make' by hand and
> is overriding CC or CFLAGS, and is forgetting to
> include -std=gnu99 in the right spot.

If we do this somewhere (e.g., in nt/config.nt):

 #define restrict __restrict

would this solve the problem even when -std=gnu99 is not in use?

Re: windows build failure

[Paul Eggert]

On 05/29/13 13:28, Eli Zaretskii wrote:
> If we do this somewhere (e.g., in nt/config.nt):
> 
>  #define restrict __restrict
> 
> would this solve the problem even when -std=gnu99 is not in use?

It might, yes.  But it's probably better not to.

If 'configure' is using different CFLAGS than 'make' is using,
there are likely other screwups, some of which could well cause
subtle runtime failures.  It could well be a good thing that
the messed-up build is failing so reliably.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 29 May 2013 14:27:28 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 05/29/13 13:28, Eli Zaretskii wrote:
> > If we do this somewhere (e.g., in nt/config.nt):
> > 
> >  #define restrict __restrict
> > 
> > would this solve the problem even when -std=gnu99 is not in use?
> 
> It might, yes.  But it's probably better not to.
> 
> If 'configure' is using different CFLAGS than 'make' is using,
> there are likely other screwups, some of which could well cause
> subtle runtime failures.  It could well be a good thing that
> the messed-up build is failing so reliably.

This problem was reported for the build that does not use the Posix
configure script, but the old Windows makefile.w32-in files.  Those do
not probe the compiler like the configure script does, and they use
-std=gnu99 only in the non-optimized build.

So I think using __restrict is the right cure for that situation, and
it should be good enough, since that way of building is deprecated.

Thanks.

Re: windows build failure

[rzl24ozi]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Maybe TDM is using the MinGW-w64 headers?

TDM (32bit) is not using MinGW64 headers. TDM64 is using it.

Eli Zaretskii <eliz@gnu.org> writes:
> If you type this:
>
>   cpp -dM < nul | fgrep restrict
>
> what do you see?

I see no output.

I write:
> When I try to build with non-Posix build method (run configure.bat and
> make bootstrap under nt/ directory), got same error.

"-std=gnu99" is not used when configured by nt/configure.bat.

When I try make bootstrap CC="gcc -std=gnu99", it seems that this problem
is solved.

Re: windows build failure

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Date: Thu, 30 May 2013 08:35:23 +0900
> 
> > When I try to build with non-Posix build method (run configure.bat and
> > make bootstrap under nt/ directory), got same error.
> 
> "-std=gnu99" is not used when configured by nt/configure.bat.
> 
> When I try make bootstrap CC="gcc -std=gnu99", it seems that this problem
> is solved.

If you edit this line in nt/config.nt:

#undef restrict

to say this instead:

#define restrict __restrict

and then re-configure and rebuild, does the problem go away even
without using -std=gnu99?

Re: windows build failure

[rzl24ozi]

Eli Zaretskii <eliz@gnu.org> writes:
> If you edit this line in nt/config.nt:
>
> #undef restrict
>
> to say this instead:
>
> #define restrict __restrict
>
> and then re-configure and rebuild, does the problem go away even
> without using -std=gnu99?

I try it but still got error because w32.c include config.h after sys/time.h.

Re: windows build failure

[Eli Zaretskii]

> From: rzl24ozi@gmail.com
> Cc: emacs-devel@gnu.org
> Date: Fri, 31 May 2013 04:38:20 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > If you edit this line in nt/config.nt:
> >
> > #undef restrict
> >
> > to say this instead:
> >
> > #define restrict __restrict
> >
> > and then re-configure and rebuild, does the problem go away even
> > without using -std=gnu99?
> 
> I try it but still got error because w32.c include config.h after sys/time.h.

Right, I forgot about that.

Please try with the latest trunk.

Re: windows build failure

[cg]

On 5/28/2013 12:36 AM, Eli Zaretskii wrote:
>> Date: Sun, 26 May 2013 16:29:36 -0400
>> From: Sean Sieger <sean.sieger@gmail.com>
>>
>> In file included from w32.c:33:0:
>> ../nt/inc/sys/time.h:41:62: error: conflicting types for 'restrict'
>> ../nt/inc/sys/time.h:41:35: note: previous definition of 'restrict' was here
>> make[3]: *** [oo-spd/i386/w32.o] Error 1
>> make[3]: Leaving directory `c:/trunk/src'
>> make[2]: *** [bootstrap-temacs-CMD] Error 2
>> make[2]: Leaving directory `c:/trunk/src'
>> make[1]: *** [bootstrap-temacs] Error 2
>> make[1]: Leaving directory `c:/trunk/src'
>> make: *** [bootstrap-gmake] Error 2
>
> Is this with today's bzr?  If so, what version of GCC is this, and
> what does the macro-expanded nt/inc/sys/time.h look like?
>
> I don't get this error.  Emacs builds for me on 2 different machines
> with 2 different GCC versions.
>

I got this compile error too, gcc version is 4.6.0 downloaded from
sourceforge.net.

The problem is gettimeofday (in time.h) has two arguments with
the same name 'restrict':

int gettimeofday (struct timeval *restrict, struct timezone *restrict);

just rename one of them, the error will be gone:

int gettimeofday (struct timeval *restrict, struct timezone *restrict2);

I don't know what C spec says about it.
--
cg

Re: windows build failure

[Eli Zaretskii]

> From: cg <chengang31@gmail.com>
> Date: Thu, 30 May 2013 00:06:56 +0800
> 
> The problem is gettimeofday (in time.h) has two arguments with
> the same name 'restrict':
> 
> int gettimeofday (struct timeval *restrict, struct timezone *restrict);

'restrict' is a keyword, not a variable.  Like 'static' or 'volatile'.

Windows build failure

[Dani Moncayo]

Hi,

With the current trunk (bzr revno 109266), I get this error when
trying to build the Windows binaries (mingw32-make bootstrap):

[...]
gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -fno-crossjumping
-I../../libs/libiconv-1.14-2-mingw32-dev/i
nclude -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
-I../../libs/giflib-4.1.4-1/include -I../.
./emacs/libs/gnutls-3.0.16/include -I../../libs/jpeg-6b-4/include
-I../../libs/libpng-1.4.10 -I../..
/libs/libxpm-3.5.8/include -I../../libs/libxpm-3.5.8/src
-I../../libs/tiff-3.8.2-1/include -I../../l
ibs/zlib-1.2.6 -I. -I../nt/inc -I../src -o oo/i386/dtotimespec.o dtotimespec.c
mingw32-make -w getopt_.h-SH
[Please ignore a syntax error on the next line - it is intentional]
/usr/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/usr/bin/sh: -c: line 1: syntax error: unexpected end of file
mingw32-make[2]: Entering directory `C:/emacs/trunk/lib'
getopt.in.h or ../build-aux/snippet/arg-nonnull.h is newer than getopt_.h.
Run "gmake getopt_h" in the lib/ subdirectory.
You will need GNU Sed to be installed.
exit -1
mingw32-make[2]: *** [getopt_.h-SH] Error 255
mingw32-make[2]: Leaving directory `C:/emacs/trunk/lib'
mingw32-make[1]: *** [getopt_.h] Error 2
mingw32-make[1]: Leaving directory `C:/emacs/trunk/lib'
mingw32-make: *** [bootstrap-gmake] Error 2


-- 
Dani Moncayo

Re: Windows build failure

[Dani Moncayo]

On Sun, Jul 29, 2012 at 6:40 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> Hi,
>
> With the current trunk (bzr revno 109266), I get this error when
> trying to build the Windows binaries (mingw32-make bootstrap):
>

I've deleted the build-aux directory, and re-started the process.  The
problem seem solved.  Sorry.

-- 
Dani Moncayo

windows build failure

[Sean Sieger]

gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -DENABLE_CHECKING -DXASSERTS -fno-crossju
mping  -Ic:/imagesupport/include -DHAVE_CONFIG_H=1 -I. -I../nt/inc -I../src -o o
o/i386/md5.o md5.c
rm oo/i386/libgnu.a
rm: cannot remove `oo/i386/libgnu.a': No such file or directory
make[1]: [oo/i386/libgnu.a] Error 1 (ignored)
ar -rsc oo/i386/libgnu.a oo/i386/dtoastr.o oo/i386/getopt.o oo/i386/getopt1.o oo
/i386/strftime.o oo/i386/time_r.o oo/i386/md5.o
make[1]: Leaving directory `c:/emacs-24.0.50/lib'
make   -C ../src bootstrap
make[1]: Entering directory `c:/emacs-24.0.50/src'
make -w  temacs CFLAGS="-I. -c -gdwarf-2 -g3  -DEMACSDEBUG -DENABLE_CHECKING -DX
ASSERTS -fno-crossjumping  -Ic:/imagesupport/include -Demacs=1 -DHAVE_CONFIG_H -
I../lib -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000"
make[2]: Entering directory `c:/emacs-24.0.50/src'
mkdir "oo"
mkdir "oo/i386"
echo oo/i386 > stamp_BLD
make[2]: *** No rule to make target `filemode.c', needed by `gl-stamp'.  Stop.
make[2]: Leaving directory `c:/emacs-24.0.50/src'
make[1]: *** [bootstrap-temacs] Error 2
make[1]: Leaving directory `c:/emacs-24.0.50/src'
make: *** [bootstrap-gmake] Error 2

Re: windows build failure

[Sean Sieger]

Shoot.  Sorry, you knew that.

Re: windows build failure

[Christoph]

On 2/21/2011 12:37 PM, Sean Sieger wrote:

> make[2]: *** No rule to make target `filemode.c', needed by `gl-stamp'.  Stop.
> make[2]: Leaving directory `c:/emacs-24.0.50/src'
> make[1]: *** [bootstrap-temacs] Error 2
> make[1]: Leaving directory `c:/emacs-24.0.50/src'
> make: *** [bootstrap-gmake] Error 2

A fix is in the works.

Re: windows build failure

[Paul Eggert]

On 02/21/2011 11:37 AM, Sean Sieger wrote:

> make[2]: *** No rule to make target `filemode.c', needed by `gl-stamp'.  Stop.

Yes, that's due to the filemode change installed a few hours ago; see
<http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00935.html>
and the parent thread.  As discussed in that thread, the Windows builds
should need minor tweaking and that should happen soon.

Re: windows build failure

[Eli Zaretskii]

> Date: Mon, 21 Feb 2011 11:48:51 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 02/21/2011 11:37 AM, Sean Sieger wrote:
> 
> > make[2]: *** No rule to make target `filemode.c', needed by `gl-stamp'.  Stop.
> 
> Yes, that's due to the filemode change installed a few hours ago; see
> <http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00935.html>
> and the parent thread.  As discussed in that thread, the Windows builds
> should need minor tweaking and that should happen soon.

Done (revision 103375).

Re: windows build failure

[Lennart Borgman]

On Mon, Feb 21, 2011 at 9:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 21 Feb 2011 11:48:51 -0800
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Cc: emacs-devel@gnu.org
>>
>> On 02/21/2011 11:37 AM, Sean Sieger wrote:
>>
>> > make[2]: *** No rule to make target `filemode.c', needed by `gl-stamp'.  Stop.
>>
>> Yes, that's due to the filemode change installed a few hours ago; see
>> <http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00935.html>
>> and the parent thread.  As discussed in that thread, the Windows builds
>> should need minor tweaking and that should happen soon.
>
> Done (revision 103375).


Thanks Eli.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    Done (revision 103375).

Great.  Built successfully.

Re: windows build failure

[Eli Zaretskii]

> Date: Mon, 21 Feb 2011 11:48:51 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 02/21/2011 11:37 AM, Sean Sieger wrote:
> 
> > make[2]: *** No rule to make target `filemode.c', needed by `gl-stamp'.  Stop.
> 
> Yes, that's due to the filemode change installed a few hours ago; see
> <http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00935.html>
> and the parent thread.  As discussed in that thread, the Windows builds
> should need minor tweaking and that should happen soon.

Btw, one fallout of the filemode.c import is that now all platforms
have S_IFLNK defined (by virtue of lib/sys_stat.h), so the remapping
of lstat to stat on fileio.c and dired.c is no longer needed, and can
be deleted.  Unless I'm missing something, that is.

Re: windows build failure

[Paul Eggert]

On 02/21/2011 12:37 PM, Eli Zaretskii wrote:

> one fallout of the filemode.c import is that now all platforms
> have S_IFLNK defined (by virtue of lib/sys_stat.h), so the remapping
> of lstat to stat on fileio.c and dired.c is no longer needed, and can
> be deleted.  Unless I'm missing something, that is.

Thanks for mentioning that.  I committed simplifications along those
lines to the trunk as revision 103380.  I don't expect
this to affects Windows builds, as the only new symbol in config.in
is HAVE_LSTAT and Windows doesn't have lstat.

One minor thing: Gnulib's <sys/stat.h> substitute guarantees
the existence of S_ISLNK, but not S_IFLNK.

Re: windows build failure

[Eli Zaretskii]

> Date: Mon, 21 Feb 2011 18:09:07 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 02/21/2011 12:37 PM, Eli Zaretskii wrote:
> 
> > one fallout of the filemode.c import is that now all platforms
> > have S_IFLNK defined (by virtue of lib/sys_stat.h), so the remapping
> > of lstat to stat on fileio.c and dired.c is no longer needed, and can
> > be deleted.  Unless I'm missing something, that is.
> 
> Thanks for mentioning that.  I committed simplifications along those
> lines to the trunk as revision 103380.

Thanks.

> One minor thing: Gnulib's <sys/stat.h> substitute guarantees
> the existence of S_ISLNK, but not S_IFLNK.

Yes, that was a typo on my part (to my defense, I would point out the
time when I wrote that ;-).

Please note that the portions of the code that need symlinks (and the
corresponding library functions) be supported by the host are
currently guarded by "#ifdef S_IFLNK", which the Windows and DOS
platforms do not define.  OTOH, S_ISLNK _is_ defined on all
platforms.  This makes me uneasy, because I've never seen a situation
with such a mismatch.  Normally, if S_IFLNK is defined, so is S_ISLNK,
and vice versa.  (I realize that this may have been otherwise in the
past, but I don't think any of those older systems are still in use,
or supported by Emacs.)

IOW, we use this mismatch as a trick to get filemode.c compile,
without breaking non-Posix platforms which don't really have symlinks.

I'm worried that someone unaware of this trick might assume that
S_IFLNK is also available, and will write code that will subtly break
non-Posix platforms.

If I'm not the only one who feels uneasy about this mismatch, we may
wish doing something about it.

(Personally, I wonder why gnulib removed the "#ifdef S_ISLNK" guards
in the first place: the artificial definition to zero in sys_stat.in.h
is only fine if one ignores the de-facto practice of testing for
S_IFLNK or S_ISLNK to guard code elsewhere that cannot be compiled or
run on platforms without symlinks.  So it looks like an anti-social
decision on the part of gnulib, since it does support MinGW.)

Re: windows build failure

[Paul Eggert]

On 02/22/2011 12:57 AM, Eli Zaretskii wrote:
>  the artificial definition to zero in sys_stat.in.h
> is only fine if one ignores the de-facto practice of testing for
> S_IFLNK or S_ISLNK to guard code elsewhere that cannot be compiled or
> run on platforms without symlinks

No, the idea is that normal code should not use #ifdef S_IFLNK.
It should instead use "if (S_ISLNK (...)) ...".
On hosts that don't have symbolic links, this "if"
gets optimized away to nothing, so it's just as fast
as the #ifdef.

Using plain "if" tends to lead to code that is
easier to maintain than using "#ifdef", in cases
like these.  Among other things, trivial typos
inside the then-part are detected even when compiling
on platforms that lack the feature in question.

Large chunks of GNU code have been written using this style,
in programs such as coreutils, and it typically works well.

Re: windows build failure

[Eli Zaretskii]

> Date: Tue, 22 Feb 2011 01:40:24 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 02/22/2011 12:57 AM, Eli Zaretskii wrote:
> >  the artificial definition to zero in sys_stat.in.h
> > is only fine if one ignores the de-facto practice of testing for
> > S_IFLNK or S_ISLNK to guard code elsewhere that cannot be compiled or
> > run on platforms without symlinks
> 
> No, the idea is that normal code should not use #ifdef S_IFLNK.

Well, "normal code" in Emacs does.  We have 5 such places at this
time, if I didn't miss any.

> It should instead use "if (S_ISLNK (...)) ...".
> On hosts that don't have symbolic links, this "if"
> gets optimized away to nothing, so it's just as fast
> as the #ifdef.

How can we use this idea, when the code in question calls functions
like `symlink' or `readlink", which don't exist on hosts that don't
support symlinks?  This won't link, unless we do something else in
addition.  If we want to go your way, we need to decide how to resolve
this difficulty (and do it in a way that won't become broken when you
resync with gnulib an hour or a day or a year from now ;-).

> Using plain "if" tends to lead to code that is easier to maintain
> than using "#ifdef", in cases like these.

I have no issues with using "if", but we must decide how to do that
without breaking compilation/link.

Once compilation and link work, we will also need to carefully review
the affected code, because its logic might subtly assume something
about the underlying platforms' behavior wrt symlinks, and that logic
might do The Wrong Thing when applied to hosts without symlinks, in
the parts that are common to "if" and its "else".

> Large chunks of GNU code have been written using this style,
> in programs such as coreutils, and it typically works well.

For some value of "well".  I really don't want to begin griping about
the MinGW port of Coreutils on Windows (that's OT here, anyway), but
for starters, it is linked against a ported glibc, which includes a
bastard semi-broken emulation of symlinks.  So I'm not sure anyone has
ever tested this approach in practice, at least not in Coreutils.

Again, I'm not against going the "if" path, I just wanted to (a) point
out the issue and hear from the relevant parties what, if anything,
they prefer to do about that, and (b) make sure we all understand that
fixing it cleanly is not a trivial job (but not rocket science,
either, of course).  Once the decision is made, I will be more than
willing to contribute to this effort.

Re: windows build failure

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 6337 bytes --]

On 02/22/2011 02:49 AM, Eli Zaretskii wrote:
>> From: Paul Eggert<eggert@cs.ucla.edu>
>> No, the idea is that normal code should not use #ifdef S_IFLNK.
>
> Well, "normal code" in Emacs does.  We have 5 such places at this
> time, if I didn't miss any.

These #ifdef uses are problematic, and should be removed.  For example,
on a GNU system (make-symbolic-link A B) signals a file-already-exists
error if B already exists, but if I'm reading the code correctly this
does not happen on a system lacking symlinks.  It's better to remove
unnecessary discrepancies like this.

> How can we use this idea, when the code in question calls functions
> like `symlink' or `readlink", which don't exist on hosts that don't
> support symlinks?

Use substitutes for symlink and readlink that always fail.
That's easy and works well in practice.

> Once compilation and link work, we will also need to carefully review
> the affected code,

The affected code is fairly small.  A complete patch for your review
is below; it removes the problematic #ifdefs and thereby
shrinks the main Emacs source code by about 25 lines.
(As usual, I'm attaching the full patch, which includes files
autogenerated from gnulib.)

The new symbols in config.in that you may have to look at for Windows
include FILE_SYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX,
FILE_SYSTEM_BACKSLASH_IS_FILE_NAME_SEPARATOR,
FILE_SYSTEM_DRIVE_PREFIX_CAN_BE_RELATIVE, HAVE_READLINK, HAVE_SYMLINK,
REPLACE_FUNC_STAT_DIR, and REPLACE_FUNC_STAT_FILE.

This patch also works around some other portability issues with
symlinks, with respect to file names that end with "/".  This
doesn't affect Windows, but we might as well fix those too,
since we get them for essentially zero programming cost here.

[ChangeLog]
Work around some portability problems with symlinks.
* Makefile.in (GNULIB_MODULES): Add lstat, readlink, symlink.
* configure.in (lstat, HAVE_LSTAT): Remove special hack.
* lib/lstat.c, lib/readlink.c, lib/stat.c, lib/symlink.c:
* m4/dos.m4, m4/lstat.m4, m4/readlink.m4, m4/stat.m4, m4/symlink.m4:
New files, automatically generated from gnulib.
* aclocal.m4, configure, lib/Makefile.in, lib/gnulib.mk:
* lib/stdlib.in.h, m4/gl-comp.m4, m4/stdlib_h.m4: Regenerate.

2011-02-22  Paul Eggert  <eggert@cs.ucla.edu>
[src/ChangeLog]
Work around some portability problems with symlinks.
* fileio.c (Frename_file, Fmake_symbolic_link, Ffile_symlink_p):
Simplify the code by assuming that the readlink and symlink calls
exist, even if they always fail on this host.
(Ffile_readable_p): Likewise, for fifos.
* config.in: Regenerate.
=== modified file 'Makefile.in'
--- Makefile.in	2011-02-22 01:55:20 +0000
+++ Makefile.in	2011-02-22 18:48:53 +0000
@@ -332,7 +332,7 @@
  # as per $(gnulib_srcdir)/DEPENDENCIES.
  GNULIB_MODULES = \
    crypto/md5 dtoastr filemode getloadavg getopt-gnu \
-  ignore-value mktime strftime sys_stat
+  ignore-value lstat mktime readlink strftime symlink sys_stat
  GNULIB_TOOL_FLAGS = \
   --import --no-changelog --no-vc-files --makefile-name=gnulib.mk
  sync-from-gnulib: $(gnulib_srcdir)

=== modified file 'configure.in'
--- configure.in	2011-02-22 01:55:20 +0000
+++ configure.in	2011-02-22 18:48:14 +0000
@@ -2661,15 +2661,6 @@
  gl_ASSERT_NO_GNULIB_TESTS
  gl_INIT

-# Emacs does not care about lstat's behavior on files whose names end in
-# trailing slashes, so it does not use the gnulib lstat module.
-# However, Emacs does want the "#define lstat stat" in sys/stat.h
-# when lstat does not exist, so it pretends to use the lstat module
-# even though it implements only the lstat-checking part of that module.
-AC_CHECK_FUNCS_ONCE([lstat])
-test $ac_cv_func_lstat = yes || HAVE_LSTAT=0
-gl_SYS_STAT_MODULE_INDICATOR([lstat])
-
  # UNIX98 PTYs.
  AC_CHECK_FUNCS(grantpt)


=== modified file 'src/fileio.c'
--- src/fileio.c	2011-02-22 01:55:20 +0000
+++ src/fileio.c	2011-02-22 18:39:29 +0000
@@ -2178,14 +2178,11 @@
        if (errno == EXDEV)
  	{
            int count;
-#ifdef S_IFLNK
            symlink_target = Ffile_symlink_p (file);
            if (! NILP (symlink_target))
              Fmake_symbolic_link (symlink_target, newname,
                                   NILP (ok_if_already_exists) ? Qnil : Qt);
-          else
-#endif
-	  if (!NILP (Ffile_directory_p (file)))
+	  else if (!NILP (Ffile_directory_p (file)))
  	    call4 (Qcopy_directory, file, newname, Qt, Qnil);
  	  else
  	    /* We have already prompted if it was an integer, so don't
@@ -2197,11 +2194,7 @@
  	  count = SPECPDL_INDEX ();
  	  specbind (Qdelete_by_moving_to_trash, Qnil);

-	  if (!NILP (Ffile_directory_p (file))
-#ifdef S_IFLNK
-	      && NILP (symlink_target)
-#endif
-	      )
+	  if (!NILP (Ffile_directory_p (file)) && NILP (symlink_target))
  	    call2 (Qdelete_directory, file, Qt);
  	  else
  	    Fdelete_file (file, Qnil);
@@ -2311,7 +2304,6 @@
      RETURN_UNGCPRO (call4 (handler, Qmake_symbolic_link, filename,
  			   linkname, ok_if_already_exists));

-#ifdef S_IFLNK
    encoded_filename = ENCODE_FILE (filename);
    encoded_linkname = ENCODE_FILE (linkname);

@@ -2338,12 +2330,6 @@
      }
    UNGCPRO;
    return Qnil;
-
-#else
-  UNGCPRO;
-  xsignal1 (Qfile_error, build_string ("Symbolic links are not supported"));
-
-#endif /* S_IFLNK */
  }

  \f
@@ -2482,7 +2468,7 @@
    return Qnil;
  #else /* not DOS_NT and not macintosh */
    flags = O_RDONLY;
-#if defined (S_IFIFO) && defined (O_NONBLOCK)
+#ifdef O_NONBLOCK
    /* Opening a fifo without O_NONBLOCK can wait.
       We don't want to wait.  But we don't want to mess wth O_NONBLOCK
       except in the case of a fifo, on a system which handles it.  */
@@ -2584,6 +2570,10 @@
    (Lisp_Object filename)
  {
    Lisp_Object handler;
+  char *buf;
+  int bufsize;
+  int valsize;
+  Lisp_Object val;

    CHECK_STRING (filename);
    filename = Fexpand_file_name (filename, Qnil);
@@ -2594,13 +2584,6 @@
    if (!NILP (handler))
      return call2 (handler, Qfile_symlink_p, filename);

-#ifdef S_IFLNK
-  {
-  char *buf;
-  int bufsize;
-  int valsize;
-  Lisp_Object val;
-
    filename = ENCODE_FILE (filename);

    bufsize = 50;
@@ -2635,10 +2618,6 @@
    xfree (buf);
    val = DECODE_FILE (val);
    return val;
-  }
-#else /* not S_IFLNK */
-  return Qnil;
-#endif /* not S_IFLNK */
  }

  DEFUN ("file-directory-p", Ffile_directory_p, Sfile_directory_p, 1, 1, 0,




[-- Attachment #2: emacs-symlink-diff.txt.gz --]
[-- Type: application/x-gzip, Size: 15638 bytes --]

Re: windows build failure

[Eli Zaretskii]

> Date: Tue, 22 Feb 2011 13:44:48 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> [1:text/plain Hide]
> On 02/22/2011 02:49 AM, Eli Zaretskii wrote:
> >> From: Paul Eggert<eggert@cs.ucla.edu>
> >> No, the idea is that normal code should not use #ifdef S_IFLNK.
> >
> > Well, "normal code" in Emacs does.  We have 5 such places at this
> > time, if I didn't miss any.
> 
> These #ifdef uses are problematic, and should be removed.

That was my original point, I believe.

> For example,
> on a GNU system (make-symbolic-link A B) signals a file-already-exists
> error if B already exists, but if I'm reading the code correctly this
> does not happen on a system lacking symlinks.  It's better to remove
> unnecessary discrepancies like this.

I'm not sure this particular discrepancy should be removed.  It is not
useful to bitch at the user with secondary issues when there's a
bigger issue looming.  Imagine:

  User: M-x make-symbolic-link RET foo RET bar RET
  Emacs: File bar already exists; make it a link anyway?
  User: yes RET
  Emacs: Making symbolic link: Function not implemented
  User: :-( why *&^%$#@! didn't you tell me that to begin with??

> The affected code is fairly small.  A complete patch for your review
> is below; it removes the problematic #ifdefs and thereby
> shrinks the main Emacs source code by about 25 lines.
> (As usual, I'm attaching the full patch, which includes files
> autogenerated from gnulib.)

Thanks.  However, this is too heaviweight (like always with gnulib).
If all we need is define 2 always-fail functions for w32 and for
MS-DOS, let's just do that on src/w32.c and src/msdos.c, where no one
who is interested in Posix platforms only will ever need to see or
consider them.  It will take less than 10 lines of code, and no
additional changes anywhere.

By contrast, your proposal introduces half a dozen new preprocessor
macros, replacements for 4 functions (2 of which no platforms need),
and additional configury stuff which will only be needed if someone
ever makes the Windows build of Emacs use autotools (and for now, just
increases the labor required to get these changes to work on Windows).

Also, there's an effort in Emacs maintenance to reduce the number of
preprocessor symbols used by the code, so I don't think adding more is
a good idea.

I'm particularly nervous about code that messes with `stat', for which
Emacs has its own from-ground-up implementation that already takes
care of the trailing slashes issue.  It took a lot of labor to get to
the current version, so I'd really prefer not to introduce a wrapper
that was clearly designed to call the version of `stat' in Microsoft's
runtime, which Emacs doesn't use.

An example of what could go wrong with these replacements can be seen
in this excerpt from rpl_lstat:

  +  /* This replacement file can blindly check against '/' rather than
  +     using the ISSLASH macro, because all platforms with '\\' either
  +     lack symlinks (mingw) or have working lstat (cygwin) and thus do
  +     not compile this file.  0 len should have already been filtered
  +     out above, with a failure return of ENOENT.  */
  +  len = strlen (file);
  +  if (file[len - 1] != '/' || S_ISDIR (sbuf->st_mode))
  +    return 0;

The assumption stated in the comment is wrong for DJGPP v2.04, which
is supported in the DOS build, where there's a working `symlink', but
a backslash is a valid directory separator.

More generally, Emacs has accumulated through the years fixes for many
idiosyncrasies of the MS systems.  I would prefer not to touch that by
importing external code that tries to fix the same issues in subtly
different ways.

> @@ -2311,7 +2304,6 @@
>       RETURN_UNGCPRO (call4 (handler, Qmake_symbolic_link, filename,
>   			   linkname, ok_if_already_exists));
> 
> -#ifdef S_IFLNK
>     encoded_filename = ENCODE_FILE (filename);
>     encoded_linkname = ENCODE_FILE (linkname);
> 
> @@ -2338,12 +2330,6 @@
>       }
>     UNGCPRO;
>     return Qnil;
> -
> -#else
> -  UNGCPRO;
> -  xsignal1 (Qfile_error, build_string ("Symbolic links are not supported"));
> -
> -#endif /* S_IFLNK */

I would prefer not to change the user-visible behavior here.  Even if
the target of the symlink does not exist, the current error message is
much more clear and self-explanatory than the half-cryptic
"make-symbolic-link: Function not implemented" (which function? not
implemented by whom? Emacs certainly implements make-symbolic-link, as
"C-h f" will readily show).  How about testing for ENOSYS explicitly?

And there's still the issue with emitting this error message without
calling barf_or_query_if_file_exists, see above.

Thanks.

Re: windows build failure

[Eli Zaretskii]

> Date: Wed, 23 Feb 2011 04:47:40 -0500
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I'm particularly nervous about code that messes with `stat', for which
> Emacs has its own from-ground-up implementation

That was about the w32 build only, of course.  Sorry for not saying
that explicitly in the first place.

Re: windows build failure

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 9680 bytes --]

On 02/23/2011 01:47 AM, Eli Zaretskii wrote:

> How about testing for ENOSYS explicitly?

Yes, that's easily enough done, and is in the revised patch at the end
of this message (the full patch, including regenerated files, is attached).

> If all we need is define 2 always-fail functions for w32 and for
> MS-DOS, let's just do that on src/w32.c and src/msdos.c

That sounds fine, and that can be combined with this approach, since
the w32 and DOS ports supply their own hand-built config.h files.

However, we should also work around the known bugs with lstat etc. on
non-Windows platforms, which the Gnulib code handles.  These have to
do with file names that have trailing slashes; some Unixish hosts
incorrectly treat "foo/" as a symbolic link, for example, even when
it's a directory or is nonexistent, if "foo" happens to be a symlink.

> your proposal introduces half a dozen new preprocessor macros,
> replacements for 4 functions (2 of which no platforms need), and
> additional configury stuff which will only be needed if someone ever
> makes the Windows build of Emacs use autotools

I've simplified the proposal so that it introduces into src/config.in
only the preprocessor symbols needed to work around known problems in
Unixish systems mentioned above.  The hand-built Windows ports
shouldn't need to worry about these symbols; they need only to supply
their own always-failing versions of readlink and symlink, which can
be as trivial as a couple of lines in nt/inc/sys/stat.h (e.g.,
"#define readlink(f,b,s) (errno = ENOSYS, -1)").

> Imagine:
>
>    User: M-x make-symbolic-link RET foo RET bar RET
>    Emacs: File bar already exists; make it a link anyway?
>    User: yes RET
>    Emacs: Making symbolic link: Function not implemented
>    User: :-( why *&^%$#@! didn't you tell me that to begin with??

This scenario already occurs in the mainstream code.  If I am running
Emacs on a GNU/Linux host, using files on a file server that does not
support symbolic links, I will already see behavior like that.  It's
more consistent if Emacs's behavior is similar on Windows.

> I'm particularly nervous about code that messes with `stat' ...
> I'd really prefer not to introduce a wrapper

You don't have to.  That wrapper is built only if you're running
ordinary 'configure' on a host with a buggy 'stat'.  The Windows
build doesn't run ordinary 'configure', so it shouldn't need or
build that wrapper.

> The assumption stated in the comment is wrong for DJGPP v2.04, which
> is supported in the DOS build, where there's a working `symlink', but
> a backslash is a valid directory separator.

I'll forward that to the gnulib mailing list, but as per the above
it's irrelevant to the proposed change for Emacs, since the code in
question isn't being used for Emacs.

Here's the revised patch (full version attached).

=== modified file 'ChangeLog'
--- ChangeLog	2011-02-25 07:23:41 +0000
+++ ChangeLog	2011-02-25 20:05:36 +0000
@@ -1,5 +1,11 @@
  2011-02-25  Paul Eggert  <eggert@cs.ucla.edu>
  
+	Simplify symlink portability workaround.
+	* m4/dos.m4: Remove.
+	* aclocal.m4, configure, lib/Makefile.in, lib/gnulib.mk, lib/stat.c:
+	* m4/gl-comp.m4, m4/stat.m4, src/config.in: Regenerate from gnulib.
+	* lib/dosname.h: New file, regenerated from gnulib.
+
  	* configure, lib/Makefile.in, lib/getopt_int.h, lib/gnulib.mk:
  	* lib/stdlib.in.h, m4/stdlib_h.m4: Regenerate.
  
@@ -10,6 +16,17 @@
  
  2011-02-22  Paul Eggert  <eggert@cs.ucla.edu>
  
+	Work around some portability problems with symlinks.
+	* Makefile.in (GNULIB_MODULES): Add lstat, readlink, symlink.
+	* configure.in (lstat, HAVE_LSTAT): Remove special hack.
+	* lib/lstat.c, lib/readlink.c, lib/stat.c, lib/symlink.c:
+	* m4/dos.m4, m4/lstat.m4, m4/readlink.m4, m4/stat.m4, m4/symlink.m4:
+	New files, automatically generated from gnulib.
+	* aclocal.m4, configure, lib/Makefile.in, lib/gnulib.mk:
+	* lib/stdlib.in.h, m4/gl-comp.m4, m4/stdlib_h.m4: Regenerate.
+
+2011-02-22  Paul Eggert  <eggert@cs.ucla.edu>
+
  	Assume S_ISLNK etc. work, since gnulib supports this.
  	* Makefile.in (GNULIB_MODULES): Add sys_stat.
  	* configure.in: Check for lstat and set HAVE_LSTAT=0 if not.

=== modified file 'Makefile.in'
--- Makefile.in	2011-02-22 01:55:20 +0000
+++ Makefile.in	2011-02-22 19:30:07 +0000
@@ -332,7 +332,7 @@
  # as per $(gnulib_srcdir)/DEPENDENCIES.
  GNULIB_MODULES = \
    crypto/md5 dtoastr filemode getloadavg getopt-gnu \
-  ignore-value mktime strftime sys_stat
+  ignore-value lstat mktime readlink strftime symlink sys_stat
  GNULIB_TOOL_FLAGS = \
   --import --no-changelog --no-vc-files --makefile-name=gnulib.mk
  sync-from-gnulib: $(gnulib_srcdir)

=== modified file 'configure.in'
--- configure.in	2011-02-24 04:28:17 +0000
+++ configure.in	2011-02-25 06:42:06 +0000
@@ -2661,15 +2661,6 @@
  gl_ASSERT_NO_GNULIB_TESTS
  gl_INIT
  
-# Emacs does not care about lstat's behavior on files whose names end in
-# trailing slashes, so it does not use the gnulib lstat module.
-# However, Emacs does want the "#define lstat stat" in sys/stat.h
-# when lstat does not exist, so it pretends to use the lstat module
-# even though it implements only the lstat-checking part of that module.
-AC_CHECK_FUNCS_ONCE([lstat])
-test $ac_cv_func_lstat = yes || HAVE_LSTAT=0
-gl_SYS_STAT_MODULE_INDICATOR([lstat])
-
  # UNIX98 PTYs.
  AC_CHECK_FUNCS(grantpt)
  

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-02-25 06:30:50 +0000
+++ src/ChangeLog	2011-02-25 21:20:06 +0000
@@ -1,5 +1,11 @@
  2011-02-25  Paul Eggert  <eggert@cs.ucla.edu>
  
+	Simplify symlink portability workaround.
+	* fileio.c (Fmake_symbolic_link): Treat ENOSYS specially, and
+	generate a special message for it.  Suggested by Eli Zaretskii in
+	<http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00995.html>.
+	* config.in: Regenerate.
+
  	* dired.c (Ffile_attributes): Increase size of modes from 10 to 12
  	as per recent filemodestring API change.  Reported by Jonas Öster in
  	<http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg01069.html>.
@@ -26,6 +32,13 @@
  
  2011-02-22  Paul Eggert  <eggert@cs.ucla.edu>
  
+	Work around some portability problems with symlinks.
+	* fileio.c (Frename_file, Fmake_symbolic_link, Ffile_symlink_p):
+	Simplify the code by assuming that the readlink and symlink calls
+	exist, even if they always fail on this host.
+	(Ffile_readable_p): Likewise, for fifos.
+	* config.in: Regenerate.
+
  	* dired.c (Ffile_attributes): Simplify and avoid #ifdef.
  
  2011-02-22  Wolfgang Jenkner  <wjenkner@inode.at>  (tiny change)

=== modified file 'src/fileio.c'
--- src/fileio.c	2011-02-22 01:55:20 +0000
+++ src/fileio.c	2011-02-25 21:20:06 +0000
@@ -2178,14 +2178,11 @@
        if (errno == EXDEV)
  	{
            int count;
-#ifdef S_IFLNK
            symlink_target = Ffile_symlink_p (file);
            if (! NILP (symlink_target))
              Fmake_symbolic_link (symlink_target, newname,
                                   NILP (ok_if_already_exists) ? Qnil : Qt);
-          else
-#endif
-	  if (!NILP (Ffile_directory_p (file)))
+	  else if (!NILP (Ffile_directory_p (file)))
  	    call4 (Qcopy_directory, file, newname, Qt, Qnil);
  	  else
  	    /* We have already prompted if it was an integer, so don't
@@ -2197,11 +2194,7 @@
  	  count = SPECPDL_INDEX ();
  	  specbind (Qdelete_by_moving_to_trash, Qnil);
  
-	  if (!NILP (Ffile_directory_p (file))
-#ifdef S_IFLNK
-	      && NILP (symlink_target)
-#endif
-	      )
+	  if (!NILP (Ffile_directory_p (file)) && NILP (symlink_target))
  	    call2 (Qdelete_directory, file, Qt);
  	  else
  	    Fdelete_file (file, Qnil);
@@ -2311,7 +2304,6 @@
      RETURN_UNGCPRO (call4 (handler, Qmake_symbolic_link, filename,
  			   linkname, ok_if_already_exists));
  
-#ifdef S_IFLNK
    encoded_filename = ENCODE_FILE (filename);
    encoded_linkname = ENCODE_FILE (linkname);
  
@@ -2333,17 +2325,17 @@
  	      return Qnil;
  	    }
  	}
+      if (errno == ENOSYS)
+	{
+	  UNGCPRO;
+	  xsignal1 (Qfile_error,
+		    build_string ("Symbolic links are not supported"));
+	}
  
        report_file_error ("Making symbolic link", list2 (filename, linkname));
      }
    UNGCPRO;
    return Qnil;
-
-#else
-  UNGCPRO;
-  xsignal1 (Qfile_error, build_string ("Symbolic links are not supported"));
-
-#endif /* S_IFLNK */
  }
  
  \f
@@ -2482,7 +2474,7 @@
    return Qnil;
  #else /* not DOS_NT and not macintosh */
    flags = O_RDONLY;
-#if defined (S_IFIFO) && defined (O_NONBLOCK)
+#ifdef O_NONBLOCK
    /* Opening a fifo without O_NONBLOCK can wait.
       We don't want to wait.  But we don't want to mess wth O_NONBLOCK
       except in the case of a fifo, on a system which handles it.  */
@@ -2584,6 +2576,10 @@
    (Lisp_Object filename)
  {
    Lisp_Object handler;
+  char *buf;
+  int bufsize;
+  int valsize;
+  Lisp_Object val;
  
    CHECK_STRING (filename);
    filename = Fexpand_file_name (filename, Qnil);
@@ -2594,13 +2590,6 @@
    if (!NILP (handler))
      return call2 (handler, Qfile_symlink_p, filename);
  
-#ifdef S_IFLNK
-  {
-  char *buf;
-  int bufsize;
-  int valsize;
-  Lisp_Object val;
-
    filename = ENCODE_FILE (filename);
  
    bufsize = 50;
@@ -2635,10 +2624,6 @@
    xfree (buf);
    val = DECODE_FILE (val);
    return val;
-  }
-#else /* not S_IFLNK */
-  return Qnil;
-#endif /* not S_IFLNK */
  }
  
  DEFUN ("file-directory-p", Ffile_directory_p, Sfile_directory_p, 1, 1, 0,



[-- Attachment #2: symlink-patch2.txt.gz --]
[-- Type: application/x-gzip, Size: 30751 bytes --]

windows build failure

[Sean Sieger]

gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -DENABLE_CHECKING -DXASSERTS -fno-crossju
mping  -Ic:/imagesupport/include -Demacs=1 -DHAVE_CONFIG_H -I../lib -I../nt/inc
-DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo/i386/buffer.o buffer.c
buffer.c: In function 'init_buffer_once':
buffer.c:5044: error: 'struct buffer' has no member named 'buffer_file_type'
buffer.c:5116: error: 'struct buffer' has no member named 'buffer_file_type'
buffer.c: In function 'syms_of_buffer':
buffer.c:5677: error: 'struct buffer' has no member named 'buffer_file_type'
make[2]: *** [oo/i386/buffer.o] Error 1
make[2]: Leaving directory `c:/emacs-24.0.50/src'
make[1]: *** [bootstrap-temacs] Error 2
make[1]: Leaving directory `c:/emacs-24.0.50/src'
make: *** [bootstrap-gmake] Error 2

Re: windows build failure

[Tom Tromey]

>>>>> "Sean" == Sean Sieger <sean.sieger@gmail.com> writes:

Sean> buffer.c:5044: error: 'struct buffer' has no member named 'buffer_file_type'
Sean> buffer.c:5116: error: 'struct buffer' has no member named 'buffer_file_type'
Sean> buffer.c: In function 'syms_of_buffer':
Sean> buffer.c:5677: error: 'struct buffer' has no member named 'buffer_file_type'

Please try this.
If it works for you I will check it in.

If you send `make -k' output, I can try to fix them all at once.

Tom

2011-02-14  Tom Tromey  <tromey@redhat.com>

	* buffer.c (init_buffer_once, syms_of_buffer): Use B_ in DOS_NT
	case.

=== modified file 'src/buffer.c'
--- src/buffer.c	2011-02-14 15:39:19 +0000
+++ src/buffer.c	2011-02-14 16:58:24 +0000
@@ -5041,7 +5041,7 @@
   B_ (&buffer_defaults, cursor_in_non_selected_windows) = Qt;
 
 #ifdef DOS_NT
-  buffer_defaults.buffer_file_type = Qnil; /* TEXT */
+  B_ (&buffer_defaults, buffer_file_type) = Qnil; /* TEXT */
 #endif
   B_ (&buffer_defaults, enable_multibyte_characters) = Qt;
   B_ (&buffer_defaults, buffer_file_coding_system) = Qnil;
@@ -5113,7 +5113,7 @@
   XSETFASTINT (B_ (&buffer_local_flags, abbrev_table), idx); ++idx;
   XSETFASTINT (B_ (&buffer_local_flags, display_table), idx); ++idx;
 #ifdef DOS_NT
-  XSETFASTINT (buffer_local_flags.buffer_file_type, idx);
+  XSETFASTINT (B_ (&buffer_local_flags, buffer_file_type), idx);
   /* Make this one a permanent local.  */
   buffer_permanent_local_flags[idx++] = 1;
 #endif
@@ -5674,7 +5674,7 @@
 in narrower windows.  */);
 
 #ifdef DOS_NT
-  DEFVAR_PER_BUFFER ("buffer-file-type", &current_buffer->buffer_file_type,
+  DEFVAR_PER_BUFFER ("buffer-file-type", &B_ (current_buffer, buffer_file_type),
 		     Qnil,
 		     doc: /* Non-nil if the visited file is a binary file.
 This variable is meaningful on MS-DOG and Windows NT.

Re: windows build failure

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: Mon, 14 Feb 2011 09:54:47 -0700
> Cc: emacs-devel@gnu.org
> 
> >>>>> "Sean" == Sean Sieger <sean.sieger@gmail.com> writes:
> 
> Sean> buffer.c:5044: error: 'struct buffer' has no member named 'buffer_file_type'
> Sean> buffer.c:5116: error: 'struct buffer' has no member named 'buffer_file_type'
> Sean> buffer.c: In function 'syms_of_buffer':
> Sean> buffer.c:5677: error: 'struct buffer' has no member named 'buffer_file_type'
> 
> Please try this.
> If it works for you I will check it in.

It works, but there are other problems like this.  I'm on it.

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    It works, but there are other problems like this.  I'm on it.

... there I was learning how to apply a patch.  Thanks, Eli, Tom.

Re: windows build failure

[Eli Zaretskii]

> Date: Mon, 14 Feb 2011 19:17:55 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
> 
> > From: Tom Tromey <tromey@redhat.com>
> > Date: Mon, 14 Feb 2011 09:54:47 -0700
> > Cc: emacs-devel@gnu.org
> > 
> > >>>>> "Sean" == Sean Sieger <sean.sieger@gmail.com> writes:
> > 
> > Sean> buffer.c:5044: error: 'struct buffer' has no member named 'buffer_file_type'
> > Sean> buffer.c:5116: error: 'struct buffer' has no member named 'buffer_file_type'
> > Sean> buffer.c: In function 'syms_of_buffer':
> > Sean> buffer.c:5677: error: 'struct buffer' has no member named 'buffer_file_type'
> > 
> > Please try this.
> > If it works for you I will check it in.
> 
> It works, but there are other problems like this.  I'm on it.

Should be fixed now, let me know if not.  I installed Tom's patch as
well.

Re: windows build failure

[Tom Tromey]

Eli> Should be fixed now, let me know if not.  I installed Tom's patch as
Eli> well.

Thank you.

Tom

Re: windows build failure

[Sean Sieger]

Eli Zaretskii <eliz@gnu.org> writes:

    Should be fixed now, let me know if not.  I installed Tom's patch as
    well.

Yep, built fine.

windows build failure

[Sean Sieger]

rm oo/i386/lastfile.a
rm: cannot remove `oo/i386/lastfile.a': No such file or directory
make[2]: [oo/i386/lastfile.a] Error 1 (ignored)
ar -rsc oo/i386/lastfile.a oo/i386/lastfile.o
gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -DENABLE_CHECKING -DXASSERTS -fno-crossju
mping  -Ic:/imagesupport/include -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_NT
GUI=1 -DUSE_CRT_DLL=1 -DPURESIZE=5000000 -o oo/i386/firstfile.o firstfile.c
windres -O coff --include-dir ../nt -o oo/i386/emacs.res ../nt/emacs.rc
gcc -o oo/i386/temacs.bin  -gdwarf-2 -g3    -Wl,-stack,0x00800000 -Wl,-heap,0x00
100000 -Wl,-image-base,0x01000000 -Wl,-subsystem,console -Wl,-entry,__start -Wl,
-Map,oo/i386/temacs.map oo/i386/firstfile.o oo/i386/emacs.res oo/i386/temacs0.a
oo/i386/temacs1.a oo/i386/temacs2.a oo/i386/lastfile.a -lwinmm -ladvapi32 -lgdi3
2 -lcomdlg32 -luser32 -lmpr -lshell32 -lwinspool -lole32 -lcomctl32 -lusp10
oo/i386/temacs2.a(image.o): In function `my_png_error':
c:\emacs-24.0.50\src/image.c:5547: undefined reference to `png_set_longjmp_fn'
oo/i386/temacs2.a(image.o): In function `png_load':
c:\emacs-24.0.50\src/image.c:5709: undefined reference to `png_set_longjmp_fn'
collect2: ld returned 1 exit status

I'll look at the patch in the meanwhile ...

Re: windows build failure

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Mon, 03 Jan 2011 12:57:24 -0500
> 
> 
> oo/i386/temacs2.a(image.o): In function `my_png_error':
> c:\emacs-24.0.50\src/image.c:5547: undefined reference to `png_set_longjmp_fn'
> oo/i386/temacs2.a(image.o): In function `png_load':
> c:\emacs-24.0.50\src/image.c:5709: undefined reference to `png_set_longjmp_fn'
> collect2: ld returned 1 exit status

Sorry, my bad.  Please try again with the current repo.

windows build failure

[Sean Sieger]

w32.c:1959:27: error: \x used with no following hex digits
w32.c:1959:27: warning: unknown escape sequence '\i'
make[1]: *** [oo/i386/w32.o] Error 1
make[1]: Leaving directory `c:/emacs-24.0.50/src'
make: *** [all-other-dirs-gmake] Error 2

Re: windows build failure

[Juanma Barranquero]

On Mon, Aug 2, 2010 at 17:01, Sean Sieger <sean.sieger@gmail.com> wrote:

> w32.c:1959:27: error: \x used with no following hex digits
> w32.c:1959:27: warning: unknown escape sequence '\i'
> make[1]: *** [oo/i386/w32.o] Error 1
> make[1]: Leaving directory `c:/emacs-24.0.50/src'
> make: *** [all-other-dirs-gmake] Error 2

Isn't that (again) the result of passing backslashes in the -I paths?

    Juanma

Re: windows build failure

[Sean Sieger]

    Isn't that (again) the result of passing backslashes in the -I paths?

Uh-huh.  Thank you for keeping me moving, Juanma.  Talk to ya in a
few ...

windows build failure

[Sean Sieger]

gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -DENABLE_CHECKING -DXASSERTS  -Ic:\xpm\in
clude -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o oo
/i386/w32.o w32.c
w32.c:1959:27: error: \x used with no following hex digits
w32.c:1959:27: warning: unknown escape sequence '\i'
make[1]: *** [oo/i386/w32.o] Error 1
make[1]: Leaving directory `c:/emacs-24.0.50/src'
make: *** [all-other-dirs-gmake] Error 2

Re: windows build failure

[Óscar Fuentes]

Sean Sieger <sean.sieger@gmail.com> writes:

> gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -DENABLE_CHECKING -DXASSERTS  -Ic:\xpm\in
> clude -Demacs=1 -DHAVE_CONFIG_H -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o oo
> /i386/w32.o w32.c
> w32.c:1959:27: error: \x used with no following hex digits
> w32.c:1959:27: warning: unknown escape sequence '\i'
> make[1]: *** [oo/i386/w32.o] Error 1
> make[1]: Leaving directory `c:/emacs-24.0.50/src'
> make: *** [all-other-dirs-gmake] Error 2

Do not use backslashes on the paths you pass as compiler or linker
arguments. In this case, the backslashes are interpreted as scape
sequences once the string is inserted on the source code.

OTOH, the function get_emacs_configuration_options has a potential
buffer overrun.

Re: windows build failure

[Juanma Barranquero]

On Mon, Jul 19, 2010 at 17:03, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Do not use backslashes on the paths you pass as compiler or linker
> arguments. In this case, the backslashes are interpreted as scape
> sequences once the string is inserted on the source code.

I'm surprised we don't mention this in nt/INSTALL.

> OTOH, the function get_emacs_configuration_options has a potential
> buffer overrun.

Just yesterday I was thinking of fixing ithe buffer overrun, but
before I'd like to bring get_emacs_configuration_options up to date
(it currently only shows a handful of the options passed to
configure.bat).

    Juanma

Re: windows build failure

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 19 Jul 2010 17:30:43 +0200
> Cc: emacs-devel@gnu.org
> 
> On Mon, Jul 19, 2010 at 17:03, Óscar Fuentes <ofv@wanadoo.es> wrote:
> 
> > Do not use backslashes on the paths you pass as compiler or linker
> > arguments. In this case, the backslashes are interpreted as scape
> > sequences once the string is inserted on the source code.
> 
> I'm surprised we don't mention this in nt/INSTALL.

I would also add an entry to etc/PROBLEMS.

Re: windows build failure

[Juanma Barranquero]

On Mon, Jul 19, 2010 at 19:45, Eli Zaretskii <eliz@gnu.org> wrote:

> I would also add an entry to etc/PROBLEMS.

Done.

Óscar, I've borrowed your wording and done horrible, horrible things to it.

    Juanma

Re: windows build failure

[Sean Sieger]

    Do not use backslashes on the paths you pass as compiler or linker
    arguments. In this case, the backslashes are interpreted as scape
    sequences once the string is inserted on the source code.

And only an hour earlier, I hadn't.  Sorry for the noise.

    OTOH, the function get_emacs_configuration_options has a potential
    buffer overrun.