[SOLVED]Compiling 16 bit x86 compiler "FAUcc" under Cygwin

[demonkoryu]

I've been looking for C compiler that can produce real (i.e. not GCC .code16-style) 16 bit x86 assembly AND works on Cygwin as well as a "real" *nix.

I've found BCC (Bruce's C Compiler), but the dialect of C it understands is very old.
I've found OpenWatcom, but can't get it to bootstrap on Cygwin.
Now, I've tried (T)ACK, the Amsterdam Compiler Toolkit, and it seems to be the best fit. Except that it doesn't build due to a function that Cygwin misses: brk().
(Edit: FAUcc looks interesting. Will report how that one goes.)

Long story short: Did anyone of you get ACK to build on Cygwin, and if so, how?

[Love4Boobies]

You don't need to have something use Cygwin to call it from the shell. Just add the path to OpenWatcom to your PATH environment variable and be done with it.

[demonkoryu]

Thanks for your answer. I know I could just drop a binary in, but I want to have a really working cross-platform environment; in case someone decides to check my work out.
The path translation problem of using Win32 binaries in a Cygwin environment would mean that I would have a hackish Makefile to accomodate for that.

[Love4Boobies]

But OpenWatcom is already more cross-platform than Cygwin. How would porting it to Cygwin improve things? And how would your build system be influenced by whether the compiler uses cygwin1.dll?

[demonkoryu]

I consider Cygwin an additional platform. I'm working on the bootstrap, and I'd like the build system to "bootstrap" clean (duh), that means no foreign-platform binaries. Call me stubborn.

[Love4Boobies]

That is silly. I refuse to come up with a more complex solution just because you randomly dismiss a perfectly valid one. What you are asking for makes no technical sense whatsoever.

[demonkoryu]

Hey boobies, there's no need to get abusive. If you don't use Cygwin, this might not make sense. Anyway, here's what I came up with.

FAUcc can produce 16-bit code. It understands GCC-style inline assembly.
I've got it to compile by
a) adding a small missing function to scan.l:

Code: Select all

#if defined(__CYGWIN__)
#define strtold(a,b) ((long double)strtod((a),(b)))
#endif

Since the scanner uses 2 1MB buffers on the stack, I've had to
b) run configure (after calling autoreconf --install --force of course) this way, else cc1 produces a segmentation fault:

Code: Select all

./configure LDFLAGS="-Wl,--stack,8388608"

I couldn't find the "official" sources, however, as the download link on FAUcc's homepage was dead or wrong. I've instead downloaded something from the Ubuntu package development site:
https://launchpad.net/ubuntu/+source/fa ... urce-files
Specifically, the original source, wherever it is from:
https://launchpad.net/ubuntu/+archive/p ... rig.tar.gz

By accident, I also found a Masters Thesis "Implementation of a 16 bit BIOS" (PDF) that uses FAUcc + LD linker scripts for implementation of such a BIOS.

So, there you have a native compiler for Linux and Cygwin that can produce 16 bit (assembly) code!

[Love4Boobies]

I do use Cygwin, in fact. It's just that you've proved that you don't really understand what Cygwin is or how it should be used correctly. If you think I was being abusive, you misunderstood my intentions---the solution I provided actually fixes all the issues you've brought up but you've dismissed it because of misconceptions regarding Cygwin, which doesn't care how the programs it runs were built. I will gladly go into more detail if you tell me why you think that solution doesn't work for you.

[demonkoryu]

Well, yes, I know that Cygwin is mostly providing a POSIX emulation layer for Windows that can be linked to.
I also know that from Cygwin's point of view, it doesn't matter which library an application uses; even if it is launched by bash or say, make. (Although the first Cygwin version I used could not yet launch non-Cygwin applications...)
But because I appreciate Cygwin very much (and I use it since... well, 15 years), I have an interest that I can use binaries that are first class citizens on this pseudo-POSIX environment, and that means bootstrapping clean.

I realize that this desire is of largely philosophical nature. However, I've been bitten by bootstrapping issues several times when I had to rescue mission-critical systems for which the original bootstrapping tools were not available anymore, and it wasn't pretty. So cut me some slack.

[Love4Boobies]

You're taking this too personally. I was just trying to help you to become a better engineer. Emotions always get in the way of that. Criticizing your techniques is different than insulting you. I am sure you are a nice guy in real life.

[demonkoryu]

Don't get me wrong, I very much appreciate your help and I hope that you will help me in the future despite our silly little argument here.
I've just asked a different question from the one that you answered. If I just wanted a 16 bit compiler, I'd just have taken OWC in a heartbeat. But I specifically asked for advice on how to find, and compile, a native Cygwin+Linux compiler. That may not seem an efficient use of time, but it was my innocent and valid question, and I don't take too well to being called silly.
No bad blood though, I know you calling it silly was in good intention. So, now I'm back at work coding at a Linux machine where such problems as with Cygwin simply don't exist, and it's a joy.
Thanks again! Next time, I'll come up with a more sensible question.