jwt27

Why i686? All it does is set the default value for `-march=`, and then the target libraries are built with that. I would suggest using i386 instead for improved compatibility.

I'm not seeing anything that requires i686-compiled target libraries - only hardcoded compiler names, which is just bad practice. If you want to avoid patching the makefiles, symlinks would work...

386 doesn't have `cmpxchg`, you'll need `-march=i486` at minimum. I do want the debian/ubuntu packages to produce 386 code by default, so won't fix.

I think those are in `libatomic`. Have you considered other solutions? For atomic flags you generally only need `__atomic_test_and_set()` (which is just regular `xchg`).

> > I think those are in libatomic > > Its probably unavailable in your build. -latomic doesn't seem to work. It hasn't been ported to djgpp yet, I guess...

> Maybe if you use `-mtune=i386` then it won't use anything of 486 unless explicitly asked? Just a guess. `-mtune` only affects instruction timings, so that doesn't help: ``` $...

So, we don't know if anything will break if it's changed. Not sure what the best course of action is. I was considering sending a patch to djgpp, but it...

Did some searching. From what I can tell the exit status is only checked in `dpmildr.asm`, and it only checks if it's >= 4. So to me it seems safe...

By the way, I did send a patch to djgpp (but no response yet), since I think it's more correct to ignore the exit status, and it also saves a...

Generally no, since the stub checks `int 2f/1687` before loading dpmi. Only if the already-installed host is 16-bit, then it could be an issue. From what I can tell hdpmi32...