[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: make'ing make-3.18beta4 under mingw/msys - "undefined referenceto `s
Re: make'ing make-3.18beta4 under mingw/msys - "undefined referenceto `sleep'"
Fri, 30 Dec 2005 23:46:15 +0100
"Eli Zaretskii" <address@hidden> wrote in message news:address@hidden
>> From: "Markus Mauhart" <address@hidden>
>> Date: Fri, 30 Dec 2005 19:24:13 +0100
>> Cc: address@hidden
>> I built make-3.18beta4 (-> ftp://alpha.gnu.org/gnu/make) both under
>> cygwin and under mingw/msys, using basically the same commands inside
>> cygwin's and msys' bash:
>> dstroot=/c/mau/out/cyg <------ for cygwin
>> dstroot=/c/mau/out/mss <------ for msys/mingw
>> [ -d $dst ] || mkdir $dst && cd $dst
>> $src/configure --enable-case-insensitive-file-system --disable-rpath
>> make CFLAGS='-O3 -s'
>> 100% ok for cygwin.
>> 99% ok for msys -- the last build instruction fails:
>> gcc -O3 -s -o loadavg.exe loadavg-getloadavg.o
>> loadavg-getloadavg.o:getloadavg.c:(.text+0xd5): undefined reference to
>> collect2: ld returned 1 exit status
>> make: *** [loadavg.exe] Error 1
>> make: Leaving directory `/c/mau/out/mss/make-3.81beta4'
> Do I understand correctly that you built the MinGW port of Make by
> running "./configure; make" from the shell's prompt?
> If so, then
> that's not how you should do it. Instead, run the build_w32.bat batch
> file from cmd.exe, like this:
> build_w32 gcc
> (The file README.W32 explains this, I think.)
> Make sure you delete config.h before you do this, so that
> build_w32.bat will copy config.h.W32 to config.h and use that.
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.
E.g. I hoped that address@hidden would suggest
'#define FILE_TIMESTAMP_HI_RES 1' (-> turned out not).
Also for other defines I'm interested in the config.h produced by
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
("gmake -j": I still dont know whether '#3678 make -j unnecessarily
requires an Unix shell'
will work for current gmake, built with build_w32.bat ...)
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.
> If I build the MinGW port with build_w32.bat, I don't have any
Btw 2, many thanks to you, JGrant, Paul and colleagues for putting
so much efforts in gnumake381's builtin windows support !