Hmm, thats strange. Let me try that tomorrow myself. Do you set any special environment stuff for compiling on your own?

No. Just ./configure
Followed by make
I have even deleted the folder and untared it again and ran ./autogen before ./configure with the exact same result.

You need to pass on some environment settings, please search the forum I wrote this somewhere and don't have the resources to look it up myself.
ESPECIALLY you need to build Dosbox 0.74 in 32bit or it will crash when it switches to dynamic core. The OS X 64bit dynamic core has been fixed in SVN but is still much much slower than the 32bit dynamic core.

Dominus,

I've been chipping away at various builds, and am hitting a similar core MIDI problem using GCC under macOS. Specifically:

1In file included from midi_coremidi.h:17,
2                 from midi.cpp:75:
3/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreMIDI.framework/Headers/MIDIServices.h:304:2: error: expected unqualified-id before '^' token
4  304 | (^MIDINotifyBlock)(const MIDINotification *message);

I've tested the following (click the 'build' link to see the output):
- gcc 9.2: https://github.com/dreamer/dosbox-staging/runs/275613233
- gcc 8.3: https://github.com/dreamer/dosbox-staging/runs/275613242
- gcc 7.4: https://github.com/dreamer/dosbox-staging/runs/275613217
- gcc 6.5: https://github.com/dreamer/dosbox-staging/runs/275613297
- gcc 5.5: https://github.com/dreamer/dosbox-staging/runs/275613327

Each test involves standing up a separate clean Mac OSX VM:
- uname -a: Darwin Mac-247.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
- uname -s: Darwin
- uname -m: x86_64

Followed by using brew to install the GNU stack:
- compiler (gcc@9, or gcc@8, ... )
- coreutils
- autogen
- autoconf
- automake
- pkg-config
- libpng
- sdl
- sdl_net

PATH is then prefixed with: /usr/local/bin to ensure GCC is actually used (and not the gcc->clang symlinks).

The compiler variables are set per their version, such as:

1    CC       = gcc-5
2    CXX      = g++-5
3    LD       = gcc-5
4    AR       = ar
5    RANLIB   = ranlib
6    CFLAGS   = -Wall -pipe -fstack-protector -fdiagnostics-color=always -O2
7    CXXFLAGS = -Wall -pipe -fstack-protector -fdiagnostics-color=always -O2
8    LIBS     =  (unset)
9    LDFLAGS  = (unset)

This is then followed by the usual:
- ./autogen.sh
- ./configure
- make

This above works fine for Clang and generates many different build types without issues.

Cross linked to this GitHub bug: https://github.com/dreamer/dosbox-staging/issues/19

Interim solution proposed here:
- https://sourceforge.net/p/dosbox/bugs/517/#4e3e

You might want to check why configure is not enabling the dynamic_x86 core for all those builds.

Thank you for the report and investigation.

I a reading it right ? Are the midi headers of apple themselves broken ?
Maybe it would be better to detect clang (with apple extensions) vs gcc instead. ? Although I am not sure what to do and if it is really something that we should fix it at all.. (maybe through configure, as that ifdef stuff really looks like something for the configure to set) ?)
Where is Apples quality control ? or should we not be using that header ? (as you seem to hint at in staging bug report)

I believe Apple's version of gcc (back when they used to use it instead of clang) handles these files fine, the problem is an external build of gcc is being used instead. It's the classic problem of having to use apple's stuff to build for their platform.

jmarsh wrote:

You might want to check why configure is not enabling the dynamic_x86 core for all those builds.

Jmarsh, thanks for flagging this - it's a bug on my part (no involvement with current gcc build error).

Qbix, I'm glad to help.

Yes, the header is non-standard, and deliberately so.

dreamer_ augmented the macOS build to cat the entire header:
https://github.com/dreamer/dosbox-staging/runs/275683941

That's a pretty nasty smoking gun.. exactly as jmarsh describes. It's the Apple way or the highway.

Good point regarding moving the detection into autotools. Apple's headers require any compiler that handles their Blocks extension, so we could have configure add a HAVE_APPLE_BLOCKS (or something like that) in config.h, and in turn look for that plus the MACOS define before including the coremidi headers.

Regarding detecting clang.. that's an option too. I went with the approach Apple's docs recommended regarding detecting 'blocks' as a language addon; in a non-clang centeric way. The reality is that clang will probably always be the only compiler to support this syntax though, so perhaps no different.

This is the only header DOSBox uses that's affected with this. It would be nice to not use the header at all to avoid needing a non-standard-compliant compiler to compile midi.cpp, and instead figure out how to link to core audio with needing that header (perhaps have DOSBox's coremidi.h explicitly define C-compliant extern prototypes for the core midi functions that we call, instead of including the apple header.)

Perhaps it's always been this way, and people have been fooled when testing builds of DOSBox on mac with the gnu stack (just like I was.. Apple links all of the gnu dev binary names to clang or their own binaries, unless you explicitly use the brew-provided binaries in /usr/local/bin, like I eventually did).

If you leave these blocks out, does CoreMidi work on OS X? Or is it just to satisfy the buildtest?
CoreMidi is the way DOSBox can use real Midi devices like a Roland MT-32 but also virtual Midi devices like Munt (when it is not built in).

jmarsh wrote:

I believe Apple's version of gcc (back when they used to use it instead of clang) handles these files fine, the problem is an external build of gcc is being used instead. It's the classic problem of having to use apple's stuff to build for their platform.

Absolutely. It's arrogant of Apple to not even attempt to make their headers comply with the C specification (with some ifdefs in their own headers that swap-in C-compliant prototypes in place of their stuff when built with non-Apple compilers).

Certainly it would be easy for them to write a tool that autogenerates C-compatible equivalents so their own developers aren't burdened with this (and can keep their clang-goggles on), so the choice seems deliberate by Apple.

Dominus wrote:

If you leave these blocks out, does CoreMidi work on OS X? Or is it just to satisfy the buildtest?
CoreMidi is the way DOSBox can use real Midi devices like a Roland MT-32 but also virtual Midi devices like Munt (when it is not built in).

Good question.. I don't have an OS X machine (or VM) to test this GCC-built DOSBox, but its midi interface uses the OSS sequencer API, which it seems Apple still provides functional hooks into (given linking works with all symbols found) .

I'm not sure how munt and other midi interpreters tie into the OSS bus in general (like when running on a pre-ALSA Linux or BSD), but my guess is this would be the same here.

Dominus wrote:

If you leave these blocks out, does CoreMidi work on OS X? Or is it just to satisfy the buildtest?
CoreMidi is the way DOSBox can use real Midi devices like a Roland MT-32 but also virtual Midi devices like Munt (when it is not built in).

Dominus, you mentioned cross-compiling for OS X, https://sourceforge.net/p/dosbox/patches/283/#0bd1 needing gcc 4.0/4.2. Maybe at some point in the past, CoreMIDI/MIDIServices.h was actually C-compliant. Can you inspect your cross-compiling machine's `CoreMIDI/MIDIServices.h` header and see if it's using Apple's Blocks extension?

Here's a snip from their current header that's using Apple Blocks syntax:

1typedef void
2(^MIDINotifyBlock)(const MIDINotification *message);

Curious what yours contains.

Regarding needing gcc 4.x; fortunately something that old is not needed (and infact doesn't even work) on a real OSX host. Even the latest version 5 (gcc-5.5.0_3) installed by brew is incapable of building DOSBox due to fundamental header issues:

1/usr/local/Cellar/gcc@5/5.5.0_3/lib/gcc/5/gcc/x86_64-apple-darwin17.7.0/5.5.0/include-fixed/stdio.h:78:20: fatal error: _stdio.h: No such file or directory

So at least on an actual OS X host, the set of working GNU compilers include the latest versions of GCC 6, 7, 8, and 9.

Only for compiling the PPC version did I need to cross compile using old gcc 4.0/4.2, but that is also the one apple supplied

Dominus wrote:

Only for compiling the PPC version did I need to cross compile using old gcc 4.0/4.2, but that is also the one apple supplied

Oh.. interesting. They might have mangled it with their non-standard language extensions prior to getting clang underway.

In any case, do you know if it's pulling in the core midi header, and if that header is using Apple's Blocks syntax? If it is, then this new change to deal with this non-standard syntax might let you use a modern gcc version to cross-compile for PPC.

Qbix, here's how it looks moved into the configure step, which simplifies what we look for in midi.cpp:

https://github.com/dreamer/dosbox-staging/com … 32b00eab7876e28

(mind the spelling typo of 'support')

krcroft wrote:

Oh.. interesting. They might have mangled it with their non-standard language extensions prior to getting clang underway.

As I mentioned earlier that's exactly what happened. Their headers have always been designed to only work with their compiler, not sure why you're going to the effort of setting up a buildchain with a third-party supplied compiler when that's never been a supported configuration.

jmarsh wrote:

not sure why you're going to the effort of setting up a buildchain with a third-party supplied compiler when that's never been a supported configuration.

I wasn't aware DOSBox's core developers exclusively support Clang-based builds on OS X (happy if you can point me to that).

Similarly, I wasn't aware the core developers have declared gcc as /not supported/ on OS X. I would also appreciate pointing me to that public statement. (Perhaps I'm like Leisure Suit Larry.. lookin' for the DOSBox developers club in all the wrong places?)

More earnestly though.. it's obvious the DOSBox team has gone to great effort over many years to ensure their code is maximally portable and standards-compliant, so declaring a bonafide GNU stack as explicily not supported would conflict with their own actions. Likewise, Qbix's response here shows concern about addressing this issue. This is backed by reality as well: a simple preprocessor check is all that's needed to get things back on track.

Regarding this 'third-party supplied compiler', if the brew team is shipping a defective GNU dev stack, feel free to open an issue with them: https://formulae.brew.sh/formula/gcc
(On the contrary, I've personally found their stuff more up-to-date than most out-of-the-box Linux package managers, and DOSBox now builds and links with gcc 9.2, 8.3, 7.4, and 6.5 on OS X: including with feedback-directed optimizations and whole-program-optimizations.. so I have been pleasantly surprised with how complete and issue-free the experience has been on OS X, despite working at arms length on a remote VM).

Why do I invest the effort? Because I want to; I didn't realize we were questioning people's efforts.

PS.. We've got a 23-19 situation forming: somebody mentioned wanting to build DOSBox with Open Watcom V2. Seargent, you might want to pay that thread a visit, investigate their motives, and notify them of DOSBox's support terms.