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
