OSDev.org

So, for reasons I don't care to explain, I want to be able to compile mach-o binaries under, of all places, Windows. I could reboot into OS X every time I want to compile something, but that's too much of a PITA, especially since technically I shouldn't be running it anyway (not a Mac). It would be nice if I could have those fancy "fat" files (that have both Intel and PPC code) but it's not necessary and probably would be more trouble than it's worth. I need Intel mach-o files, but the GNU GCC page only lists the PPC architecture as a target (under powerpc-*-darwin* or whatever).

My questions are: Could the powerpc-* thing be misleading me into thinking it's powerpc only (i.e. using this option might also give me the intel platform too)? Can I use the GCC 4.4.0 source I just downloaded (not solely for this)? If so, what options do I need to configure with to do it? And if not, where can I get one that I can use to cross compile?

I'm terribly sorry if any of this can be found with a quick Google, but I'm not as good with it as I'd like, and I'd rather not have downloaded 300MB of stuff and end up having to also download a completely different package to do what I want.

Firestryke31 wrote:So, for reasons I don't care to explain, I want to be able to compile mach-o binaries under, of all places, Windows. I could reboot into OS X every time I want to compile something, but that's too much of a PITA, especially since technically I shouldn't be running it anyway (not a Mac). It would be nice if I could have those fancy "fat" files (that have both Intel and PPC code) but it's not necessary and probably would be more trouble than it's worth. I need Intel mach-o files, but the GNU GCC page only lists the PPC architecture as a target (under powerpc-*-darwin* or whatever).

My questions are: Could the powerpc-* thing be misleading me into thinking it's powerpc only (i.e. using this option might also give me the intel platform too)? Can I use the GCC 4.4.0 source I just downloaded (not solely for this)? If so, what options do I need to configure with to do it? And if not, where can I get one that I can use to cross compile?

I'm terribly sorry if any of this can be found with a quick Google, but I'm not as good with it as I'd like, and I'd rather not have downloaded 300MB of stuff and end up having to also download a completely different package to do what I want.

I've been working to help port the GNU toolchain (gcc/binutils/etc) to support Mach-O. Nobody as far as I know wants, needs or cares to have a Mach-O toolchain. Currently, Apple uses a heavily modified version of gas, and their own dynamic linker. As well, certain aspects of the Mach-O format don't easily map to anything GNU ld has, so that would require a heavy rewrite. As well, since the Linux kernel has no ability to load Mach-O binaries (although patches have been submitted). Nasm/Yasm can output Macho(32,64) but nothing can link nor run them. Bummer.

I did glance at the Mach v4 system, but it's rather late here and I have to go into work tomorrow, so I didn't get a chance to try anything out.

The reason I want a Mach-o capable compiler is that the boot system I have on my computer that lets me run OS X will load and run a Mach-o file at boot, and so I wanted to poke around in the Mac pre-boot environment to see what things were like. Maybe if I can get one I could try my hand at my own Mach based OS...

Firestryke31 wrote:I did glance at the Mach v4 system, but it's rather late here and I have to go into work tomorrow, so I didn't get a chance to try anything out.

The reason I want a Mach-o capable compiler is that the boot system I have on my computer that lets me run OS X will load and run a Mach-o file at boot, and so I wanted to poke around in the Mac pre-boot environment to see what things were like. Maybe if I can get one I could try my hand at my own Mach based OS...

I think you are confusing Mach and Mach-O. They are not the same.

Does Mach not use Mach-O files? I would think so, seeing as that's (IIRC) where the format came from. I was looking at their compiler, since it doesn't have any of the proprietary stuff built in, so it might work with a bit of tweaking.

Firestryke31 wrote:Does Mach not use Mach-O files? I would think so, seeing as that's (IIRC) where the format came from. I was looking at their compiler, since it doesn't have any of the proprietary stuff built in, so it might work with a bit of tweaking.

http://en.wikipedia.org/wiki/Mach-O

So Mach does use Mach-O files, which is why I'm confused as to why you said this:

I think you are confusing Mach and Mach-O. They are not the same.

I never said they were the same, I just said I looked at the Mach v4 system. I just want to try and get their compiler working under Windows so I can poke around in the OS X (which uses the Mach-O format) pre-boot system.

Edit: I had my laptop with me at work, and it was a slow day, so I just decided to try "configure --target=1486-darwin9" and I am make-ing it now. So far so good, but knowing my luck it will fail on like the very last step in building after 7 hours of doing stuff.

Sorry for the double post, but this is just unrelated from the previous post enough to deserve it.

It seems to be failing on one of these lines in the libiberty makefile: What does the "; @true" part of the config.h rule mean? My makefile syntax is a bit rusty.

Edit: Hack fix: removing the "; @true" allowed compilation to continue...

I'm using make 3.81 for -i686-pc-mingw that I downloaded and compiled because I needed <= 3.80 and my msys install had 3.79.1

It also struggled with this, which I just did manually: Specifically the touch. The x"$(PICFLAG)" resolved to x"" so IDK what that means (does the if fail?).

I get a feeling that there are going to be a few more issues before I'm done...

Firestryke31 wrote: It also struggled with this, which I just did manually:

Code: Select all

stamp-picdir:
	if [ x"$(PICFLAG)" != x ] && [ ! -d pic ]; then \
	  mkdir pic; \
	else true; fi
	touch stamp-picdir

Specifically the touch. The x"$(PICFLAG)" resolved to x"" so IDK what that means (does the if fail?).

I get a feeling that there are going to be a few more issues before I'm done...

if [ x"$(BLEH)" != x ] is a way of testing if variable BLEH is set to a non-null value. So the if should succeed if PICFLAG is set (and "pic" is not currently a directory, due to the [! -d pic]", and fail otherwise.

I.e. are you using position independent code?

Probably not since I'm using the default values. I gave up trying to build GCC on MSYS, and just dumped it all on my Linux box. Now I'm getting everything set up to create a Linux->Windows Cross Compiler, which I will then use to make my Windows->Mach Cross Compiler. And maybe upgrade my MinGW GCC to 4.4.0...

Blarg, I ran out of time and couldn't do what I said above. So instead I completely wiped my MSYS/MinGW install and reinstalled it. Now I'm following the Cross compiler Wiki entry here, and I'm glad to say that so far things are looking much better. Now, however, I'm stuck on one minor issue, and that is that the binutils make step is getting stuck configuring the binutils subdirectory (i.e. binutils-blah/binutils/configure $MyOptions). Specifically it's getting stuck on "checking lex output file root..."

I've got the latest Flex for Windows (2.5.4a), and I think it might be the "for Windows" part that might be causing problems. Other than using Linux (which is no longer an option due to large distance between me and currently off Linux box), what can I do?

The tutorial is written and tested for a Cygwin environment (which also provides flex). I have never tried it on MSYS/MingW.

If I could just figure out why this install of flex won't work (I heard it has problems with a system that uses different endlines, and that might be my problem) then I'll tell you just how well it works for MSYS/MinGW.

It's annoying because I know I had gotten a cross compiler configured and made using that tutorial and MSYS/MinGW at one point, but I don't remember exactly what I did to get it working properly.

Maybe... If I could get the Cygwin Flex without downloading the installer, I might be able to continue...

Might be a dumb question, but why not use the Cygwin environment?

I don't know, there's just something about Cygwin that I don't like. Probably the whole "POSIX emulation" layer instead of trying to use the native interface. It's basically catering to the people that are unwilling to even try to get their programs working in Windows for whatever personal reasons. I prefer my apps to be truly cross-platform, not cross-platform-if-you-install-this-thing. But that's a different thread and I know that Cygwin can compile for MinGW-like targets.

Maybe I'll try compiling Flex myself, and if I need to I'll modify the code to get it to work properly.

Edit: Okay, despite my (admittedly not entirely reasonable) dislike of Cygwin, I went ahead and installed it anyway. Following the wiki article (except using --target=i486-pc-darwin9 and --prefix=/mach to match my MinGW's install to /mingw as well as both with --build=i686-pc-mingw and without) using binutils-2.19.1 I can configure the build but when I do 'make all' it fails to configure ./libiberty due to

configure: error: expected an absolute directory name for --prefix: 0

MSYS 'make all' still freezes at ./binutils configure's "checking lex output root" even when using Cygwin's flex with all the .dll files copied as needed.

Edit 2.0: Well, part of the problem was my choice of triplet. I should have used --target=i686-pc-mach3 instead of i486-pc-darwin9, but I don't know if (and highly doubt that) it will fix any problems. If not, I've got binutils-2.16.1 (which is at least known to work with the target compiler) downloaded, configured, and ready to make. I just wanted to make tools that matched my existing set, which is why I chose 2.19.1 in the first place.

Edit 2.5: O Flex, how I hate thee.
Binutils-2.16.1 stuck in the exact same spot, though now it will at least say it will make ld and whatnot due to the changed target triplet. The test file is simple: Sitting there for a while does nothing, since it doesn't seem to be doing anything in the task manager (no cpu, no mem usage change), it's just stuck. I've tried it with Unix line endings, DOS line endings, it just won't work.

I looked at gcc-3.4.5 just to be ready for when I got to the point where I could start it and it doesn't support the mach3 triplet unless I use the --enable-obsolete option, it only supports the Darwin triplet. Let me get this straight: ld doesn't support configuring for Darwin but it does support Mach, and gcc doesn't support Mach but it does support Darwin? *Bangs head against desk* WHY?! I'd just deal with it except I'm pretty sure it will break the install if I used both mach3-ld and darwin9-gcc together due to all kinds of stupid problems (rename one set, it can't find it's own tools; rename the other set, other set has same problem, keep the names, the sets can't find each other).