Your notes were perfect; thanks Dominus.

DOSBox is now building clean using a pure-MacPorts suite with gcc-9. Here's a link to the full run:
https://github.com/dreamer/dosbox-staging/runs/277061295

MacPorts is installed from source, PATH prefixed with /opt/local/bin, and the following "*-mp-9" binaries used:

1    CC       = gcc-mp-9
2    CXX      = g++-mp-9
3    LD       = gcc-mp-9
4    AR       = ar
5    RANLIB   = ranlib
6    CFLAGS   = -Wall -pipe -fstack-protector -fdiagnostics-color=always -Ofast 
7    CXXFLAGS = -Wall -pipe -fstack-protector -fdiagnostics-color=always -Ofast 

$ gcc --version

1gcc-mp-9 (MacPorts gcc9 9.2.0_1) 9.2.0
2Copyright (C) 2019 Free Software Foundation, Inc.
3This is free software; see the source for copying conditions.  There is NO
4warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Snippet from configure:

1checking if compiler supports -mno-ms-bitfields... yes
2checking if compiler supports CoreMIDI headers... no
3checking for ALSA CFLAGS... 
4checking for ALSA LDFLAGS...  -lasound -lm -ldl -lpthread

After building we have a 3.7MB DOSBox binary that links to the following MacPorts libs (in addition to the usual Apple Framework libraries):

1	/opt/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.4.0)
2	/opt/local/lib/libSDL_net-1.2.0.dylib (compatibility version 9.0.0, current version 9.0.0)
3	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
4	/opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.27.0)
5	/opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

I tried to give apple-gcc40 and 42 a try, but they're no longer available on newer OS X releases:

1"Error: apple-gcc42 is not supported on OS X versions newer than El Capitan."

As for the SDK - that's great you've got an older set of C-compliant headers that are still useable by your MacPorts gcc-4.2 version. (Hold onto that configuration.. too bad things degrade if you upgrade! 😒 )

Now confirming that this change allows DOSBox to build with MacPorts gcc versions from 5 through 10 (https://github.com/dreamer/dosbox-staging/com … te_id=283858513).

Clang builds of DOSBox are unaffected and continue to include CoreMIDI headers.

That's as far as I can take my compatibility coverage; MacPorts doesn't support gcc less than or equal to 4.2 on the up-to-date OS X version running on GitHub's VMs.

Dominus, jmarsh - if you have working build environments, would you be able to confirm that your existing builds behave as expected with this change? (and kick the tires with gcc if you're curious 😀)

Patch attached; apply with: zcat /path/to/dosbox-compiler_supports_coremidi_check.patch.gz | patch -p1

Probably best to run the check only for darwin targets, like the "whether Apple user wants to override the build process to produce a 32 bit binary" test for example. Not a showstopper but will speed up configure a little bit.

That's even tidier; thanks jmarsh.
Updated patch attached.

Here's what happens on non-darwin hosts:

1checking if compiler supports -mno-ms-bitfields... yes
2checking if compiler supports CoreMIDI headers... no, not on Apple

And on OS X, here's how all three compilers behave:

Tangentially related, I didn't realize what a broken down, gutted state Apple's developer API documentation is in.

Here's a list of Core MIDI API calls: https://nooverviewavailable.com/core-midi/

Clicking them takes you to Apple's developer documentation. For example:
- MIDIDeviceCreate(_:_:_:_:_:), https://developer.apple.com/documentation/cor … ididevicecreate
- MIDIDriverInterface(), https://developer.apple.com/documentation/cor … driverinterface

These don't even have descriptions, and the second doesn't even define the struct content (and that's as far as you get.. there are no links into the actual headers or code, so you're left grepping in their SDK source).

Quick question,
This check currently disables both midi interfaces on the mac.
However, all discussion so far has been focused on CoreMidi, which is one of the 2.
The compilation logs seem to indicate problems with both. So maybe this is intentional ?

@dominus. Which of the frameworks can be excluded if Midi is not compiled in. I take that -framework CoreMIDI should be part of this test. But I don't know if the other 2 audio frameworks are for the other midi or not ? (as both are currently excluded)

Something like this ? (krofts patch with the framework moved to the positive result)

Thanka for the check Qbix.

Intent is to bypass Apple's non-C-compliant headers to allow compilation with a standard GCC dev-stack provided by either MacPorts or Homebrew.

What was the second midi interface being knocked out? - maybe we can include it? (ThIs change should retain the maximum possible compileable functionality).

I like your addition to remove corresponding uneeded Apple framework libraries as well.

midi_coreaudio.h (part of the ifdef in midi.cpp)

Qbix wrote:

midi_coreaudio.h (part of the ifdef in midi.cpp)

Interesting; I didn't realize it was independent from midi_coremidi.h.

Will see what happens when trying to include its Apple headers (#include <AudioToolbox/AUGraph.h> and
#include <CoreServices/CoreServices.h>); fingers crossed they are still C-standard compliant.

each midi device is a header included in there. The comment that you removed didn't really specify it that clearly, but maybe it should be improved instead of removed.

Qbix wrote:

each midi device is a header included in there. The comment that you removed didn't really specify it that clearly, but maybe it should be improved instead of removed.

Thanks; and oops: that line cut was an unintentional hasty edit that I didn't catch! Will re-add and clarify 😀

I'll see what frameworks are not needed. will take a bit, though. No time today...

Attached patch separates the handling of Core MIDI and Core Audio for headers and libraries. Thanks jmarsh and Qbix for the reviews!

darwin host using default Clang compiler (configure output and shared libraries used by the binaries)
https://github.com/dreamer/dosbox-staging/run … 885793#step:5:0
checking if compiler supports Apple's Core MIDI headers... yes
checking if compiler supports Apple's Core Audio headers... yes
/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 69.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
<binary linked to both Core MIDI and Core Audio libs>

darwin host using default Clang compiler (artificial failure in support for Core Audio)
https://github.com/dreamer/dosbox-staging/run … 825102#step:5:0
checking if compiler supports Apple's Core MIDI headers... yes
checking if compiler supports Apple's Core Audio headers... no
/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 69.0.0)
<binary does not link to Core Audio libs>

darwin host using default Clang compiler (artificial failure in support for Core MIDI)
https://github.com/dreamer/dosbox-staging/run … 823699#step:5:0
checking if compiler supports Apple's Core MIDI headers... no
checking if compiler supports Apple's Core Audio headers... yes
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
<binary does not link to core MIDI lib>

darwin host using default Clang compiler (artificial failure supporting both Core MIDI and Core Audio)
https://github.com/dreamer/dosbox-staging/run … 929350#step:5:0
checking if compiler supports Apple's Core MIDI headers... no
checking if compiler supports Apple's Core Audio headers... no
<binary links to neither Core MIDI or Core Audio libs>

darwin host using MacPorts and Homebrew GNU build stack (fails both Core MIDI and Core Audio)
https://github.com/dreamer/dosbox-staging/run … 885852#step:5:0
https://github.com/dreamer/dosbox-staging/run … 885816#step:5:0
checking if compiler supports Apple's Core MIDI headers... no
checking if compiler supports Apple's Core Audio headers... no
<binary links to neither Core MIDI or Core Audio libs>

Non-darwin-based host:
checking if compiler supports Apple's MIDI headers... no, not on Apple
(builds and links as usual)

Thanks!

You're welcome; thank you & team for DOSBox 😀

For those with a Mac (or VM) and curious to try a build, here's a quick step-by-step.
Estimated time if copy-and-pasted back to back is roughly 10 minutes.

Install Xcode

1xcode-select --install
2sudo xcodebuild -license

Install MacPorts

1git clone --quiet --depth=1 https://github.com/macports/macports-base.git
2cd macports-base
3./configure
4make -j"$(sysctl -n hw.physicalcpu || echo 4)"
5sudo make install
6cd ..
7rm -rf macports-base

Note that by default, ./configure and make will install MacPorts to /opt/local.
If you change this path (using ./configure --prefix=/my/new/path), then macports will switch to using source-based packages and this install will take half a day or more. So I highly recommend leaving the above commands as-is to ensure you get the binary fast-install packages).

Install dev and DOSBox dependencies

1PATH="/opt/local/sbin:/opt/local/bin:${PATH}"
2sudo port -q selfupdate
3sudo port -q install  gcc9 coreutils autogen autoconf autoconf-archive automake pkgconfig libpng libsdl libsdl_net opusfile speexDSP

Build DOSBox (using same PATH as above)

1cd /my/src/dosbox
2export CC=gcc-mp-9
3export CXX=g++-mp-9
4export LD=gcc-mp-9
5export AR=ar
6export RANLIB=ranlib
7export CFLAGS="-Wall -pipe -fstack-protector -fdiagnostics-color=always -Ofast"
8export CXXFLAGS="${CFLAGS}"
9unset LIBS
10unset LDFLAGS
11./autogen.sh
12./configure
13make -j"$(sysctl -n hw.physicalcpu || echo 4)"

If you copy and paste that in one script, it will take about 10 minutes (at least it does on my VM). Hopefully you've got enough space! After that, you can blow away /opt/local 😀

against which Dosbox? SVN or a one of the staging bits?

Dominus wrote:

against which Dosbox? SVN or a one of the staging bits?

SVN should ./configure OK and fail during make
SVN + patch should ./configure and make OK; (I don't have an OS X box to test the binary with though 😒 )

Thanks, that's giving me enough to test with.

ok, tested with normal Apple clang and the macports gcc9.
Looks halfway good. When done with clang (+patch) CoreMidi/CoreAudio are still working (at least it is initialized). With gcc9 (+patch)these are not working ("MIDI: Can't find device:coremidi, finding default handler.") as expected but Dosbox works and audio is also working (as long as it is SB emulation).
But that there is no Midi device anymore is not ideal 🙁
IMO there should be a configure message at the end of configure that with this compiler there is no coremidi and/or coreaudio (depending on the test result) and that using Apple's clang will make those work.

As for the instructions, if you have MacPorts already installed (and thus skipping the macports install steps) you need "export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"" to make everything work (there is a bug with current Xcode on macOS 10.14 and macports in that it tries to use the 10.14 SDK but Xcode now only provides SDK 10.15 - that is likely already fixed in the macports git)