make-w32
[Top][All Lists]
Advanced

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

Re: make'ing make-3.18beta4 under mingw/msys - "undefined referenceto `s


From: Eli Zaretskii
Subject: Re: make'ing make-3.18beta4 under mingw/msys - "undefined referenceto `sleep'"
Date: Sat, 31 Dec 2005 10:59:30 +0200

> From: "Markus Mauhart" <address@hidden>
> Date: Fri, 30 Dec 2005 23:46:15 +0100
> Cc: address@hidden
> 
> Actually I was just checking the so copied config.h when I thought it
> might be a good idea first to check out the config.h computed by
> address@hidden, hence I decided first to run the 'default'
> build procedure, with cygwin and with msys/mingw.

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).

> E.g. I hoped that address@hidden would suggest
> '#define FILE_TIMESTAMP_HI_RES 1' (-> turned out not).

Why did you think so?

> Another reason for me to preferre buliding via address@hidden:
> I probably have to use the resulting gmake together with msys' sh.exe
> to get working "gmake -j" (dual core :-) ... I guess the optimal
> partner of msys' sh.exe is gmake built via address@hidden

Why would you think that?  There's nothing in the configure script
that tests the shell or any other external utilities, it only probes
the compiler, the header files, the libraries, and the OS system
calls.

> ("gmake -j": I still dont know whether '#3678 make -j unnecessarily
> requires an Unix shell' 
> (http://savannah.gnu.org/patch/?func=detailitem&item_id=3678)
> will work for current gmake, built with build_w32.bat ...)

It will work (or not) in the resulting binary regardless of how it was
built, since there's nothing in the configure script that could change
the code which rejects -j when a Unixy shell is not available.

> Btw, despite the trailing error, address@hidden DID result
> in a working make.exe; nevertheless I'd like to know whether others
> can reproduce (or better: help me solve) that error.

That error happens when the Makefile produced by the configure script
tries to build loadavg.exe, which is a separate program.  But you
don't need this program, since it is used only for testing the
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.

> Btw 2, many thanks to you, JGrant, Paul and colleagues for putting
> so much efforts in gnumake381's builtin windows support !

You're welcome.




reply via email to

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