ZSNES on OS X (No PPC Macs Allowed!)

BRPXQZME · Post by **BRPXQZME** » Tue May 30, 2006 5:17 am

I got my MacBook, and wanted an SNES emulator (and considering similar situations, who here wouldn't?). Well, there's Snes9x and that worked all dandy... but that's also the reason I even got the MacBook in the first place (my PowerBook G3 caught on fire during a really good round of Super Street Fighter II, and I still have nightmares about it). So, I say that it's about time I go about it the hard way... and get ZSNES, now that my Mac runs on an Intel chip.

The only object of the game here is to get it compiled and running, not get a full-blown OS X app just yet... that will take a bit of work (although getting it not in X11 would be desirable). There aren't even checks in place to insure that

Now let's just say that I'm astonished at how far my compile gets with SVN R3122 (hey, nobody else has ZSNES working natively on a Mac either). In fact, it compiles with only a few glitches and hitches, some of which I can even dance around. However, a code wizard I am not, so I think I will just post what I have been able to do so far and look around desperately for help!

First, there is svn checkout:

Code: Select all

$ svn co https://svn.bountysource.com/zsnes/trunk/ zsnes
....<blah blah blah>....
$ cd zsnes/src/

Then, there is the application of the (actually pretty small) patch that I made to the code to get this puppy compiled most of the way: (get it here EDIT: Do not use this patch, look at EDIT1 and put in that patch)

Code: Select all

$ patch -p0 < ~/zsnes_osx86-0.patch

Then we do this dealy to get our configure script...

Code: Select all

$ aclocal
<bunch of warnings that don't seem to hurt anything on my Gentoo computers, and probably have nothing to do with the stop sign I get later>
$ autoconf

Now that that's run without a gripe, let's run ./configure and hope for the best! (commentary to the right in red)

Code: Select all

$ ./configure

results wrote:checking build system type... i386-apple-darwin8.6.2 I've also seen i686-apple-darwin8 in places, but this seems okay
checking host system type... i386-apple-darwin8.6.2
checking target system type... i386-apple-darwin8.6.2
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc GCC 4.0.1 Apple build 5341 to be exact. It has its own quirks, has the GCC4 propensity for flipping out when you use code that's a little off-standard, but its the only one an Intel Mac user really should have any luck using. From Xcode 2.3.
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for nasm... nasm
checking for sdl-config... /sw/bin/sdl-config It's SDL 1.2.9 installed from fink. To potential Mac power users: don't leave home without having either fink or darwinports! You'll never be able to compile very much without 'em!
checking for SDL - version >= 1.2.0... yes
checking for zlib - version >= 1.1.0... yes Comes with OS X
checking for libpng - version >= 1.2.0... no I have this from fink, but it isn't detected... but also, we can solve that problem later
rm: conf.libpngtest: No such file or directory
checking how to run the C preprocessor... gcc -E
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for glGetError in -lGL... yes
checking for OpenGL... yes But for some reason, it won't detect this later on during the compile... so keep reading
checking for JMA support... yes
checking for cpu info... failed uh ohs!!!
checking if you want gdb friendly executable... no
checking if you want crazy optimizations... no
checking which cpu architecture to optimize for... guessing i386
configure: WARNING: This is not what you want, use --target or force-arch Not good, but not a show-stopper either
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether sys/types.h defines makedev... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h

ZSNES vpre1.43

SDL support Version 1.2.9 OK!
NASM support NASM version 0.98.40 (Apple Computer, Inc. build 9) compiled on Apr 6 2006 nasm from Xcode 2.3
zlib support Version 1.2.3 zlib that comes from OS X
PNG support Disabled, library not found Not good, but not a showstopper
OpenGL support Yes I think this will turn out to be OpenGL+X11, but I can't tell
JMA support Yes Thank goodness!

The binary will be installed in /usr/local/bin

Configure complete, now type 'make' and pray. This is the proper course of action!

But then we hit one snag: Apple's gcc -s is a little buggy:

Code: Select all

$ make
g++  -pipe -I. -I/usr/local/include -I/usr/include -D__UNIXSDL__ -D__MACOSX__ -arch i386  -I/sw/include/SDL -D_THREAD_SAFE -DNO_PNG -D__OPENGL__ -O3 -fomit-frame-pointer -s -march=i386 -fno-rtti -o parsegen parsegen.cpp
./parsegen -D__UNIXSDL__ -cheader psrhead/cfg.h -fname cfg t_cfg.c cfg.psr
dyld: lazy symbol binding failed: lazy pointer not found
dyld: lazy pointer not found
make: *** [cfg.o] Trace/BPT trap

That can be automagically fixed later. For now, we will help the compile along... just remove the -s from all those options and run it manually, then run strip to do what it was trying to do but failed at:

Code: Select all

$ g++  -pipe -I. -I/usr/local/include -I/usr/include -D__UNIXSDL__ -D__MACOSX__ -arch i386  -I/sw/include/SDL -D_THREAD_SAFE -DNO_PNG -D__OPENGL__ -O3 -fomit-frame-pointer -march=i386 -fno-rtti -o parsegen parsegen.cpp
$ strip parsegen

And that's all there is to getting past that....

Code: Select all

$ make
...<blah blah blah>...
In file included from cfgload.c:24:
gblhdr.h:83:20: error: GL/gl.h: No such file or directory
make: *** [cfgload.o] Error 1

Crud. Okay, re-run configure (if you're following along at home, this line is the one you want):

Code: Select all

$ ./configure --with-opengl-prefix=/usr/X11R6
<blahhhhhh>
$ make
<making making making>
<more making>
<it gets to that "let's link everything together in one piece!" step>
g++ -o zsnes cfg.o cfgload.o debug.o endmem.o init.o initc.o md.o patch.o ui.o uic.o vcache.o version.o zloader.o zmovie.o zstate.o chips/sfxproc.o chips/fxemu2.o chips/dsp1proc.o chips/fxemu2b.o chips/fxemu2c.o chips/fxtable.o chips/sa1proc.o chips/sa1regs.o chips/dsp1emu.o chips/st10proc.o chips/seta10.o chips/dsp2proc.o chips/sdd1emu.o chips/c4emu.o chips/dsp4proc.o chips/dsp4emu.o chips/dsp3proc.o chips/dsp3emu.o chips/obc1emu.o chips/obc1proc.o cpu/dma.o cpu/dsp.o cpu/dspproc.o cpu/execute.o cpu/executec.o cpu/irq.o cpu/memory.o cpu/memtable.o cpu/spc700.o cpu/stable.o cpu/table.o cpu/tableb.o cpu/tablec.o gui/gui.o gui/guifuncs.o gui/menu.o effects/burn.o effects/water.o effects/smoke.o jma/7zlzma.o jma/crc32.o jma/iiostrm.o    jma/inbyte.o jma/jma.o jma/lzma.o       jma/lzmadec.o jma/winout.o jma/zsnesjma.o mmlib/linux.o mmlib/mm.o  video/makev16b.o video/makev16t.o video/makevid.o video/mode716.o video/mode716b.o video/mode716d.o video/mode716e.o video/mode716t.o video/mode7.o video/mode7ext.o video/mv16tms.o video/m716text.o video/newg162.o video/newgfx.o video/newgfx16.o video/newgfx2.o video/procvid.o video/procvidc.o video/sw_draw.o video/2xsaiw.o video/hq2x16.o video/hq2x32.o video/hq3x16.o video/hq3x32.o video/hq4x16.o video/hq4x32.o video/ntsc.o linux/copyvwin.o linux/sdlintrf.o linux/sdllink.o linux/gl_draw.o linux/sw_draw.o linux/zfilew.o linux/safelib.o dos/debug.o dos/joy.o dos/vesa2.o zip/unzip.o zip/zpng.o  -pipe -I. -I/usr/local/include -I/usr/include -D__UNIXSDL__ -D__MACOSX__ -arch i386  -I/sw/include/SDL -D_THREAD_SAFE -DNO_PNG -I/usr/X11R6/include -D__OPENGL__ -O3 -fomit-frame-pointer -s -march=i386 -fno-rtti  -L/usr/local/lib -L/usr/lib  -lz -L/sw/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -Wl,-framework,OpenGL -L/usr/X11R6/lib -lGL
/usr/bin/ld: Undefined symbols:
GUIDoReset
InitDSP2
InitFxTables
SPC7110Load
initregr
initregw
outofmemfix
InitSPC
MMXCheck
StartUp
SystemInit
WaitForKey
allocmem
init
outofmemory
ChangetoLOADdir
ProcessSoundBuffer
_ManyMouseDriver_hidmanager
collect2: ld returned 1 exit status
make: *** [main] Error 1
$ <hit head on keyboard and fall out of chair>

And that's pretty much where I'm stuck. Any words of wisdom that will coax it into linking? (so then we can get on with the testing?)

Note that I tried doing this with the 1.42 source before thinking better of it and getting it from SVN. The final link is also where that finally died (hence why a lot of this is essentially pre-packaged; I spent all day fiddling with this).

EDIT1: Okay, I've squashed all but one of these now... This is the patch that makes up all the changes I've made to the ZSNES code right (here). Now someone just needs to figure out what's going on with this one and we just might be in business!

Code: Select all

$ make
g++ -o zsnes cfg.o cfgload.o debug.o endmem.o init.o initc.o md.o patch.o ui.o uic.o vcache.o version.o zloader.o zmovie.o zstate.o chips/sfxproc.o chips/fxemu2.o chips/dsp1proc.o chips/fxemu2b.o chips/fxemu2c.o chips/fxtable.o chips/sa1proc.o chips/sa1regs.o chips/dsp1emu.o chips/st10proc.o chips/seta10.o chips/dsp2proc.o chips/sdd1emu.o chips/c4emu.o chips/dsp4proc.o chips/dsp4emu.o chips/dsp3proc.o chips/dsp3emu.o chips/obc1emu.o chips/obc1proc.o cpu/dma.o cpu/dsp.o cpu/dspproc.o cpu/execute.o cpu/executec.o cpu/irq.o cpu/memory.o cpu/memtable.o cpu/spc700.o cpu/stable.o cpu/table.o cpu/tableb.o cpu/tablec.o gui/gui.o gui/guifuncs.o gui/menu.o effects/burn.o effects/water.o effects/smoke.o jma/7zlzma.o jma/crc32.o jma/iiostrm.o    jma/inbyte.o jma/jma.o jma/lzma.o       jma/lzmadec.o jma/winout.o jma/zsnesjma.o mmlib/linux.o mmlib/mm.o  video/makev16b.o video/makev16t.o video/makevid.o video/mode716.o video/mode716b.o video/mode716d.o video/mode716e.o video/mode716t.o video/mode7.o video/mode7ext.o video/mv16tms.o video/m716text.o video/newg162.o video/newgfx.o video/newgfx16.o video/newgfx2.o video/procvid.o video/procvidc.o video/sw_draw.o video/2xsaiw.o video/hq2x16.o video/hq2x32.o video/hq3x16.o video/hq3x32.o video/hq4x16.o video/hq4x32.o video/ntsc.o linux/copyvwin.o linux/sdlintrf.o linux/sdllink.o linux/gl_draw.o linux/sw_draw.o linux/zfilew.o linux/safelib.o dos/debug.o dos/joy.o dos/vesa2.o zip/unzip.o zip/zpng.o  -pipe -I. -I/usr/local/include -I/usr/include -D__UNIXSDL__ -D__MACOSX__ -arch i386  -I/sw/include/SDL -D_THREAD_SAFE -DNO_PNG -I/usr/X11R6/include -D__OPENGL__ -O3 -fomit-frame-pointer -s -march=i386 -fno-rtti  -L/usr/local/lib -L/usr/lib  -lz -L/sw/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -Wl,-framework,OpenGL -L/usr/X11R6/lib -lGL
/usr/bin/ld: Undefined symbols:
_ManyMouseDriver_hidmanager
collect2: ld returned 1 exit status
make: *** [main] Error 1

EDIT2: Hm, doesn't look like we'll want ManyMouse code for OS X stepping in and making things complicated yet, so I commented that line out. Now I get this funny error:

Code: Select all

/usr/bin/ld: ui.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_malloc
collect2: ld returned 1 exit status
make: *** [main] Error 1

Post by **Nach** » Tue May 30, 2006 1:01 pm

Thanks for doing this.
I really need to get my OS X working...

I can fix archopt, I know the issues with OS X.
Can probably fix the rest with your patch once I get a machine set up too.
Thanks.

adventure_of_link · Post by **adventure_of_link** » Tue May 30, 2006 1:04 pm

You have an Intel Mac Nach ?

Interesting..

Also, to the OP: How does a Mac catch on fire during a Street Fighter Session..

Post by **Nach** » Tue May 30, 2006 1:22 pm

http://nsrt.edgeemu.com/archopt.zip

Compile:

Code: Select all

gcc -Wall -W -o archopt archopt.c 
gcc -Wall -W -o archopt-no-proc archopt-no-proc.c

Let me know if they both compile. And what each program outputs when you run them.

And if you happen to have /proc/cpuinfo, please include the contents of that as well.

SquareHead · Post by **SquareHead** » Tue May 30, 2006 2:46 pm

adventure_of_link wrote:You have an Intel Mac Nach ?

Interesting..

Also, to the OP: How does a Mac catch on fire during a Street Fighter Session..

Does he really need one now that theres versions of Intel Compatible OSX floating around the intarweb?

adventure_of_link · Post by **adventure_of_link** » Tue May 30, 2006 2:55 pm

and who said Nach is pirating stuff

BRPXQZME · Post by **BRPXQZME** » Tue May 30, 2006 4:48 pm

adventure_of_link wrote:How does a Mac catch on fire during a Street Fighter Session..

Freak accident involving a piece of plastic that became dislodged months before I got the Pismo. It gets stuck at a position where heat builds up, a good round of Snes9x-powered SFII taxes the Rage 128 Mobility, causing more heat than usual, and then it all went boom and arrrgh, accompanied by smoke and the wonderful smell of burning plastic.

Nach wrote:Let me know if they both compile. And what each program outputs when you run them.

They compile fine and both output "pentium-m", which makes sense because that's what the Intel Core Duo is made of.

And if you happen to have /proc/cpuinfo, please include the contents of that as well.

I don't have a Linux livecd on hand, so there is no procfs.... but it's probably just like other Pentium M and Core Duo systems in terms of capabilities. In case you find any of it useful, though, you can look at an abbreviated list of hardware specs here, but it isn't really like /proc/cpuinfo at all.

The problem with malloc is still confusing. And weird. But then again, I get this funny feeling that not too many major NASM-based projects have really gone Mac just yet.

(If the ZSNES devs need temporary remote access to Intel OS X hardware, I might be able to cut a deal somewhere or other, being that I know the guy who runs osx86project and my school is planning on getting a Mac Mini cluster soon...)

adventure_of_link · Post by **adventure_of_link** » Tue May 30, 2006 5:02 pm

you can download Damn Small Linux, and it should give you access to /proc/cpuinfo.

Post by **Nach** » Tue May 30, 2006 5:29 pm

BRPXQZME wrote:
And if you happen to have /proc/cpuinfo, please include the contents of that as well.
I don't have a Linux livecd on hand, so there is no procfs....

I wanted Mac OS X 86 /proc/cpuinfo IFF it existed. Don't bother with Linux.

also, SVN is up and tell me how it's working now.

EDIT: Doubleposting... Nach... I'm suprised at you

bztunk · Post by **bztunk** » Tue May 30, 2006 7:44 pm

if you want to debug configure's failures, you should post configure.log (generated after a ./configure, of course).

BRPXQZME · Post by **BRPXQZME** » Tue May 30, 2006 8:16 pm

Okay, so from a clean SVN checkout, aclocal, autoconf, ./configure --with-opengl-prefix=/usr/X11R6, make...

- Still coughs on configure a little... no libpng (duh, didn't even begin work on that bit). Forgot to mention that when the opengl prefix is specified, an odd message comes up... but it's not that important:

Code: Select all

checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
./configure: line 4036: LDFLAGS- -L/usr/local/lib -L/usr/lib  -lz -L/sw/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -Wl,-framework,OpenGL -L/usr/X11R6/lib: No such file or directory

- It detects pentium-m optimization. Good...
- Still runs into problem with 'gcc -s' and parsegen. This is an Apple bug as far as I can tell, and I haven't a clue how to work around it in code; compiling parsegen separately without the -s flag works fine.
- Dies with

Code: Select all

/usr/bin/ld: Undefined symbols:
_ManyMouseDriver_hidmanager
collect2: ld returned 1 exit status
make: *** [main] Error 1

- It is probably okay to comment out the offending line in mmlib/mm.c for now; the Mac version requires pulling in stuff I don't know how to pull in, and would only complicate the matter before zsnes even finishes compiling. Although it would probably work just fine after that business is taken care of....
- Assuming the above, it dies the same way as it did before I went to bed:

Code: Select all

/usr/bin/ld: ui.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_malloc
collect2: ld returned 1 exit status
make: *** [main] Error 1

- And for that, I'm still trying to figure out what's going on. Weird linking idiosyncrasy, probably.

Also, um, config.log, yes. Where have my wits gone off to?

EDIT: Ha! I have an executable! Adding this flag to the huge final command made it ignore the external relocation entries:

Code: Select all

-Wl,-read_only_relocs,warning

Now on to the fun part...

Code: Select all

$ ./zsnes 

ZSNES vPre 1.43, (c) 1997-2006, ZSNES Team
Be sure to check http://www.zsnes.com/ for the latest version.
Please report crashes to zsnes-devel@lists.sourceforge.net.

ZSNES is written by the ZSNES Team (See AUTHORS.TXT)
ZSNES comes with ABSOLUTELY NO WARRANTY.  This is free software,
and you are welcome to redistribute it under certain conditions;
please read 'LICENSE.TXT' thoroughly before doing so.

Use ZSNES -? for command line definitions.

This is a work in progress build. It contains code which
May or may not be complete
Starting Mouse detection.
/dev/input does not exist or is inaccessable
ManyMouse: -1 mice detected.
Illegal instruction

Well, it's a start!

EDIT2: Looking at SVN, nach is a couple of steps ahead of me. Awesome.

Post by **Nach** » Wed May 31, 2006 12:00 am

Please test SVN now and let me know how the build works.

As for the once you have the binary, if it crashes please do as follows:
rebuild with debug enabled, I do "./configure debug=yes", but I'm not sure if that's our official method or not. I'm also not certain if stabs works with OS X.
Let me know how that goes.
Anyways once you have a debug binary built (if our debug process doesn't work, then compile regular, but no -s on link then), run in GDB, and see if you can get a backtrace.

BRPXQZME · Post by **BRPXQZME** » Wed May 31, 2006 3:20 am

Upgraded to R3134....

'./configure debug=yes' doesn't seem to do anything.

'./configure --enable-debug' does.

With debug enabled, the build goes clean all the way up til' it has to use nasm. Because nasm doesn't have stabs for Mach-O

GCC has stabs support, considering that Apple mentions it, so this is a problem with nasm, I suppose. So just removing the -s flag for now (I guess I could remove the stabs option from NFLAGS, but nasm still doesn't produce debug info anyway)...

It works great up until it tries to build mmlib/osx.c; this is because it wants manymouse.h instead of mm.h. One trivial change later, and it makes all the way up to the final link...

Code: Select all

g++ -o zsnes <all the .o files> -pipe -I. -I/usr/local/include -I/usr/include -D__UNIXSDL__ -D__MACOSX__ -arch i386  -I/sw/include/SDL -D_THREAD_SAFE -DNO_PNG -I/usr/X11R6/include -D__OPENGL__ -O3 -fomit-frame-pointer  -march=pentium-m -fno-rtti  -L/usr/local/lib -L/usr/lib  -lz -L/sw/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -Wl,-framework,OpenGL -L/usr/X11R6/lib -lGL
/usr/bin/ld: Undefined symbols:
_IOCreatePlugInInterfaceForService
_IODestroyPlugInInterface
_IOIteratorNext
_IOMasterPort
_IONotificationPortCreate
_IONotificationPortGetRunLoopSource
_IOObjectRelease
_IORegistryEntryCreateCFProperties
_IORegistryEntryGetParentEntry
_IOServiceAddInterestNotification
_IOServiceAddMatchingNotification
_IOServiceMatching
collect2: ld returned 1 exit status
make: *** [main] Error 1

Hm, looks like it wants IOKit. Now I don't know how this is supposed to get dragged in, but adding in the flag -Wl,-framework,IOKit manually gives us a more innocent error:

Code: Select all

/usr/bin/ld: ui.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_malloc_size
collect2: ld returned 1 exit status

Adding in the magical -Wl,-read_only_relocs,warning flag, demoting errors to warnings....

Code: Select all

/usr/bin/ld: warning ui.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_malloc_size
/usr/bin/ld: warning linux/sdlintrf.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_putchar
_getchar

Running the resulting zsnes binary:

Code: Select all

$ ./zsnes 

ZSNES vPre 1.43, (c) 1997-2006, ZSNES Team
Be sure to check http://www.zsnes.com/ for the latest version.

ZSNES is written by the ZSNES Team (See AUTHORS.TXT)
ZSNES comes with ABSOLUTELY NO WARRANTY.  This is free software,
and you are welcome to redistribute it under certain conditions;
please read 'LICENSE.TXT' thoroughly before doing so.

Use ZSNES -? for command line definitions.

This is a work in progress build. It contains code which
May or may not be complete
ManyMouse: 2 mice detected.
Using ManyMouse for:
Mouse 0: Apple Internal Keyboard / Trackpad
Mouse 1: Trackpad
Illegal instruction

Okay... (woot! I have two mice?! I'll save that for later inspection...) so running it in GDB now.

Code: Select all

(gdb) run
Starting program: /Users/brp/zsnes/src/zsnes 
Reading symbols for shared libraries ...........................................................................+... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done

ZSNES vPre 1.43, (c) 1997-2006, ZSNES Team
Be sure to check http://www.zsnes.com/ for the latest version.

ZSNES is written by the ZSNES Team (See AUTHORS.TXT)
ZSNES comes with ABSOLUTELY NO WARRANTY.  This is free software,
and you are welcome to redistribute it under certain conditions;
please read 'LICENSE.TXT' thoroughly before doing so.

Use ZSNES -? for command line definitions.

This is a work in progress build. It contains code which
May or may not be complete
Reading symbols for shared libraries . done
ManyMouse: 2 mice detected.
Using ManyMouse for:
Mouse 0: Apple Internal Keyboard / Trackpad
Mouse 1: Trackpad

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x8fe136e4 in __dyld_stub_binding_helper_interface ()
(gdb) bt
#0  0x8fe136e4 in __dyld_stub_binding_helper_interface ()
#1  0x00000000 in ?? ()

Okay, so maybe not the world's easiest nut to crack. Maybe... let's put in -g where -s used to be. At least GCC will give debug info, right? Well, unfortunately, it gives the same result. Since nasm doesn't produce debug info for Mach-O, it makes this kind of difficult.

Post by **pagefault** » Wed May 31, 2006 3:24 am

Dumb question but are you running this as a 64-bit app. Because that won't work at all. ZSNES uses some instructions that don't even exist in 64-bit mode.

BRPXQZME · Post by **BRPXQZME** » Wed May 31, 2006 3:47 am

Uh, I don't think it is (a dumb question, that is; there is such a thing IMO, but that's not it).

That's not what's going on. The Intel Core Duo is 32-bit; the 64-bit version comes out in July and August (yay!), finally driving out the last Pentiums (and good riddance, I say!). Although it a semi-reasonable question, seeing as to how Apple started using GCC4 for the 64-bit capabilities (and man are those G5's sweet), everything being compiled here is almost certainly 32-bit.

Apparently, though, OS X is pretty annoyingly strict about things like 16-byte aligned calls and such. I hear the guys who ported mupen64 got headaches over details like that.

Post by **Nach** » Wed May 31, 2006 12:52 pm

Let me know how latest SVN works.

BRPXQZME · Post by **BRPXQZME** » Thu Jun 01, 2006 3:30 am

Hrm...

Okay, the -lcc_dynamic flag doesn't work. The lib doesn't exist for x86 targets (or all X.4 for that matter). Pretty much all the other changes are okay, after patching gui/gui.asm to put a few Windows/DOS-only things back in their places (man, that is one big commit!).

The -dynamic flag could be added, though, I guess (it's the default anyway, so not adding it won't hurt anything). Still gives this:

Code: Select all

g++ -o zsnes <objs> -pipe -I. -I/usr/local/include -I/usr/include -D__UNIXSDL__ -D__MACOSX__ -arch i386  -I/sw/include/SDL -D_THREAD_SAFE -DNO_PNG -I/usr/X11R6/include -D__OPENGL__ -O3 -fomit-frame-pointer -s -march=pentium-m -fno-rtti  -L/usr/local/lib -L/usr/lib -framework Carbon -framework IOKit -dynamic  -lz -L/sw/lib -lSDLmain -lSDL -Wl,-framework,Cocoa -Wl,-framework,OpenGL -Wl,-read_only_relocs,warning -L/usr/X11R6/lib -lGL
/usr/bin/ld: warning ui.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_malloc_size
/usr/bin/ld: warning linux/sdlintrf.o has external relocation entries in non-writable section (__TEXT,__text) for symbols:
_putchar
_getchar

Apparently, though (according to the ld man page), the -dynamic flag only fights the relocation problem for objects compiled under the -dynamic flag; assembly code is apparently read-only to the dynamic linker. Here's the relevant section, just in case you can catch a detail I can't:

-read_only_relocs treatment
Specifies how relocation entries in read-only sections are to be treated when -dynamic is used. To get the best possible sharing, the read-only sections should not have any relocation entries. If they do, the dynamic linker will write on the section. Having relocation entries appear in read-only sections is normally avoided by compiling with the option -dynamic. But in such cases non-converted assembly code or objects not compiled with -dynamic relocation entries will appear in read-only sections. The treatment can be: error, warning, or suppress. Which cause [sic] the treatment of relocation entries in read-only sections as either, errors, warnings, or suppressed messages. The default is to treat these as errors.

Going through and ignoring those errors as warnings still makes the zsnes binary crash just like before, but I think the LDFLAGS are on the right track.

(and also, this patch may be relevant to your interests; the linker got confused by a few extraneous EXTSYM entries)

Post by **grinvader** » Thu Jun 01, 2006 3:47 am

BRPXQZME wrote:(man, that is one big commit!).

Yeah, I love you too. ;)

Post by **Nach** » Thu Jun 01, 2006 12:54 pm

BRPXQZME wrote: Apparently, though (according to the ld man page), the -dynamic flag only fights the relocation problem for objects compiled under the -dynamic flag; assembly code is apparently read-only to the dynamic linker. Here's the relevant section, just in case you can catch a detail I can't:
-read_only_relocs treatment
Specifies how relocation entries in read-only sections are to be treated when -dynamic is used. To get the best possible sharing, the read-only sections should not have any relocation entries. If they do, the dynamic linker will write on the section. Having relocation entries appear in read-only sections is normally avoided by compiling with the option -dynamic. But in such cases non-converted assembly code or objects not compiled with -dynamic relocation entries will appear in read-only sections. The treatment can be: error, warning, or suppress. Which cause [sic] the treatment of relocation entries in read-only sections as either, errors, warnings, or suppressed messages. The default is to treat these as errors.

Thanks, that explains a quite a bit. NASM isn't generating code that is going to link properly like this.

BRPXQZME wrote: Going through and ignoring those errors as warnings still makes the zsnes binary crash just like before, but I think the LDFLAGS are on the right track.

Those errors should be gone now, let me know how SVN is.

And thanks for your help.

Post by **Nach** » Thu Jun 01, 2006 4:40 pm

I'll be going away for the weekend, so post, but I won't respond till Sunday or so.
Hope it's good news though.
Today is my 8th anniversary of using ZSNES regularly, would be nice if it would also be the day ZSNES started working on OSX

Anyways, see you.

BRPXQZME · Post by **BRPXQZME** » Fri Jun 02, 2006 3:27 am

Alas, the new additions don't change the results at all (although they do their part bit by bit).

But I have good news!

You can save 15 hours off your development cycle by using a real Intel Mac!

Yeah, 8 mac minis arrived at school and they'll be set up pretty soon. There's a possibility we could facilitate a few unused cycles once the systems are production stable (the main problem IMO being that they'll be surrounded by teenage males with inhibition abilities comparable to those of drunks five days a week; on the other hand, we're all ZSNES fans out here anyway). In the meantime, I'll be trying to pin down where these errors come from.

(oh, and despite my 8th full year of using emulation being only a few months away and being well into my 5th year leeching off the open-source effort, this is pretty much the first time I've actually tried to take either anywhere. It's nice for me. Eight years using one project is certainly a testament to dedication!)