SendMIDI, ReceiveMIDI: The 10.14 SDK (Xcode 10.1+) is required to build JUCE apps

[ryandesign (Ryan Carsten Schmidt)]

SendMIDI and ReceiveMIDI fail to build with Xcode versions earlier than 10 (i.e. High Sierra and earlier):

In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Source/ScriptMidiMessageClass.cpp:19:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Source/ScriptMidiMessageClass.h:21:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/JuceHeader.h:17:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_audio_basics/juce_audio_basics.h:54:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_core/juce_core.h:66:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_core/system/juce_TargetPlatform.h:152:8: error: "The 10.14 SDK (Xcode 10.1+) is required to build JUCE apps. You can create apps that run on macOS 10.9+ by changing the deployment target."
      #error "The 10.14 SDK (Xcode 10.1+) is required to build JUCE apps. You can create apps that run on macOS 10.9+ by changing the deployment target."
       ^
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Source/ScriptMidiMessageClass.cpp:19:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Source/ScriptMidiMessageClass.h:21:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/JuceHeader.h:17:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_audio_basics/juce_audio_basics.h:54:
In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_core/juce_core.h:204:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_core/system/juce_StandardHeader.h:66:10: fatal error: 'optional' file not found
#include <optional>
         ^~~~~~~~~~
2 errors generated.

The first issue should be easy to solve by using the MacOSX10.14.sdk port:

if {${os.platform} eq "darwin" && [vercmp ${configure.sdk_version} < 10.14]} {
    configure.sdk_version   10.14
    configure.sdkroot       ${prefix}/Developer/SDKs/MacOSX${configure.sdk_version}.sdk
    depends_build-append    port:MacOSX${configure.sdk_version}.sdk
}

The second issue should be fixable by using the newer MacPorts libc++ which can be done using legacy support:

PortGroup           legacysupport 1.1

legacysupport.newest_darwin_requires_legacy 17
legacysupport.use_mp_libcxx                 yes

However even just enabling legacy support, without using MacPorts libc++, reveals a bug in the xcode portgroup regarding how it handles environment variables that contain more than one value, for which I will submit a fix:

sh: -lMacportsLegacySupport: command not found

Once that's fixed, if MacPorts libc++ is used, the build fails with a zillion error such as:

In file included from /opt/local/var/macports/build/_Volumes_Shared_macports-ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Source/ScriptMidiMessageClass.cpp:19:
In file included from /opt/local/var/macports/build/_Volumes_Shared_macports-ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Source/ScriptMidiMessageClass.h:21:
In file included from /opt/local/var/macports/build/_Volumes_Shared_macports-ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/JuceHeader.h:17:
In file included from /opt/local/var/macports/build/_Volumes_Shared_macports-ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_audio_basics/juce_audio_basics.h:54:
In file included from /opt/local/var/macports/build/_Volumes_Shared_macports-ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_core/juce_core.h:204:
In file included from /opt/local/var/macports/build/_Volumes_Shared_macports-ports_multimedia_ReceiveMIDI/ReceiveMIDI/work/ReceiveMIDI-1.3.1/Builds/MacOSX/../../JuceLibraryCode/modules/juce_core/system/juce_StandardHeader.h:50:
In file included from /opt/local/include/libcxx/v1/algorithm:641:
In file included from /opt/local/include/libcxx/v1/cstring:60:
In file included from /opt/local/include/LegacySupport/string.h:25:
/opt/local/include/libcxx/v1/string.h:73:64: error: use of undeclared identifier 'strchr'
char* __libcpp_strchr(const char* __s, int __c) {return (char*)strchr(__s, __c);}
                                                               ^
/opt/local/include/libcxx/v1/string.h:80:75: error: use of undeclared identifier 'strpbrk'
char* __libcpp_strpbrk(const char* __s1, const char* __s2) {return (char*)strpbrk(__s1, __s2);}
                                                                          ^
/opt/local/include/libcxx/v1/string.h:87:65: error: use of undeclared identifier 'strrchr'; did you mean 'strchr'?
char* __libcpp_strrchr(const char* __s, int __c) {return (char*)strrchr(__s, __c);}
                                                                ^
/opt/local/include/libcxx/v1/string.h:75:13: note: 'strchr' declared here
const char* strchr(const char* __s, int __c) {return __libcpp_strchr(__s, __c);}
            ^
/opt/local/include/libcxx/v1/string.h:94:76: error: use of undeclared identifier 'memchr'
void* __libcpp_memchr(const void* __s, int __c, size_t __n) {return (void*)memchr(__s, __c, __n);}
                                                                           ^
/opt/local/include/libcxx/v1/string.h:101:74: error: use of undeclared identifier 'strstr'; did you mean 'strchr'?
char* __libcpp_strstr(const char* __s1, const char* __s2) {return (char*)strstr(__s1, __s2);}
                                                                         ^
/opt/local/include/libcxx/v1/string.h:77:13: note: 'strchr' declared here
      char* strchr(      char* __s, int __c) {return __libcpp_strchr(__s, __c);}
            ^
/opt/local/include/libcxx/v1/string.h:101:74: error: no matching function for call to 'strchr'
char* __libcpp_strstr(const char* __s1, const char* __s2) {return (char*)strstr(__s1, __s2);}
                                                                         ^
/opt/local/include/libcxx/v1/string.h:77:13: note: candidate disabled: <no message provided>
      char* strchr(      char* __s, int __c) {return __libcpp_strchr(__s, __c);}
            ^
/opt/local/include/libcxx/v1/string.h:101:81: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'const char *'
char* __libcpp_strstr(const char* __s1, const char* __s2) {return (char*)strstr(__s1, __s2);}
                                                                                ^~~~
/opt/local/include/libcxx/v1/string.h:77:32: note: passing argument to parameter '__s' here
      char* strchr(      char* __s, int __c) {return __libcpp_strchr(__s, __c);}
                               ^

[kencu (Ken)]

the zillion errors looks like the include_next issue #62770

[ryandesign (Ryan Carsten Schmidt)]

Thanks! Yes, that does look similar. I wonder why it's happening, since I'm using a compiler version that should already have fixed that problem.

I wonder if it's significant that the errors over there are coming from llvm headers while the errors here are coming from libc++ headers.