Woo!, glad I could be of some assistance getting that ball rolling...

Cheers!

I know the thread is old, but I wanted to say that the latest version (1.69.14 using libc) compiles and runs fine after converting to macho32 format (using agner fog object converter).

The steps:

1. download agner fog object converter from http://www.agner.org/optimize/

2. after unziping it, unzip the source. And compile it using


The -m32 is necesary on the newest version of Snow Leopard as it defaults to 64 bit compilation. -m32 tells it we want a 32 bit exe.

3. use objconv to convert the fasm.o to macho32 format


-fmacho32 Convert to macho32 object format.
-nu Depending the target it eliminates or adds an '_' at the start of symbols. (in this case it added the _ at the start of main)

4. Compile fasm


I tested assembling fasm itself and it worked. I guess that the next step would be support for macho32 and macho64 object format on fasm itself.

the macho format is documented at: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

EDIT:
Unfortunately while the fas tools (listing, prepsrc, symbols) build using this method. They throw a segmentation fault when run. gdb says is because of a misaligned stack.

EDIT:
I feel silly, It was the ccall macro. it was updated for fasm.asm but not for the tools. changing the macro with the one of fasm.asm made them work.

Hi,

I've been successfuly using a fasm binary created with this method on my Snow Leopard 64bit system.
However after upgrading to lion it just won't assemble anything anymore.

I can run fasm just fine (without any input files),
but once I try to assemble some code I end up with:



I'll try to debug the issue a little further but any help is greatly appreciated.

P.S. yes, I've also tried rebuilding fasm (32bit binary) on lion - same result

Cheers,
Shirk

@Shirk: Two things to try
1) Try to assemble an empty file and then try to assemble "nop"
2) Try modifying memory amount given to FASM

If your "some code" is a macro that generates a lot of memory-traffic so-to-speak, then increasing memory will help.

...and btw, did you notice the date of the previous reply. Maybe they've forgotten all about it

Are there any update on native Mach-O support?

Bummer.
I just joined this forum today hoping to learn FASM on my Mac. Guess it's out of the question now. I tried but seem to get errors.

I'll stay tuned but Tomasz has already done so much incredible work with this, it seems wrong that nobody has ported it to Mac. It's beyond my capabilities unfortunately. It looks like an amazing assembly language and makes me regret getting a Mac in some ways. Never stray from Linux people. It's the foundation, the bedrock for all decent programming.

you could install virtualbox or etc virtualization software to get a taste of it, before really tasting it inside macos.

bakedbadger,
Lol I have a Mac, I use Wine.
Btw the IDE works fine with Wine.
Porting fasm to Mac shouldn't be tough, but I have little
experience with the API.
The MachO format is like a disk image, DMG is the extension right? (I think?) which contains application files.

I've used and am familiar with wine (I used to play Battlefield Vietnam on Linux) but making assembler go through a virtualisation layer kind of defeats the purpose for me. Do the assembled files depend on wine too?

Mach does use its own built in assembler - an as and objective c variant - but I can't see it being faster than FASM if it uses obj c.... NASM works fine for Mac so I think I'll go with that for now. My feeling is they're all inferior to FASM.

Yes. Sadly you can't compile native Mac OS programs until now since Mach O executables aren't supported. So they will have to rely on wine.

Why is it that each time I see that I get a "Village People" song in my head?

It is a big misunderstanding. In Wine, there is no visualization layer. The code runs natively on the CPU of the computer.

There is API layer, but using GTK or Qt for the GUI is the same. In fact, some programs run in Wine even faster than in Windows.