Sort of. I can get it to compile after hacking up all of the checks for __LINUX__ to check for __APPLE__ too, but it won't link because NASM in Leopard is messed up. The linker complains that the .o files it creates are not for the same architecture or something like that. I either need to get the .asm stuff compiled with something other than NASM, or install a copy of 10.4 in VMware and use that to compile. I'm as close as I can get for now. I could easily throw in a native GUI myself if I ever get it to link.
Actually I think that's because you need to use "-f macho" instead of "-f elf" in the nasm command line...
Yep! That did the trick. Thanks! I'm really close now. Just a ton of errors related to input. Code (Text): Undefined symbols: "Controller_1D_Down", referenced from: RD_Controller_1_TP.TP_PD_DIR in io_old.o "Controller_2C_Down", referenced from: RD_Controller_2_TP.TP_PC_DIR in io_old.o ....... And so on with 90%+ of them having something to do with Controller Is io_old even supposed to be compiling? Why is it called old?
io_old.asm contains the Teamplayer code. I haven't managed to port it to C correctly yet, so I left it as assembler. Those symbols should be present in io.c... If all else fails, you can remove io_old.asm and get rid of the Teamplayer references from io.c. You won't be able to use the Teamplayer adapter, but not many games used it anyway.
I think the problem lies deeper than that. For some reason, all of the remaining errors involve the .asm files being unable to "see" externs defined in C files. I went and unrolled your #define that creates all of the Controller_##player##_ values and it still ended up having the same problem. My guess is that the linker isn't looking everywhere it should be, but I'm not sure why yet. If I haven't said it already though, great job so far re-organizing the code. It's much easier to find the source of problems than the last time I looked at Gens.
Success! Many thanks to Gerbil for some hints that helped me fix the rest of the problems. When he's got milestone 5 done, I plan to submit the changes necessary for an OS X build back to him. I may try to do a native OS X UI myself afterwards so X isn't required, not sure yet.
Excellent. The news of the successful building of Gens on OS X has come at a very good time. Last couple of updates to OS X seem to have broken my Darwine setup, and so I can't use Kega Fusion anymore until I fix a gdi32.dll initialization problem. Now Mac users will have something that's native and emulates MegaCD and 32X, which is indeed unheard of on the Mac platform at all until now. If a native UI could be implemented, then it would be what Mac Users have been wanting for some time. Excellent work, all. I hope this indeed becomes mainstream in the slowly growing emulation community of Mac Users.
Is this supposed to work with 64 bit linux, because it says x86_64-linux-gnu or something isn't a recognized architecture. If 64 bit isn't supported, will it be?
EDIT: What I wanted to say was said by Puto already. Very nice, anyway. If a proper OSX UI is made, people will be able to get rid of Bannister's "Emulator Enhancer" crap.
Eventually, 64-bit support will be added. Right now, there's a lot of 32-bit assumptions, e.g. storing pointers in 32-bit ints, so it won't work on 64-bit. If possible, try compiling it as a 32-bit binary. Also woo, Gens/GS runs on MacOS/x86! It looks like Apple's X11 implementation doesn't support the SDL window embedding hack, though.
I know I sound like a total turd for asking this, but how do I go about building it as 32 bit. Whenever I try to configure, it spits out: Code (Text): configure: error: Unsupported operating system: x86_64-unknown-linux-gnu If there is someway to bypass this check, please tell me.
Puto: Yes, I believe that many of us remember that you and Sazpiamon ported Gens to OS X x86. The problems I had with it were that 1) It had no 32X support, and 2) It broke in Leopard due to a new X11 implementation. This version will run MegaCD and 32X, and runs on Leopard (Look at the bar at the top of the screenshot window and it's noticeably a Leopard Menu Bar). This version will hopefully also have the implementation of a native UI so that it won't rely on X11, and thus circumvent the problem that MacGens has with Leopard. GerbilSoft: Annoying, isn't it? The X11 implementation is very poor, although I believe it's more at fault of X11's poor integration than Apple's system. X11 itself is very much a frustration as well as a feature. I understand why Apple wanted to implement X11, but X11 just does not have as much flexibility on OS X as it does on Linux. I do hope that you do find a way to implement a native UI. I would help, but I don't know C++ very well, although I'm working on educating myself in the language.
Puto said he was able to build it as 32-bit by specifying the compiler as "gcc -m32" and "g++ -m32". So, here's what you need to do: 1. Edit Gens/GS's configure.in, and replace *i686*linux* with *x86_64*linux* . 2. Type the following commands: ("$" is the prompt) Code (Text): $ autoconf $ CC="gcc -m32" CXX="gcc -m32" ./configure && make && make install Hopefully that should work. You'll need to install the 32-bit compatibility libraries if they're not already installed; I forget what they're called in Ubuntu. For Milestone 5, I'll include a workaround for 32-bit on x86_64 in the configure script, so this edit will be unnecessary.
Afaik you can only compile and/or run 32-bit programs if you're running a multilib 64-bit Linux distribution, I.e one which has both 32-bit and 64-bit libraries, and the corresponding development packages. Most are, but there are some which aren't, and so building Gens on those out of the box is not possible.
We did a quote-unquote native version too, but it got lost in time. It used an experimental implementation of GTK+ on Cocoa which made the UI kinda gay, but it still worked.
Now it is saying I don't have GTK+ 2.4.0 or higher when I ./configure with the gcc -m32 options, if I just run ./configure however, it runs fine. (I know I have the 32 bit compatibility stuff, it is needed to run wine and the official flash plugin, correct?)
It's probably using the 64-bit lib directory. Try running this: Code (Text): CC="gcc -m32" CXX="g++ -m32" LDFLAGS="-L /usr/lib32"
Code (Text): checking for GTK+ - version >= 2.4.0... no *** Could not run GTK+ test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GTK+ is incorrectly installed. configure: error: *** GTK+ version 2.4.0 not found! That is what I keep getting, I have used your info, I have used things I have seen elsewhere, and to no avail.
