One last test for the night, I switched to mingw32-make.exe by changing the 3 files I mentioned in my previous email. The build proceed without issues.
--Jafar On Fri, Nov 6, 2015 at 12:48 AM, Jafar Al-Gharaibeh <[email protected]> wrote: > I did another test; I switched to mingw64 toolchain and did a 32-bit > build, same result: no build errors. The new gcc reports the following > version: > > c:\unicon>gcc --version > gcc (tdm64-2) 4.8.1 > > --Jafar > > > On Fri, Nov 6, 2015 at 12:35 AM, Jafar Al-Gharaibeh <[email protected]> > wrote: > >> Don, >> >> I fixed rusage related errors a while back, I discovered that I didn't >> commit this fixes - I just did. >> >> I checked out a fresh copy of Unicon sources and tried to do a 32-bit >> build. I have mingw32 for that with gcc 4.7.2. I then did >> >> make W-Configure-GCC # or NT-Configure-GCC >> >> You only need to do this one time only; the very first time after a fresh >> checkout to get windows makefile at the top level. >> >> I then did this: >> >> make WUnicon32 >> >> The build went smooth without any errors! I then moved make.exe to >> mymake.exe and made sure I don't have any other make.exe on my path. >> >> I then did: >> >> mymake.exe WUnicon32 >> >> To catch all hard-coded calls to make, to my surprise there was non on >> the build path. However there were a few MAKE variables that I have to >> change manually in these files: >> >> unicon/config/win32/gcc/makefile.top # two occurrences at the top >> unicon/config/win32/gcc/makefile.wop # two occurrences at the top >> unicon/config/win32/gcc/makedefs.top # one occurrences at line 55 >> >> in all cases I change >> >> MAKE=make >> >> to >> >> MAKE=mymake >> >> The build went smooth again with my "new" make with no errors. >> >> I haven't tried to enable jpg/png/threads yet, but at least until this >> point everything seems to be in order. Can you reproduce this? if not then >> it must be a difference in the the toolchain which is something we >> experienced many times in the past. >> >> Cheers, >> Jafar >> >> >> >> >> On Thu, Nov 5, 2015 at 4:47 PM, Don Ward <[email protected]> wrote: >> >>> >>> On 5 Nov 2015, at 21:57, Jafar Al-Gharaibeh <[email protected]> wrote: >>> >>>> The only way I’ve got it to work is if I have “make.exe’ available >>>> somewhere in my PATH. I also had to have the CPPFLAGS and CXX arguments. Do >>>> you build successfully without them? >>>> For me, without CXX I get g++ (which doesn’t go very well) and without >>>> the CPPFLAGS it can’t find ndbm.h (when compiling rttparse.c) and tp.h >>>> (when compiling libtp). >>>> >>> >>> Usually no, I don't need this, but the last time a tried to build on >>> Windows a couple of weeks ago I had similar issues. There has been a >>> stream of commits to svn lately that shuffled few things around. We will >>> fix that >>> >>> >>> I was building rev 3976 (so I could compare what I had built with my >>> toolchain with the “official release” and hence validate my local build >>> environment). I don’t see how recent svn commits could have affected rev >>> 3976, but I still need CPPFLAGS and CXX to build it. >>> >>> Part of the "make" problem -aside from the hardcoded calls to make- is >>> that different "make" programs behave differently. Add differences between >>> different Windows releases/updates and you get a very unpredictable >>> behavior. Last year, Clint took on a quest to build our own make (lives in >>> unicon/uni/umake.icn) to avoid some of this mess. Not sure if we are going >>> to switch to that at some point if it is mature enough. >>> >>> >>> If you do switch you’ll have the usual bootstrapping problem when >>> starting from scratch with a new build: you need uMake to be working in >>> order to build itself. >>> >>> I will rebuild from scratch on Windows in the next couple of days and >>> fix these new issues. I will let you know when I get that done. >>> >>> >>> OK (and thanks for all your efforts). BTW, when I tried building rev >>> 4186, I got a stack of errors to do with rusage (which looks to have been >>> implemented circa rev 4052). Is this also a known problem for Windows >>> builds? >>> >>> Don >>> >>> >> >
------------------------------------------------------------------------------
_______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group
