GCC under macOS fails to build DOSBox

[kcgen]

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

[kcgen]

Will try gcc versions 8, 7, 6, and 5 per: https://formulae.brew.sh/formula/gcc

Update: they all fail the same. This feels like a header problem, such as missing a critical -I<path> to some other Mac-specific area (perhaps with headers that override existing ones).

DOSBox-X has experienced link problems with gcc on macOS here, which they solve by adding -framework CoreFoundation -framework Carbon to LDFLAGS, however our scenario is compile-time, not a link problem.

[kcgen]

Someone on Vogons hit this 8 years ago.

@Dominus mentioned setting environment variables but could not recall them - and searching and googling turns up nothing.

Will check with Dominus to see what he thinks:
https://www.vogons.org/viewtopic.php?f=32&t=29033&p=796740#p796740

[dreamer]

The code does not compile, because of this: MIDIServices.h:

303: typedef void
304: (^MIDINotifyBlock)(const MIDINotification *message);

I've never seen this syntax before… turns out it's Apple's extension to C language, which is not available in GCC: https://en.wikipedia.org/wiki/Blocks_(C_language_extension)

[edit]
My opinion here: I don't really care - macOS is a proprietary platform, and as long as we don't have a developer who cares enough to keep maintaining it, then it's ok to keep only a rudimentary Clang-based build.

[kcgen]

Fully agree.

The fact that DOSBox relies on headers that aren't part of the C or C++ language specifications (at any past or proposed future time) appears to conflict with the simultaneous desire to avoid actual and approved C and C++ specifications, such as those ratified > circa-2000.

Regardless of the above, surely anyone would agree these Apple headers are undesirable, and perhaps the cause is auto-tools or pkg-config trying to make the best of things. It seems worthwhile that DOSBox at a minimum should compile using a current GNU build stack (on the 2nd-most-popular desktop OS no less).

My solution would be to excise this rubbish via detection of OSX + gcc in the build system (./configure) or ideally with #ifdefs if AppleBlocks reveal itself with some preprocessor definitions: at least that would get DOSBox compiling and give us complete GNU build-chain coverage (goodbye CoreMIDI ✂️).

Given the CoreMIDI package probably boils down to C-callable symbols, a more elegant solution might be to add a C-compliant shim-header with extern prototypes for those (few?) midi calls DOSBox relies on. But that's something in which I have little person interest 🤷‍♂️

[kcgen]

Looks like we can detect and work-around it; something like:

#ifndef __has_feature
    #define __has_feature(x) 0
#endif
#ifndef __has_extension
    #define __has_extension __has_feature // Compatibility with pre-3.0 compilers.
#endif

#if __has_extension(blocks)
    ... include CoreMIDI rubbish
#else 
    ... C/C++-compliant code path  
#endif

https://clang.llvm.org/docs/LanguageExtensions.html#blocks
http://releases.llvm.org/3.7.0/tools/clang/docs/LanguageExtensions.html#has-feature-and-has-extension

[kcgen]

Fixed in e035f8b

Will see what up-stream thinks. Closing this for now given the CI chain is once again ticking along.

PS - wow.. gcc-6 detects 226 additional warnings when building under Mac: https://github.com/dreamer/dosbox-staging/runs/275764609

[dreamer]

Ouch, that's a lot… It seems like most of them are strict-aliasing warnings.