OS X 10.12 to Win32 MinGW cross compiler

Using GCC 4.1.2 because that is what I wanted.

Oh yes, it works!

It’sGCC 4.1.2 for MinGW on OS X.  Naturally I had some fun along the way.

      cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o winnt-cxx.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o tree-inline.o dummy-checksum.o main.o  libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libiberty/libiberty.a

Undefined symbols for architecture x86_64:

  “_libc_name_p”, referenced from:

      _nothrow_libfn_p in except.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make[2]: *** [cc1plus-dummy] Error 1

make[1]: *** [all-gcc] Error 2

make: *** [all] Error 2

$

 

From stack overflow:

When gperf wasn’t installed, the compilation script ran the command anyway but generated a blank ./gcc/cp/cfns.h. Since this file was newer than the source (./gcc/cp/cfns.gperf) the makefile left it alone and never regenerated the ‘real’ file when you actually had gperf. To continue, run rm ./gcc/cp/cfns.h and try again.

to dealing with duplicate inlines exact_log2 from an include gone wrong.  Not to mention more and more headers not generating.  But in the end it actually works.  As always it feels so much faster to run on OS X than Windows.  I’m sure there is stuff out there for newer versions of GCC, but I wanted to use the older toolchain and libs for some other reason.

As always it’s on my site here: OSX_16.3.0-MinGW_GCC_4.1.2.7z but I don’t think the world at large would even care.

Darwin 1.4.1 installs on Qemu 2.7!

Darwin 1.4.1 on Qemu

Darwin 1.4.1 on Qemu

I tried the x86 version from Apple’s Darwin web site.  For those who don’t know Darwin was (is?) an open source version of the OS X kernel and userland.  This was on parity with the OS X 10.1 release.  It was notoriously picky about hardware back in 2001, let alone anything today, and much to my amazement it installed fine on Qemu 2.7.

Source code to the packages should be about here.

Whlie I may have a kernel dump of Darwin 0.3, old releases appear next to impossible to find.

So apparently in OS X packages actually expire

I found this out trying to install XCode 4.2 on OS X 10.6

Failed install preflight: Error Domain=PKInstallErrorDomain Code=102 UserInfo=0x1d9a30 “The package “iPhoneSDKTools.pkg” is untrusted.” Underlying Error=(Error Domain=NSOSStatusErrorDomain Code=-21 47409654 UserInfo=0x1dbe90 “The operation couldn’t be completed. CSSMERR_TP_CERT_EXPIRED”)

CSSMERR_TP_CERT_EXPIRED??

Yep turns out XCode 4.2 (and probably many others) will actually expire.  So turn off the automatic clock sync, and set your time back to before the package was issued (Xcode 4.3, released on February 16, 2012..) and you’ll be good to go.

Installing Xcode 4.3

Installing Xcode 4.2

Qemu 2.3.0 released!

While trying to build on OS X there is some errors with building pixman
Undefined symbols for architecture x86_64:

“_prng_state”, referenced from:
_main in region-test.o
“_prng_state_data”, referenced from:
_main in region-test.o

But these are some ‘test’ programs that we really don’t need or care about.  A quick way to get it to bypass these is to run

touch /pixman/test/region-test
touch /pixman/test/scaling-helpers-test

And now it’ll compile, link and everything!

DOOM!

DOOM!

And yes, it’ll run DOOM.  Although on my 2012 MacBook Air, it’s VERY slow.  But at least the audio works.

From the source code…

DEFINE_PROP_UINT32 (“iobase”, SB16State, port, 0x220),
DEFINE_PROP_UINT32 (“irq”, SB16State, irq, 5),
DEFINE_PROP_UINT32 (“dma”, SB16State, dma, 1),
DEFINE_PROP_UINT32 (“dma16”, SB16State, hdma, 5),

So for MS-DOS be sure to set the BLASTER environment variable to:

SET BLASTER=A220 I5 D1 H5 P330 T6

From the source, in case anyone cares anymore about how to run MS-DOS soundblaster stuff in Qemu.  For any OS X users, you can find my binaries here.

And to run DOOM it’s something like this (once you’ve installed MS-DOS and DOOM itself!)

./qemu-system-i386 -L pc-bios -m 16 -soundhw sb16,adlib,pcspk -hda i/doom.vmdk

Previous 0.52 (trunk 391) + slirp

So I got this request to add in some SLiRP to Previous, the NeXT computer emulator.  Sadly work got in the way, and I trashed my windows dev machine.  To make it worse I also trashed my MacBook Air, but with a bit of screwing around I got X-code removed, and re-installed.

So Here is my wonderful work, some 50 lines of code + the SLiRP from Cockatrice all hacked up.

ICMP to 10.0.2.2 seems to work fine, UDP seems to not work, so no DNS.  I don’t know why either.  I can telnet to my BBS just fine, which is about all the testing I’ve done.

Previous to the BBS

Previous to the BBS

Inbound TCP seems to be broken too, but I could be initializing slirp_redirect incorrectly too.

In case you want to follow up on this the NeXT computer forums is the place to be.  Networking with NeXTSTEP is involved.

And for anyone who want’s my files, the source is here, and an OS X 10.10.3 binary is here.  Be sure to install the SDL2 framework ahead of time!

Qemu 2.2.0 for OS X 10.10

So yeah it’s been a while since I pushed out a build for OS X, and well I did a fresh install of OS X 10.10 on my MacBook, and this took a while to compile.  And I ran into my favorite OSS dependancy of glib2 which needs pkg-config to build, and pkg-config needs glib2.

I hate this so much...

I hate this so much…

So for those who want it, here is the build that I’ve only tested on 10.10 .. And I only compiled the i386 emulator.  And here is the larger archive with the rest of the emulators.

I’ve included the dylib’s that I needed in /usr/local/lib … And of course you’ll need LibSDL 1.2‘s framework installed.

It runs Coherent!

It runs Coherent!

And yes, I built it to run Coherent, and it runs pretty well.  The boot time fsck didn’t take 5 minutes to complete.

Cross compiling to i386 Linux ELF from OS X

This isn’t terribly useful for 99.9% of the people out there but I needed to do something creative on an F5.  Luckily they run a somewhat sane version of Linux.

Unfortunately I am stuck on Windows 10 right now, so installing a matching Linux distro is out of the question.  So on my OS X box, I thought I’d just build a cross compiler.  Going back to my DJGPP cross compiler, I thought I’d stick with binutils 2.9.1 and gcc 2.95.3, since they worked so well before.

Plus to flesh it out, you’ll want libc, libg++, and the appropriate Linux includes.  I took all of these from Slackware 3.3 since it’s from around that era.

So on the plus side this cross compiler + library set , will crank out static ELF executables, which makes running things on alien platforms all the better.

On the realistic side, I doubt anyone will need it, but here it is.

Clang didn’t want to build anything this old, but luckily that backported GCC-4.2 has no issues.

Running MS SQL Server 4.21 on OS X.

Yes, you read that right.  Thanks to the power of Crossover (Wine) I’m running SQL 4.21 on OS X.  But the installation is *NOT* straightforward.  Actually it doesn’t install at all.  But you can ‘transport’ a working copy from a Windows machine into Wine, and it’ll run.

The first thing is, if you’ve ever dealt with MSSQL is that it is VERY picky about machine names.  So first install MS SQL 4.21 in a NT 3.1/3.5/3.51/4.0 VM with a name you like. Also remember to set the default client library to TCPIP. Then create a Wine instance on your target box.  Next you’ll need to make a few changes to the registry to force the machine name:

HKEY_CURRENT_USER\Software\Wine\Network

UseDnsComputerName

REG_SZ N

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName

ComputerName

REG_SZ MSDE

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName

ComputerName

REG_SZ MSDE

I called my machine MSDE, as I have no imagination.  With those keys in place the next thing to do is grab the service keys..

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SQLServer

and

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SQLMonitor

Then finally the MS SQL product key:

HKEY_LOCAL_MACHINE\Software\Microsoft\SQLServer

The final step was to copy over the c:\sql directory, and create icons for the SQL Server, and the management tool.

To run, start the server first (SQLSERVR.EXE) , then launch the admin tool (SQLADMIN.EXE), and you should (hopefully) be able to connect!

MS SQL Server 4.21 running on OS X

MS SQL Server 4.21 running on OS X

And there we go! Is it useful? Not really, but I mean it is cool! I haven’t tried this with 6.0 or 6.5 but I imagine they should work as well. 7.0 and beyond are more complicated to transpose as they require a great deal of COM integration. In theory they should work.

building NACL stuff on OS X

this wasn’t too much fun as it is a constantly moving target and documentation slides by the side… So no doubt by the time someone else reads this it’ll be obsolete.

Some of the steps you can follow from here…

https://developers.google.com/native-client/sdk/download

the output will be completely different though.  Something like this:

$ ./naclsdk list
Bundles:
I: installed
*: update available

I sdk_tools (stable)
vs_addin (dev)
pepper_27 (post_stable)
pepper_28 (post_stable)
pepper_29 (post_stable)
pepper_30 (post_stable)
pepper_31 (stable)
pepper_32 (dev)
pepper_canary (canary)

All installed bundles are up-to-date.

I chose to install the stable branch, pepper_31 in this case (the google page talks about version 14 being stable, so a LOT has changed).

./naclsdk update pepper_31

And two big files will download and unpack in your directory.

You will also need depot_tools, a collection of scripts google uses for git/svn.  Be sure to setup your path & environment for NACL building:

$ cat /Users/neozeed/.profile
NACL_SDK_ROOT=/Users/neozeed/src/nacl_sdk/pepper_31/
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/neozeed/src/depot_tools

export NACL_SDK_ROOT PATH

And of course you’ll want to check out the nacl ports.  With everything in place the download should at least work correctly

mkdir naclports
cd naclports
gclient config –name=src https://chromium.googlesource.com/external/naclports.git
gclient config http://naclports.googlecode.com/svn/trunk/src
gclient sync

And then before you go racing off trying to build something, as it stands right now (December 2013, pepper v.31), there is a big ‘libc’ change going on, and most of the nacl stuff will not build.  You’ll need to issue something like this:

NACL_GLIBC=1 make nethack

The other major roadblock I’ve seen so far is that zlib will not build correctly, it’ll want to build a static version of itself, because the configure script is still seeing your PC as OS X, not as a nacl build.  I found the easier way was to rename the Darwin section, and then remove all the Linux bits in the OS detection and rename that to Darwin…

Linux | linux | GNU | GNU/*) LDSHARED=${LDSHARED-“$cc -shared -Wl,-soname,libz.so.1”};;

becomes

Darwin*) LDSHARED=${LDSHARED-“$cc -shared -Wl,-soname,libz.so.1”};;

And further down just rename

Darwin*) shared_ext=’.dylib’

to

XXXDarwin*) shared_ext=’.dylib’

And rebuilt zlib and now you should get the dynamic library everything else hinges on.

I hope this helps someone else..