The FreeDOS kernel build process (build.bat) fails.
Error message:
[...]
..\utils\echoto KWC38632.lnk main.obj config.obj initoem.obj inithma.obj dyninit.obj iprf.obj initdisk.obj initclk.obj cpu.obj
Error(E14): Cannot execute (..\utils\echoto): Argument list too big
Error(E42): Last command making (kwc38632.lnk) returned a bad status
Reason:
DOS has the limitation that only 8 files (oonly 9 directly accessible parameters) are allowed.
Solution: Edit within the kernel/makefile the lines
OBJS7= main.obj config.obj initoem.obj inithma.obj dyninit.obj iprf.obj initdisk.obj initclk.obj cpu.obj
OBJS=$(OBJS1) $(OBJS2) $(OBJS3) $(OBJS4) $(OBJS5) $(OBJS6) $(OBJS7)
to
OBJS7= main.obj config.obj initoem.obj inithma.obj dyninit.obj iprf.obj initdisk.obj initclk.obj
OBJS8=cpu.obj
OBJS=$(OBJS1) $(OBJS2) $(OBJS3) $(OBJS4) $(OBJS5) $(OBJS6) $(OBJS7) $(OBJS8)
AND
$(TARGET).lnk: turboc.cfg makefile ../mkfiles/generic.mak ../mkfiles/$(COMPILER).mak
-$(RM) *.lnk
$(ECHOTO) $(TARGET).lnk $(OBJS1)+
$(ECHOTO) $(TARGET).lnk $(OBJS2)+
$(ECHOTO) $(TARGET).lnk $(OBJS3)+
$(ECHOTO) $(TARGET).lnk $(OBJS4)+
$(ECHOTO) $(TARGET).lnk $(OBJS5)+
$(ECHOTO) $(TARGET).lnk $(OBJS6)+
$(ECHOTO) $(TARGET).lnk $(OBJS7)
$(ECHOTO) $(TARGET).lnk kernel.exe
$(ECHOTO) $(TARGET).lnk kernel.map
$(ECHOTO) $(TARGET).lnk $(LIBS)
to
$(TARGET).lnk: turboc.cfg makefile ../mkfiles/generic.mak ../mkfiles/$(COMPILER).mak
-$(RM) *.lnk
$(ECHOTO) $(TARGET).lnk $(OBJS1)+
$(ECHOTO) $(TARGET).lnk $(OBJS2)+
$(ECHOTO) $(TARGET).lnk $(OBJS3)+
$(ECHOTO) $(TARGET).lnk $(OBJS4)+
$(ECHOTO) $(TARGET).lnk $(OBJS5)+
$(ECHOTO) $(TARGET).lnk $(OBJS6)+
$(ECHOTO) $(TARGET).lnk $(OBJS7)+
$(ECHOTO) $(TARGET).lnk $(OBJS8)
$(ECHOTO) $(TARGET).lnk kernel.exe
$(ECHOTO) $(TARGET).lnk kernel.map
$(ECHOTO) $(TARGET).lnk $(LIBS)
After the above modifications of the kernel/makefile, the build process works fine.
The the edited kernel/makefile is attached.
I ran into this same problem. I'm running on Ubuntu 12.04, with dosemu building with the Watcom compiler. I modified the makefile in the same way. Can we get this into the source code repo?
Same problem here, the solution described by Sven worked perfectly. Any chance this could land in SVN's trunk, for future generations to enjoy?
Yes, this was resolved in my primary kernel repository with commit https://github.com/PerditionC/fdkernel/commit/08c05b1d7aab11fede3c5e7fe3421c1ea7b05b28#diff-3885426c104e86ff67e62c6398c3f68f and will be applied to SVN soon.
That's cool, thanks! but I'm lost now... What is the relation between the SVN and github repositories? Why having two repositories for supposedly the same project? Wouldn't it be better to keep everything on the SVN's trunk here at sourceforge?
Kernel 2042 has already been released in May. This ticket should be closed (and a new one opened, if still needed, I haven't looked closely myself).