WSAPoll & MinGW

For some reason if you try to use WSAPoll, you’ll get this fine error on linking:

poll.c:(.text+0x26): undefined reference to `WSAPoll’

Yeah.

Turns out that it’s basically missing from the includes.  Thanks to this hint, just simply add this into your source/header after pulling in winsock2.h and it’ll link.

typedef struct pollfd {
SOCKET fd;
SHORT events;
SHORT revents;
} WSAPOLLFD, *PWSAPOLLFD, FAR *LPWSAPOLLFD;
WINSOCK_API_LINKAGE int WSAAPI WSAPoll(LPWSAPOLLFD fdArray, ULONG fds, INT timeout);

And now you can happily compile and link.

Just for you, lucky Spanish user, GCC 3.0.4 for Windows NT (MinGW)

From Spain!

I cannot understand why you want this, or why I’m even going to do it.  At this point in GCC history the winnt-3.5 target had been dumped in favour of going all in with Cygwin.  So yeah, this does not either clearly configure, or compile.  But a little bit of mashing files, and I have it at least compiling some assembly that can be translated into an object file that a later version of MinGW can actually compile.

All I’ve built is the gcc driver, the cpp pre-processor, and the cc1 aka C backend.


D:\proj\gcc-3.0.4\gcc>xgcc -c -v hi.c
Using builtin specs.
Configured with:
Thread model: single
gcc version 3.0.4
 cc1 -lang-c -v -iprefix ../lib/gcc-lib/i386-winnt35/3.0.4/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=4 -Dunix -DWIN32 -D_WIN32 -DWINNT -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -DALMOST_STDC -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D_cdecl=__attribute__((__cdecl__)) -D__unix__ -D__WIN32__ -D_WIN32 -D__WINNT__ -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -D__ALMOST_STDC__ -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__cdecl__=__attribute__((__cdecl__)) -D__unix -D__WIN32 -D__WINNT -D__ALMOST_STDC -D__cdecl=__attribute__((__cdecl__)) -Asystem=unix -Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ hi.c -quiet -dumpbase hi.c -version -o C:\Users\jason\AppData\Local\Temp\ccpflisr.s
GNU CPP version 3.0.4 (cpplib) (80386, BSD syntax)
GNU C version 3.0.4 (i386-winnt35)
        compiled by GNU C version 5.1.0.
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
End of search list.
<command line>: warning: "__STDC__" redefined
<builtin>: warning: this is the location of the previous definition
<command line>: warning: "__STDC__" redefined
<command line>: warning: this is the location of the previous definition
hi.c: In function `main':
hi.c:3: warning: return type of `main' is not `int'
 as --traditional-format -o hi.o C:\Users\jason\AppData\Local\Temp\ccpflisr.s

D:\proj\gcc-3.0.4\gcc>gcc hi.o -o hi

D:\proj\gcc-3.0.4\gcc>hi
Hello from GCC 3.0.4

So there you go, mysterious internet user!  Download my source dump with binaries in the tree because I’m lazy.

gcc-3.0.4-MinGW.7z

N64 cross GCC / Binutils for Win32

Building GCC & Binutils for the Nintendo 64

I had a request to help get a GCC+Binutils running as native win32 exe’s something comperable to the ancient ‘ultra’ N64 toolchain done by Kyoto Microcomputer (resume pdf).  One interesting thing about their toolchain is that they used a common object format for MS-DOS, DOS/V and MS-DOS on the PC-98 format, along with Win32.  However the Win32 runtime doesn’t like Win64 environments.  On Win64 the exew32 driver just complains:

Can’t allocate memory (Error Code=487)

However the stubs in all the exe’s reference exegcc98 exegccv DOS extender’s along with a exegcc.  However googling around yields nothing.

Running on a x86 version of Windows, however the tools run and report gcc 2.7.2 release 1.2 and the binutils version is simply 2.6 with BFD version 2.6.  So going with this, and the request to keep it 1997 vintage I went ahead with Gcc 2.7.2.3 and Binutils 2.8.1 as they are the end of the line in both trains of code.

To configure is really a snap, as both support the Windows NT platform directly

sh configure --host=i386-winnt3.5 --target=mips-elf

I guess I should add that I build with TDM GCC 5.1, and I use the incredibly ancient MSYS-1.0.11-rc-1.  But it’s enough to bootstrap and build with!  Since my GCC is much newer, I did have to finagle some things.  Here is a quick list of my notes on what I had changed, and some justification.

Binutils 2.8.1 notes:

include/fopen-same.h

make sure this uses MS-DOS rb wb type constraints!

libiberty/xmalloc.c

There is no sbrk on my MinGW32 … so comment out all the sbrk stuff.

bfd/targmatch.sed

My sed LOVES UNIX style text files, so this one shouldn’t be in MS-DOS CRLF format.

binutils/objcopy.c

mkdir only accepts the path on Win32.  Also there is now chown.

Gcc 2.7.2.3 notes:

c-gperf.h

‘__inline’ for is_reserved_word needs to be commented out.

config/mips/mips.h

Set like the following for both ASM_FINAL_SPEC to prevent the t-mips from trying to be run.

#define ASM_FINAL_SPEC “\
+%{pipe:-}”

config/winnt/xm-winnt.h

OBJECT_SUFFIX “.o”

Just because we are on Windows NT, doesn’t mean we want an .obj object suffix.

gcc.c

__spawnv : __spawnvp work better as _spawnv : _spawnvp

obstack.h

*((void **)__o->next_free)++ = ((void *)datum);

confuses newer compilers, with this error message:

obstack.h:341:32: error: lvalue required as increment operand

replace it with with:

*(__o->next_free)++ = ((void *)datum);

So at the end I have a cross compiler, and I can generate object files, and link files that the final tool MILD can then use and produce N64 ROM images.  It’s not a 100% solution, as I don’t see any mention of MILD being GNU, however the compiler and binutils is running on Windows 10 x64!

GCC cross compiling to the N64 target

GCC cross compiling to the N64 target

I built a few demos and tested with the 1964 emulator.

And there you have it.  For anyone who cares, you can download the toolchain + source here: winnt3.5_i386-mips_elf-gcc-2.7.2.3_binutils-2.8.1.7z

Stupid GCC error

So while mixing and matching GCC on Windows, I ran into this issue with stdio.h of all things:

In file included from hi.c:1:0:
\mingw\include/stdio.h:191:65: error: unknown type name ‘size_t’
_CRTIMP int __cdecl __MINGW_NOTHROW setvbuf (FILE*, char*, int, size_t);
^~~~~~

Good grief how could stdio be all screwed up?

Well, it turns out it was my fault.  I had not rebuilt things like SDL, or copied over pcap so I figured I could incorrectly just point a -I to my old includes, and the new gcc would post-pend all use -I stuff.  NOPE it pre-pends them, meaning the old headers now take priority.  And wouldn’t you know it, things have drifted between versions.  So I just manually copied the files and libraries and all was well.

Googling around I did see other people with broken stdio.h but nobody posted the solution.  I guess it’s to embarrassing, but here we are.

GCC 6.1.0 for MinGW

Since MS-DOS has it’s 6.1.0 I was dying to re-build stuff for 6.1.0.  As I don’t want to build it myself I did mange to find a version on equation.com

I rebuilt Cockatrice III, and that seems to be running fine.

Continuing from my GCC 1.40 on Windows, here is version 6.1.0’s scores:

D:\emx\demo\dhry>gcc610.exe
Dhrystone(1.1) time for 500000000 passes = 53
This machine benchmarks at 9433962 dhrystones/second

D:\emx\demo\dhry>gcc610_O.exe
Dhrystone(1.1) time for 500000000 passes = 18
This machine benchmarks at 27777777 dhrystones/second

D:\emx\demo\dhry>gcc610_O2.exe
Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

D:\emx\demo\dhry>gcc610_Ofast.exe
Dhrystone(1.1) time for 500000000 passes = 13
This machine benchmarks at 38461538 dhrystones/second

As you can see the scores are actually slower than GCC 5.1.0.  Well that was kind of surprising.  Since I almost never read the manual, I did find out about -Ofast vs -O3/-O2, and yes, it is much faster!  So I guess I should recompile everything with GCC 5.1.0 … But I do prefer the diagnostic messages in GCC 6, it’s very CLANG like.

Ported UAE 0.7.6 to MinGW!

0.7.6

0.7.6

I can’t find any source of the 0.5 versions, and I had issues with 0.6.x  but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?).  I suppose with this version working I can go back and take a stab at resurrecting 0.6.x

What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.

I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta.  So now you can actually use the CLI, and change disks.  Double clicking is an impossibility as it simply runs far too fast.  I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.

I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast.  UAE is from an era where a 100Mhz computer was a luxury item.  Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.

For the 2/3 people who care, I put the binary & source tree on sourceforge here. UAE 0.4 & UAE 0.1 are also available for download, plus all the source code I’ve been able to find.

Stack corruption in MSYS with Windows 10

I’m sure it’s happened in other versions of Windows too.  Everything will be fine, then out of the blue you start getting errors like this:

0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x3B0000, State 0x10000
d:\mingw\bin\sh.exe: *** Couldn’t reserve space for cygwin’s heap, Win32 error 0
make: *** [all] Error 1

Well MSYS like Cygwin uses persistent shared memory locations, and if they become corrupt, it’s game over.

So yeah, reboot.

Updated build of Linux 0.11 on Windows 10

Building & Running Linux

Building & Running Linux

I’ve updated my project for compiling Linux 0.11 on Windows 10.  In this version it builds a lot better with TDM MinGW 5.1.0 + MSYS.

The big improvements is that you can compile Linux without the full MinGW/MSYS install by running the ‘blind’ script which will compile the kernel without make and friends.

The build process for the kernel works as well so now with the included Qemu 0.12.5, no need to link under Linux anymore.  I fixed up some of the build processes as I thought I’d re-build and some stuff bombed so it’s all fixed up.

For those interested, I just updated the original download here:

MinGW-aout-linux-011.7z

Building Linux 0.11 on Windows 10

No really, it compiles! on Windows!

No really, it compiles! on Windows!

So continuing with the fun from yesterday, where I had managed to get gcc 1.40 running on Windows with MinGW, it was time to try to take the final leap and build Linux.

There wasn’t too much to massage on Linux, mostly Makefiles for the various tool name differences, and how to handle keyboard.S as the default setup for NTFS is case insensitivity.  While I did get some old version of as16 and ld16 to build, I’m not sure if they are working correctly.  Or it could be the ‘build’ tool.  The downside is that the final ‘Image’ file produced doesn’t work (I should add that all issues have since been fixed, and it is now possible to cross compile a running kernel from Windows, and boot it with Qemu).

But copying the ‘system’ file that is compiled on Windows, to a Linux VM, and having it do the boot setup does work!

And it boots!

And it boots!

Very cool to say the least!

I almost wonder if MSVC 1.0 could build any of this.  Then it could be possible to bootstrap Linux from Windows NT 3.1 … Although Windows 10 is good enough for me, right now.

And I got the DJGPP 1.0 gcc driver to work (soft of)!

C:\aoutgcc\test>gcc -v hello.c -o hello -I ../include-0.12 -L../lib
gcc version 1.40
cpp -v -I ../include-0.12 -undef -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ hello.c C:/Users/neozeed/AppData/Local/Temp/cca0_388.cpp
GNU CPP version 1.40
cc1 C:/Users/neozeed/AppData/Local/Temp/cca0_388.cpp -quiet -dumpbase hello.c -version -o C:/Users/neozeed/AppData/Local/Temp/cca0_388.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387
a386 -o hello.o C:/Users/neozeed/AppData/Local/Temp/cca0_388.s
ld -o hello c:/aoutgcc/lib/crt0.o -L../lib hello.o c:/aoutgcc/lib/gnulib -lc c:/aoutgcc/lib/gnulib

Sorry that doesn’t format so well on a blog.  But now I only have to force the include path, and the lib directory. At this point I’d call it ‘good enough’

I uploaded the archive MinGW-aout-linux-011.7z.  If you want to compile Linux, you’ll need a MSYS from MinGW.  Otherwise, this is only interesting to people who run Windows and want to play with Linux 0.11.  I also included the Linux VM, and binaries for the tools.  It’s not even 7MB.  How is that for crazy small?

 

** EDIT

I got it all working now that I found all the portions to set to output as O_BINARY/wb that are needed on a Win32 host, so using MinGW I can build the as86/ld86/binutils/gcc and Linux 0.11!

My updated post is here.

Building MinGW32 Qemu on Linux (or anything else I guess)

So as always it’s the glibc2 wars.  And as part of the fun you need pkg-config.  And since it has to run, you’ll end up with the native version.

Luckily I found this site, mega-nerd.com

So you can create a i586-mingw32msvc-pkg-config file.  Just in case it get's lost here it is:

#!/bin/bash

# This file has no copyright assigned and is placed in the Public Domain.
# No warranty is given.

# When using the mingw32msvc cross compiler tools, the native Linux
# pkg-config executable works fine as long as the default PKG_CONFIG_LIBDIR
# is overridden.
export PKG_CONFIG_LIBDIR=/usr/i586-mingw32msvc/lib/pkgconfig

# Also want to override the standard user defined PKG_CONFIG_PATH with
# a mingw32msvc specific one.
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH_MINGW32MSVC

# Now just execute pkg-config with the given command line args.
pkg-config $@

Fun as always, right?

And as always Qemu can be configured with:

configure --cross-prefix=i586-mingw32msvc-

When cross compiling.