[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: make'ing make-3.18beta4 under mingw/msys - "undefinedreferenceto `sl
From: |
Eli Zaretskii |
Subject: |
Re: make'ing make-3.18beta4 under mingw/msys - "undefinedreferenceto `sleep'" |
Date: |
Sun, 01 Jan 2006 22:00:44 +0200 |
> From: "Markus Mauhart" <address@hidden>
> Date: Sun, 1 Jan 2006 19:14:37 +0100
> Cc: address@hidden
>
> > Well, if config.h.W32 is different from config.h you get by running
> > configure, then please report the discrepancies (with the obvious
> > exceptions of a different ordering).
>
> Please see the attached files:
>
> config.w32 ... copy from official make-3.81beta4
> config.h ... produced by "address@hidden" (-> see below)
> config.W32.h-config.h.windiff.log
> ... list of different lines, produced by MS windiff
Thanks.
> >> E.g. I hoped that address@hidden would suggest
> >> '#define FILE_TIMESTAMP_HI_RES 1' (-> turned out not).
> >
> > Why did you think so?
>
> Because w32-API and NTFS file times have a resolution far below 1s
> (100ns IIRC).
Well, yes, but that's not what the configure script looks for. The
comment near the test says:
Find out whether our struct stat returns nanosecond resolution timestamps.
So it is actually testing whether `struct stat' returns file times
with nanosecond resolution, which isn't true with MinGW that uses
`stat' from the Windows runtime.
> ./configure decides about the C-#defines, which in turn decide at
> compiletime also about some gnumake features ... e.g. HAVE_DOS_PATHS,
> FILE_TIMESTAMP_HI_RES.
True; but config.h.W32 is already supposed to define everything that
can be supported on Windows.
> > produced Make binary. In fact, I don't even understand why
> > loadavg.exe was built: it seems to be part of check-loadavg target
> > that should be only invoked if you say "make check", which I think you
> > didn't.
>
> IIRC every ./configure+make (like above's "address@hidden") of some
> gmake381xxx I did (cygwin, msys) at the end tried to build loadavg.exe
> - succeeding under cygwin, failing under msys.
I think you ran "make check" for some reason.