FS-UAE for OS X PPC (Not officially supported)
Finally I found a SDL2.Framework working on PowerMacs, the universal binary is bundled with the very nice and fast game BitFighter so I tried again to build latest FS-UAE dev on my G4 MDD extracting it and putting that Framework in the usual places but the configure script fails to found it: I tried to play a bit with the command line options but without success: what is the correct syntax to force Configure (FS-UAE) to target to a specific SDL2.Framework location?
|
Hi, this is a bit outside what I can reasonably provide support for, so you need to be able to do it mostly by yourself :)
Linking against frameworks on OS X can be done like this: Code:
-F/path/to/dir/containing/framework -framework SDL2 |
The method above did not work for me, I have a G4 MDD with OSX 10.5.8 installed with all the goodies needed for compiling and here is what is happening:
- Unpacked BitFighter version Universal 32bit - Extracted from the app bundle the SDL2.framework and putting it in Library/Frameworks/ - Deleted the SDL2.framework from BitFighter bundle - Running BitFighter in this way is OK so the app is founding its way to the SDL2 framework in the new location. - Now I unpacked the FS-UAE source - From Terminal I run ./configure obtaining the following result: Code:
power-mac-g4-di-snakecoils:fs-uae-2.5.8dev snakecoils$ ./configure I also have tried to strip the universal binary to its PPC part only (and BitFighter still run) just in case FS-UAE config dislikes the universal version of that framework. As far as I know the SDL 2.0.1 version is the latest with OSX PPC support, it has been dropped since 2.0.2 but at present I have not yet found an old 2.0.1 source repository so I am stuck with the SDL2.framework found in BitFighter. Is there a way to force FS-UAE build process to use this library? |
The configure script does not look for SDL2 framework, it uses pkg-config to find the includes and library flags.
You may be able to get to work by setting the following environment variables before running configure: Code:
export SDL2_CFLAGS="-I/path/to/dir/containgin/SDL/header/files" |
Following your instructions I have declared these lines (including brackets):
export SDL2_CFLAGS="-I/Library/Frameworks/SDL2.framework/Versions/A/Headers" export SDL2_LIBS="-F/Library/Frameworks -framework SDL2" Then I ran ./configure and this time the script reaches the end. After that I have changed the dir to "macosx" and I have launched the make command but it has stopped almost immediately with this error: Code:
power-mac-g4-di-snakecoils:macosx snakecoils$ make Following the example above for SDL2 I have declared the OpenAL path directly in the MacPorts directories: export OPENAL_CFLAGS="-I/opt/local/Library/Frameworks/OpenAL.framework/Versions/A/Headers" export OPENAL_LIBS="-F/opt/local/Library/Frameworks -framework OpenAL" At present the build fails with the same error above. In the meantime I have downloaded the source of SDL 2.0.1 and recompiled as ppc binary (not universal) under Xcode 3.2.5 in a OSX 10.6.8 environment, but unfortunately this does not helped in FS-UAE compile. |
Quote:
Quote:
|
Well, after a bit of struggling FS-UAE for OSX PPC is almost here :-)
At present I used the 2.5.8dev version because the presence of PPC engine from 2.5.9 on is causing further troubles so in the meantime I have experimented on a safer release. There are some additional steps I performed to reach the end, they are: - In the SDL2.framework I modified a string in the SDL_platform.h header to allow FS-UAE to use it on 10.5 too, otherwise an error occour telling that SDL2 can't be build on an environment lower than 10.6 - The zip command from Xcode did not recognize che -Z option so using MacPorts I have upgraded to the last version and I have replaced the group of binaries in /usr/bin with the soft links from the MacPorts bunch. With the above modification the build process goes straight to the end but fails in the Python script when all resources are put together to make the bundle with this error: Code:
@rpath/SDL2.framework/Versions/A/SDL2 |
standalone.py is a small program I write to copy library dependencies to the .app bundle (and correct the library rpaths). It simply does not understand the rpath for the SDL2 framework (because no libraries I link to uses @rpath/...).
This can be fixed, of course, but you only need to run standalone.py if you plan to distribute the resulting .app bundle. For your own use only, it is not needed. |
I am already happy to can build FS-UAE again for the my beloved G4 MDD so many many thanks for the support provided :-)
Checking the bundle from the intel version seems that only the SDL2 library is missing so I added it manually, I have already uploaded the result in The Zone so everyone can already play with it. A last thing seems missed: some resources (PNG files mainly) while they are in the bundle can't be found from the FS-UAE executable, and when launched the black screen is filled with "not found PNG" messages. Here is the log for what is happening: Code:
|
The loader (for fs-uae.dat) is not big-endian-friendly. Actually, there was an #error to catch that case (so the code shouldn't even have compiled), but config.h was not included, and so the check didn't trigger.
Anyway, I'll make the code work for both little-endian and big-endian CPU :) |
This is a really great news! :-) Thank you very VERY much Frode, I and the PPC Mac user community still alive we appriciate every effort in not leaving our machines in the dust.
Great Nice Work! |
Please test the newly released 2.5.11dev version :)
I've also made some other changes for you/ppc in addition to big-endian support for loading of fs-uae.dat, so you can (hopefully) compile the latest version: * Can configure with --disable-cpuboard --disable-ppc. * Configure script checks if -fno-strict-overflow is recognized. |
Just finished my summer holidays and back to the FS-UAE OSX PPC thing :-)
After downloaded the 2.5.11dev source I compiled it following your instructions but the "Not found PNG" errors at startup are still here. The log for this issue is the following: Code:
FS-UAE VERSION 2.5.11dev Code:
(...) Anyway, many thanks again for the active support! :-) Edit: I have just uploaded the freshly build 2.5.11dev version for OSX PPC in the Zone |
What about jit?
Are there any chances of adding jit to ppc emulation? |
Quote:
Code:
--- a/fs-uae/libfsemu/src/data.c Quote:
Quote:
|
Excellent work, the patched source worked as expected, no more missing PNG error messages at startup so it can be happily included in the next dev release ;-)
The only remaining issue is the @rpath error in the python script that makes the bundle (see post #7) but I am (again) really happy with the actual binary. I am going to re-upload the fixed binary in The Zone. |
The recent 2.5.12dev does not build, i have made the usual steps that are:
export SDL2_CFLAGS="-I/Library/Frameworks/SDL2.framework/Versions/A/Headers" export SDL2_LIBS="-F/Library/Frameworks -framework SDL2" export OPENAL_CFLAGS="-I/opt/local/Library/Frameworks/OpenAL.framework/Versions/A/Headers" export OPENAL_LIBS="-F/opt/local/Library/Frameworks -framework OpenAL" ./configure --disable-cpuboard --disable-ppc cd macosx make and the build process hangs here: Code:
(...) |
The "problem" is just that --disable-cpuboard --disable-ppc isn't really used anywhere else, so when changes to the source code are made, they may not work with this combination.
In this case, it was changes from a newer WinUAE beta (which does not even have the WITH_CPUBOARD define...), and a change there must be protected by #ifdef WITH_CPUBOARD... Or, just get pearpc to compile instead (probably better long-term anyway, whether pearpc works on PPC or not). |
Maybe your suggested second solution could be the right way, It would also be interesting to see how well perform a PPC-on-PPC emulator :-)
|
If you download the latest source from git: https://github.com/FrodeSolheim/fs-uae - then you should be able to compile with --disable-cpuboard --disable-ppc again.
Note, I'm not going to do anything about the PPC/PearPC code. I cannot even test the changes. But making that bit compile would as I said make it more likely that the next development versions work out of the box as I don't really use --disable-cpuboard --disable-ppc myself. |
All times are GMT +2. The time now is 16:28. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.