fluidsynth @2.1.9: build fails on Leopard i386: fluid_coreaudio.c:190: error: ‘AudioComponentDescription’ undeclared

[kencu (Ken)]

fails also with clang-7.0.

Notice also how fluidsynth is not obeying the CMAKE_OSX_SYSROOT and is instead forcing an SDK, finding a 10.7 SDK I had added to Leopard to experiment with. Not sure if that is the new cmake behaviour, or fluidsynth doing that, just now.

-isysroot /Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.5

I pegged back at fluidsynth 2.0.5 for the time being.

[RJVB (René Bertin)]

Not at my Mac right now, but isn't the missing symbol something from an Apple SDK?

I see 2 solutions:

• clamp the version to 2.0.5 (or whatever is the latest one that does build) on Leopard i386
• detect the OS version and make the use of the component description conditional.

Ken, I know you're used to doing this sort of thing, can I ask you to chose and make the changes yourself? You'd have to test anything I can come up with anyway because I don't have a Leopard i386 system...

Not sure if we really have to support having too-new SDKs installed?

[kencu (Ken)]

Yes, happy to take a look if someone else doesn't get there first. We have a growing number of interested users of older systems -- I keep advertising us over on MacRumours as the go-to package manager for these.

Replying to RJVB:

Not sure if we really have to support having too-new SDKs installed?

Here, this was at present meant to be an observation.

If fluidsynth is doing this, that is one thing. But if cmake now is doing this, that would open up a rather huge can of worms for many many ports.

[RJVB (René Bertin)]

All I can say about the sysroot thing is that on my end (10.9), cmake is called with -DCMAKE_OSX_SYSROOT="/", and I'm not getting any -isysroot arguments in the build log. My system evidently has the 10.9 and 10.10 SDKs, so if anyone were simply to pick the newest one I ought to be getting a build against 10.10.

I do see that I'm "only" at CMake 3.19.7 and not the current 3.20.5 (aargh). But I guess that means that we can exclude anything naughty being done by fluidsynth.

[kencu (Ken)]

On 10.6.8 I had repeated build failures due to "resource unavailable" errors. That was solved by disabling parallel building, in that case.

I also did not see a different SDK used on 10.6.8. But as above, it was used on 10.5. Still not sure why.

[RJVB (René Bertin)]

So your 10.6 system also has the 10.7 SDK installed? Have you looked in ${build.dir}/CMakeFiles/CMakeOutput.log (on the 10.5 system) to see if it holds any clues? What you're seeing could be an unforeseen effect of calling xcrun, maybe?

[kencu (Ken)]

cmake changed it's default behaviour in 3.19:

​https://cmake.org/cmake/help/v3.20/release/3.19.html

Building for macOS will now use the latest SDK available on the system, unless the user has explicitly chosen a SDK using CMAKE_OSX_SYSROOT. The deployment target or system macOS version will not affect the choice of SDK.

Whether that is why it is selecting the 10.7.sdk on Leopard, or whether there is yet some other broken part somewhere, remains to be seen. To be noted, we do explicitly set CMAKE_OSX_SYSROOT, so it should obey it.

I did not immediately noticed in the main CMakeLists.txt for fluidsynth how it might be doing this itself.

[RJVB (René Bertin)]

Hmmm, it could of course be that CMAKE_OSX_SYSROOT="/" is interpreted as "take the newest you can find under /", as opposed to a setting that specifies an SDK version explicitly.

But then my builds should be using the 10.10 SDK and as far as I can tell they don't. And of course you should be seeing the same issue with everything you build through cmake...

[RJVB (René Bertin)]

FWIW, cmake's /opt/local/share/cmake-3.20/Modules/Platform/Darwin-Initialize.cmake file has 2 locations that do a check of the form

if ("x${foo}" EQ "/")

which I think can never evaluate to true. So that must either be a conscious, strange way to disable the code path, or a bug. Either way this may explain whe CMAKE_OSX_SYSROOT="/" doesn't behave as expected, so I'd remove the x from the expression if I were investigating the issue!

[evanmiller (Evan Miller)]

To the original issue: It appears that fluidsynth's Core Audio driver now relies on 10.6+ APIs. To my eyes, the most "correct" solution would be improving feature detection upstream so that the Core Audio driver is disabled on 10.4/10.5, at least until a more substantial workaround is implemented by MP (or upstream).

Would there by any objection in this audience to an upstream pull request that requires 10.6 for Core Audio support? Happy to do it myself (a one-line PR), but I didn't want to get in the way of anyone planning a more significant backward-compatibility effort.

[RJVB (René Bertin)]

Would it not be possible to limit the APIs used by the CA driver, i.e. not use the component description if it's not available? That would be the most correct solution, because what other backends are available if you remove CoreAudio support? The PortAudio backend would use CoreAudio itself, for instance.

[evanmiller (Evan Miller)]

@RJVB Core Midi would still be available. Limiting the APIs used by the CA driver would be desirable, but will require more significant patch-work either here or upstream.

[RJVB (René Bertin)]

I knew I had seen and/or worked around this API change before. It's so straightforward (see e.g. ​this patch) that you could probably map the old symbols via CPP macros. Or, with luck, the change was done in a single commit and little enough changed afterwards that the corresponding diff can still be reversed.

What's the user-facing effect of dropping CA support?

[evanmiller (Evan Miller)]

It looks like 10.4/10.5 support broke with ​this commit. Since it looks like a matter of symbol remapping, perhaps the appropriate macros could be added to legacy-support.

[kencu (Ken)]

Jason has the start of such a remapping macro set underway here, fyi

​https://github.com/macports/macports-ports/blob/master/graphics/blender/files/old_appkit_compat/AppKit/AppKit.h

[evanmiller (Evan Miller)]

Proposed fix here: ​https://github.com/evanmiller/macports-ports/tree/fluidsynth-pre-snow-leopard

This just reverts the offending commit on 10.4/10.5. Will open a PR after I finish testing some other packages.

[evanmiller (Evan Miller)]

In 8ef9fd7d42e20502b5a1c066c42259294d54267e/macports-ports (master):

fluidsynth: Fix build on Tiger/Leopard

Backport upstream fluidsynth patch to support deprecated Core Audio
symbols on legacy systems.

See: ​https://github.com/FluidSynth/fluidsynth/pull/947
See: #63230