Enable osx-ppc compilation - Githubissues

libretro / picodrive

Fast MegaDrive/MegaCD/32X emulator

Other

40 stars 63 forks source link

Enable osx-ppc compilation #202

Closed phcoder closed 2 years ago

phcoder commented 2 years ago

This fixes few needless defines and enables osx-ppc compilation @irixxxx

inactive123 commented 2 years ago

@phcoder Has this been confirmed working on OSX PowerPC?

@irixxxx Up to you to review.

irixxxx commented 2 years ago

@phcoder just wondering, was this really needed for you? @gameblabla helped me debugging the ppc drc stuff some time ago using a G4 powerpc mac, and he hadn't reported this. Edit: He made standalone picodrive versions, though.

phcoder commented 2 years ago

@phcoder Has this been confirmed working on OSX PowerPC?

Yes, on iBook G4 with a pico game

phcoder commented 2 years ago

@phcoder just wondering, was this really needed for you? @gameblabla helped me debugging the ppc drc stuff some time ago using a G4 powerpc mac, and he hadn't reported this. Edit: He made standalone picodrive versions, though.

Part of it are cleanups and they are in separate commit and marked as such.
Part is fixing double typedef's that GCC 4.2.1 chokes on. You probably didn't encounter this because often one of typedef's comes from libretro headers
By far the biggest offender is -mmacosx-min-ver set to 10.6. Last MacOS X to run on PPC is 10.5. You can technically run ppc binaries on 10.6 but only through emulator on x86 hardware which is pointless even if technically allowed

inactive123 commented 2 years ago

@irixxxx These changes are necessary yeah on older GCC compilers for PowerPC Mac. I've had to do this myself too on other cores as well. So the changes here seem reasonable to me at least.

irixxxx commented 2 years ago

Just for me to understand commit 6e820e8:

defining those types prevents them from being typedef'd in pico/sound ym2612.h. They are still defined in pico/cd/libchdr/include/libchdr/coretypes.h, though.
AFAICT those headers are never included both, so they should never be redefined. where and why is this causing a problem? Are those type names used by the system includes? Can you tell me which file didn't compile properly, please?

For the 2nd part of that commit, I'd prefer something like this, please:

ifeq ($(platform), osx)
pico/cd/libchdr/src/libchdr_chd.o: CFLAGS += -D__MACTYPES__=1
endif

That would leave the rest of the compile rules intact.

phcoder commented 2 years ago

Just for me to understand commit 6e820e8:

defining those types prevents them from being typedef'd in pico/sound ym2612.h. They are still defined in pico/cd/libchdr/include/libchdr/coretypes.h, though.

The culprit is cpu/cz80/cz80.h It has:

#ifndef UINT8
#define UINT8   u8
#endif

This make coretypes.h attempt to redefine u8 instead of defining UINT8 which results in: pico/cd/libchdr/include/libchdr/coretypes.h:25: error: redefinition of typedef 'u8' pico/pico_types.h:8: error: previous declaration of 'u8' was here

Failed compile: https://git.libretro.com/phcoder/picodrive/-/jobs/1769363 Working one: https://git.libretro.com/phcoder/picodrive/-/pipelines/99445

For the 2nd part of that commit, I'd prefer something like this, please:
ifeq ($(platform), osx)
pico/cd/libchdr/src/libchdr_chd.o: CFLAGS += -D__MACTYPES__=1
endif
That would leave the rest of the compile rules intact.

Done

irixxxx commented 2 years ago

Thanks