enable macOsNative auto discovery

[i-n-g-o]

Using Controller::setAutomaticDiscoveryDelay failed dues to a AVDECC_ASSERT in ProtocolInterfaceMacNativeImpl::sendMessage(la::avdecc::protocol::Adpdu const& adpdu).

Forwarding discovery to _bridge using discoverRemoteEntities() and discoverRemoteEntity(...)

[christophe-calmejane]

Thanks for the proposal, I'll take a deep look next week (because discovery is supposed to be handled by the Mac itself, it should not be a valid use case to try to change any discovery parameters (but it should not assert though).

[christophe-calmejane]

@i-n-g-o The issue is actually located in a very different place. As the assert explains, we should never use this method (not for now at least). I entered a new ticket to make a proper fix (see #121). I've pushed a new branch (issue/121) with a fix, can you help me confirm it does fix it for you? Thanks!

[i-n-g-o]

Hi. issue/121 works perfectly and is the proper solution. Thank you very much for the quick fix!

[i-n-g-o]

Two things i come across building current dev branch on my not-up-to-date macos:

• It requires Deployment Target 10.14 (but is set to 10.13 in cmake): ('any_cast<...>' is unavailable: introduced in macOS 10.14)
• my compiler complains about a loop variable being copied in avdeccControllerImpl.cpp line 5055, better to use a reference anyways?

[christophe-calmejane]

Regarding the first point, I noticed some issues with one of the latest macOS sdk, not sure if this one falls into that category or not: there are incorrectly flagged unavailable STL classes, although there are (and were in previous sdk) in the specified OS version. The only solution I had was to copy the sdk from another computer to my new one.... not very smooth :( Can you tell me which file/line gives that error?

Regarding the second point, you are correct. When StreamFormat was a std::uint64_t, a reference was counterproductive, but it since has changed to a class and I didn't catch this one, thanks I'll fix it.

(I'll close this PR and merge the fix branch, but you should still be able to answer here)

[christophe-calmejane]

Ok so the any_cast is the one I noticed a couple months ago on another project. Here is the SDK I have on my macOS:

#   define _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS                             \
        __attribute__((availability(macosx,strict,introduced=10.13)))           \
        __attribute__((availability(ios,strict,introduced=11.0)))               \
        __attribute__((availability(tvos,strict,introduced=11.0)))              \
        __attribute__((availability(watchos,strict,introduced=4.0)))

#   define _LIBCPP_AVAILABILITY_BAD_ANY_CAST                                    \
        _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS

class _LIBCPP_EXCEPTION_ABI _LIBCPP_AVAILABILITY_BAD_ANY_CAST bad_any_cast : public bad_cast
{
public:
    virtual const char* what() const _NOEXCEPT;
};

I don't know why in the latest SDK, they changed the minimum version to be 10.14, it makes no sense... maybe I should try to compile (and force a std::bad_any_cast to be thrown) a sample and run it on macOS 10.13 to be sure. Either they messed up when releasing the SDK I have and incorrectly allowed std::any to be used (meaning std::bad_any_cast is not provided in macOS 10.13 runtime), or they messed up the following SDK by restricting too much.

[christophe-calmejane]

I quickly wrote a sample that forces a bad_any_cast throw, and I can confirm that macOS 10.13 does implement std::bad_any_cast in its runtime library. So my SDK is correctly allowing std::any_cast (and related methods), I don't know why Apple messed that up. I don't have Xcode14 available right now, but it would be great to test it and see if they fixed this. Otherwise we should be creating a ticket in Apple's radar. In the meantime, I found this workaround (although not perfect): Add _LIBCPP_DISABLE_AVAILABILITY in compile flags.

[christophe-calmejane]

I confirm Xcode 14.1 fixed the SDK issue, but not all Macs can use it :(