Won't compile
Closed this issue · 23 comments
I've just spent the last hour or so trying multiple ways to get the new version of label to compile in order to have support for NLS. Unfortunately, none of the methods I tried would build it. Using the current FreeDOS packages for WATCOM, and GNU make from DJGPP, in DOSBox and in VirtualBox under FreeDOS. VM crash every time. Even with no drivers loaded. With just HIMEMX, It gives a GPF.
So, IDK. But, I've spent too much time on this trying to get a build already.
I will look into it, last I compiled a few weeks/months? ago from here, it just worked.
So are you using build.bat? I tested before using watcom and tcc, but can't recheck myself as I'm away from home at the moment. Looking at the batch file it should build as
build.bat tcc
or
build.bat watcom
It requires that the PATH be setup accordingly. If it still doesn't work, a log file showing the failure would be useful please.
Oh I forgot to say I was using Dosemu2. However crashing the virtual environment doesn't really sound like a build problem that my hints above could help with. Have you used this build environment successfully to build anything before?
@andrewbird I use that DOSBox env all the time to build things. I have used it to build OW programs as well. But, it has been a while and I forget the last OW compile I did. As for the VirtualBox env, I don't use it often. But, basically it's a clone of what is in DOSBox.
After running with build.bat watcom, it runs a little bit and DOS crashes not the VM.
So a little further info on my build env, I was using Dosemu2 with FDPP kernel, but FreeCOM rather than Comcom32. I believe the Watcom I was using was the current snapshot from its git repo here https://github.com/open-watcom/open-watcom-v2. The GNU make I'm not quite sure where from although I think it might not be the latest as I seem to remember some odd issues, however I believe it was the one contained in this commit here andrewbird/pcmos386@916798b
Hope that helps.
Perhaps change the Gnu make to see if that helps first
I found loading hxdos resident made dosbox more stable (i.e. actually complete a build, but it still crashed or hung randomly) when building fd kernel (didn't like alternating between causeway for Nasm and dos4gw for ow) on windows 10 64 bit. It's why I am redoing to use only gnu make and native tools (had to use digital mars linker for Borland build as tlink32 doesn't support DOS executables). I previously built on windows 10 32 bit and dosbox worked much better.
Well, I'm thinking, that for the time being, it might probably be easier for you to compile it and do a "release" tag with binaries and sources. Then, I can just wrap it in a package for RC5.
I don't know if any of the other projects you have under FDOS are "new" versions for existing ones, just forks, or what. If they are updates, I'd like to see us get them into RC5 as well. But, as I said, I don't know whats what and likely will have similar compile issues with those.
Anyhow, let me know. Thanks.
I'm working on new releases, plan is to have them announced this weekend. Ran into unrelated issues delaying my general DOS application building (windows 64 bit vs 32 bit issues).
Well, I tried a couple to build a couple other projects in FDOS. No luck with those either.
So, if I could get either of you to build these and just email them to me, I can update the packages and include them in RC5. I guess the ones I'd like to get are:
share xcopy fc choice more sort find label edit fdisk mem emm386 diskcopy tree
I will work on uploading the builds to GitHub tonight and send you an update.
I have uploaded an Open Watcom based build for label - works and builds fine; I'm having trouble testing Borland builds as tlink keeps killing my command process and I can't get gcc to finish linking (not sure if its my installation or the DOS emulation layer). It's late so I will continue this later...
Well, tried to compile it again. No joy.
I'm back home now so I thought I'd give it a try to compile. The commit 85c3802 broke all the cross-compile (gcc / watcom) and dosemu2 (tcc / watcom) builds using ./build.{sh,bat) for me. It looks like there's now considerable compiler specific logic back in the Makefile, which is something I hoped would stay in the build scripts to avoid platform and compiler difference issues.
I'm thinking of making Linux (with dosemu) the only supported build... I use Windows normally (in a DOS like manner) but with latest versions I can get real mode and 32 bit protected mode DOS and even 16 bit windows programs to work decent but not 16 bit protected mode DOS programs (ie Borland compilers) to work reliably. Dosbox crashes, msdos player doesn't support 16 bit dpmi and a vm runs but not fun to edit on. Or maybe only support open Watcom and GCC-ia16 since both of those cross compile and work under DOS. Anyway, I will fix or revert this evening. Sorry about that.
Please try again.
I made some updates that hopefully makes building easier. Note thought that gmake is required (unless you run the pretty simple build command by hand).
Under DOS or Windows you can run build.bat tcc or build.bat watcom to build with the corresponding compiler.
set UPX=rem blah or UPX=echo blah prior to running build to skip the compression step (or if you don't have upx in your path)
set TURBO=0 to use Borland vs Turbo compilers, i.e. bcc instead of tcc
you may need to edit build.bat to correct (or comment out) the lines that set the PATH environment variable; I recommend you set your path prior to trying to build - i.e. for watcom run the owsetenv.bat or similar that installation usually creates (sets all the WATCOM environment variables and adds to path), or include the borland bin directory in your path [or update build.bat with correct directories for the set PATH= line]
To skip building with CATS simply pass NOCATS to build.bat prior to the compiler, e.g. build NOCATS tcc
Alternative to using build.bat, assuming your compiler is setup (owsetenv called or path includes tc30\bin etc) then cd in the the src directory and invoke make; by default it attempts to build with open watcom compiler, to use a different compiler pass COMPILER=borland COMPILER=watcom COMPILER=gcc respectively, you can also pass TURBO=0 to use bcc instead of tcc
On linux make sure open watcom and/or gcc-ia16 are installed and appropriate environment variables exported (or that build.sh sets them), then run build.sh watcom or build.sh gcc
Alternatively, cd in the src directory and invoke make
For DOS you will likely want DJGPP tools in your path (make and rm), on windows only make need to be in your path as DEL is used (didn't look too hard why make on DOS is using rm, likely due to the DJGPP environment its run under).
label successfully builds for me under Linux (Ubuntu), Windows (10 64 bit), and plain DOS (in a VM) using Open Watcom 1.9, latest GCC ia16, and Borland compilers (Turbo C/C++ 3, Borland C/C++ 3 and Borland C/C++ 5)
I have not tested building under DOSEMU2 as I have to yet to setup my compilers under it, though hopefully that works as build.bat works under plain DOS in VirtualBox and under Windows cmd.
I added the compiler specific stuff to the Makefile as it was actually easier to support all 3 environments directly using it than using the 2 different build scripts - also I originally was having issues where environment variables set in the build.bat file not being used by make but calling make directly worked.
A side note: Building under 32 bit Windows 7 or earlier was so much easier (Windows 10 32 bit version seemed like a largely unused version and NTVDM was barely usable). I am standardizing on using gnu make for my builds as it supports all three common build platforms.
After I hear back (and hopefully without any needed updates) I will publish a 1.5 release of label [same as 1.4c pre-release from yesterday but with 1 additional translation update, build changes, and updated version strings]. Then I will move onto tree - note that as I actually have been maintainer of tree for a long while, I will be making the next release based off pdtree sources (as it is tree's successor, I just never made an explicit release).
On Windows I like this build of gnu make - https://github.com/mbuilov/gnumake-windows
From share xcopy fc choice more sort find label edit fdisk mem emm386 diskcopy tree
I believe only share has improvements (other than translations) that would be good to get into the distribution, though of the them I have only worked on share, edit, fdisk, and tree
For DOS you will likely want DJGPP tools in your path (make and rm), on windows only make need to be in your path as DEL is used (didn't look too hard why make on DOS is using rm, likely due to the DJGPP environment its run under).
Gnu Make sets up the $(RM) variable (and others) to the platform specific command. Apparently if you run make -p you can see all the defaults. It uses this $(RM) internally to clean up non precious intermediate files etc. There are a couple of caveats on DOS (I don't know about Windows) in that multiple files or wildcards must be specified separately i.e.
$(RM) a.fil
$(RM) b.fil
$(RM) *.obj
$(RM) *.mapnot
$(RM) a.fil b.fil *.obj *.mapand recursive directory deletion isn't possible. But I suspect that's no different to what occurs if you set RM yourself.
BTW, did you find a need to flip the directory separator on Windows builds, because for me it works just fine within the Makefile as '/' on both tcc and watcom DOS builds?
Thanks for fixing the cross-compile and Dosemu builds, though I have a little PR coming for Watcom DOS build.
Still won't compile. Tried DOSBox, which just freezes. Tried VirtualBox, with JEMM and get a GPF error, tried without just get something similar and VM freezes. Tried fresh install of WATCOM from their installer instead of packages. No matter where I try to build or on which DOS system it kills the VM (in different ways) at the exact same point. Early on with screens like this https://fd.lod.bz/public-images/label1.png
Can you build a basic program?
int main() { return 0;}
It looks like incompatibility with dos extenders. Try running hdpmi16 -r and hdpmi32 -r and ensure %WATCOM%\binw is before any other Watcom tools
Also try going into src directory and running make COMPILER=Watcom
Unless you just really need/want otherwise, building under native Linux compilers and cross compiling to DOS is easiest and produces smallest binaries
I have published a new release of label with builds from all supported compilers. The label-1.5.zip is the one you probably will want.
Well, Tried basic C program (stripped everything out of LABEL.C and adjust make to exclude Kitten and PRF). Same thing. Tried switching CWSDPMI to use the one with FPC. But, I don't think it was using it. Tried updating to latest FreeCOM, Kernel, HimemX and Jemm. Tried with almost no drivers (just HimemX). Tried some other stuff. All same results. So, at present IDK. It does seem to be related to be related to DPMI.
I know I did use Open Watcom 1.9 a while back to compile something that was released as source only for one of the Releases. But, it was a long time ago and I forget which one it was. I don't really use Watcom. So, I don't know if it is being "caused" by one of the command-line switches or something else. It is possible that a change somewhere in the OS, shell or drivers is causing it to fail building. It is possible that I was using a different CWSDPMI or at least different version on that build long ago. There are a lot of moving parts involved.
For now, I going to just use your build and move on with getting RC5 done. Eventually, the issue will need to be figured out and resolved. But, I think that can wait until later.
You can go ahead and close this issue. After RC5 is out and I feel like digging into this more, we can always reopen it or start a new one.
Thanks again.
Old, outdated, possible resolved, worry about it later. :-)