Closed kwyxz closed 6 years ago
Is the core properly emulating sms with your hack ? STREAM_MAX does seem necessary to me.
I've only tested with sms_alexkidd1 (crc 17a40e29) but sound seems fine as far as I can tell. I'm still not sure why gcc throws that error while it does not seem STREAM_MAX is defined anywhere else in the code. This header file actually contains the only two occurences of STREAM_MAX in the entire fbalpha repo. Could it be legacy code remnants that are now unused? Still, this #undef feels like a real dirty hack and I'd love to find a cleaner way to allow this core to build :(
From what i understand, STREAM_MAX is a system macro, perhaps haiku is not properly implementing it ?
It seems haiku do this :
#define STREAM_MAX FOPEN_MAX
(see https://github.com/haiku/haiku/blob/master/headers/posix/stdio.h)
Which seems fine to me. Could you try adding this system macro again after your #undef STREAM_MAX
and tell me if it builds ?
If it doesn't, it probably means FOPEN_MAX is not working properly in haiku ?
Thanks for looking into this @barbudreadmon
Redefining STREAM_MAX as FOPEN_MAX after the #undef does not seem to help. Here's the result:
g++ -c -osrc/burn/drv/sms/smspio.o src/burn/drv/sms/smspio.cpp -std=gnu++98 -DGIT_VERSION=\"" caebb35"\" -O3 -DNDEBUG -fPIC -DPTR64 -DINCLUDE_7Z_SUPPORT -D__LIBRETRO__ -DLSB_FIRST -D__LIBRETRO_OPTIMIZATIONS__ -DUSE_SPEEDHACKS -DTOAPLAN_SOUND_SAMPLES_HACK -fforce-addr -finline-limit=1200 -fcheck-new -Wall -W -Wshadow -Wno-long-long -Wno-write-strings -Wunknown-pragmas -Wundef -Wno-conversion -Wno-missing-braces -Wno-multichar -Wuninitialized -Wpointer-arith -Wno-inline -Wno-unused-value -Wno-sequence-point -Wno-extra -Wno-strict-aliasing -Wno-write-strings -pedantic -Wno-address -Wno-unused-but-set-variable -Wno-narrowing -Wno-pedantic -DFRONTEND_SUPPORTS_RGB565 -Isrc/burner/win32 -Isrc/burner/libretro/libretro-common/include -Isrc/burner/libretro -Isrc/burn -Isrc/cpu -Isrc/burn/snd -Isrc/burn/devices -Isrc/intf -Isrc/intf/input -Isrc/intf/cd -Isrc/intf/audio -Isrc/burner -Isrc/cpu -Isrc/cpu/i8039 -Isrc/cpu/i8051 -Isrc/cpu/tms32010 -Isrc/cpu/upd7725 -Isrc/cpu/upd7810 -Isrc/cpu/v60 -Isrc/dep/libs/zlib -Isrc/dep/libs/lib7z -Isrc/burn/drv/capcom -Isrc/burn/drv/konami -Isrc/burn/drv/dataeast -Isrc/burn/drv/cave -Isrc/burn/drv/neogeo -Isrc/burn/drv/psikyo -Isrc/burn/drv/sega -Isrc/burn/drv/toaplan -Isrc/burn/drv/taito -Isrc/dep/generated -Isrc/dep/libs
In file included from /boot/system/develop/headers/bsd/stdio.h:9:0,
from src/burn/burnint.h:8,
from src/burn/tiles_generic.h:1,
from src/burn/drv/sms/smsshared.h:4,
from src/burn/drv/sms/smspio.cpp:5:
src/burn/drv/sms/smssound.h:7:20: error: expected identifier before numeric constant
#define STREAM_MAX FOPEN_MAX
^
src/burn/drv/sms/smssound.h:15:5: note: in expansion of macro 'STREAM_MAX'
STREAM_MAX /* Total # of sound streams */
^
src/burn/drv/sms/smssound.h:7:20: error: expected '}' before numeric constant
#define STREAM_MAX FOPEN_MAX
^
src/burn/drv/sms/smssound.h:15:5: note: in expansion of macro 'STREAM_MAX'
STREAM_MAX /* Total # of sound streams */
^
src/burn/drv/sms/smssound.h:7:20: error: expected unqualified-id before numeric constant
#define STREAM_MAX FOPEN_MAX
^
src/burn/drv/sms/smssound.h:15:5: note: in expansion of macro 'STREAM_MAX'
STREAM_MAX /* Total # of sound streams */
^
In file included from src/burn/drv/sms/smsshared.h:13:0,
from src/burn/drv/sms/smspio.cpp:5:
src/burn/drv/sms/smssound.h:16:1: error: expected declaration before '}' token
};
^
makefile.libretro:536: recipe for target 'src/burn/drv/sms/smspio.o' failed
make: *** [src/burn/drv/sms/smspio.o] Error 1
Now I've taken a good hard look at my Linux header files (both Debian and RHEL) and can't seem to find STREAM_MAX defined anywhere (nothing in limits.h, nothing in stdio.h, nothing in /usr/include at all) - and sure enough, FBAlpha builds fine there. Googling about this macro definition, I sure find references to it but all of them look rather old.
Is it possible that this macro was phased out of the Linux glibc some time ago? If so, could its actual presence in the Haiku header files be the issue? Judging from the error message I am getting it looks like the preprocessor is not expecting to see a predefined macro there. Sorry, my C++ is way too outdated to be able to interpret it any better :(
Should we involve upstream? I'm not even sure of what this enum is doing there. I tried this:
diff --git a/src/burn/drv/sms/smssound.h b/src/burn/drv/sms/smssound.h
index cbe94d4..dad87cd 100644
--- a/src/burn/drv/sms/smssound.h
+++ b/src/burn/drv/sms/smssound.h
@@ -2,20 +2,20 @@
#ifndef _SMSSOUND_H_
#define _SMSSOUND_H_
-enum {
- STREAM_PSG_L, /* PSG left channel */
- STREAM_PSG_R, /* PSG right channel */
- STREAM_FM_MO, /* YM2413 melody channel */
- STREAM_FM_RO, /* YM2413 rhythm channel */
- STREAM_MAX /* Total # of sound streams */
-};
+// enum {
+// STREAM_PSG_L, /* PSG left channel */
+// STREAM_PSG_R, /* PSG right channel */
+// STREAM_FM_MO, /* YM2413 melody channel */
+// STREAM_FM_RO, /* YM2413 rhythm channel */
+// STREAM_MAX /* Total # of sound streams */
+// };
/* Sound emulation structure */
typedef struct
{
- void (*mixer_callback)(INT16 **stream, INT16 **output, INT32 length);
+// void (*mixer_callback)(INT16 **stream, INT16 **output, INT32 length);
INT16 *output[2];
- INT16 *stream[STREAM_MAX];
+// INT16 *stream[STREAM_MAX];
INT32 fm_which;
INT32 enabled;
INT32 fps;
It builds fine and... SMS sound still works. I am puzzled.
Perhaps @dinkc64 would be able to help, i kinda remember sms was the first driver he wrote in fbalpha.
I left a new smssound.h on neosource for you, that will fix the issues :)
Amazing! I was not sure I was not breaking anything by commenting out a good bunch of the code you removed, thank you for confirming it's fine. FB Alpha now builds like a charm on Haiku! Thanks @barbudreadmon and @dinkc64
Hi folks, Been having a weird build error on Haiku:
I've been Googling a lot but sadly I'm still a bit lost as to what the issue could be. The same code builds perfectly fine in Linux. Best workaround I've found:
This allows the core to build fine. However it feels : 1- like a dirty hack 2- weird that Haiku would be the only system coughing up an error
I'm assuming there's a better way to fix that, maybe directly in the Makefile. I'm open to any suggestion!
Thanks.