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
