ld: framework not found coreaudio

[ryandesign]

Hydrogen version * : 1.2.3
Operating system + version : macOS (any)
Audio driver + version : CoreAudio

---

Hydrogen fails to link when building on macOS with a case-sensitive filesystem.

The link line contains the flags -Xlinker -framework -Xlinker coreaudio -Xlinker -framework -Xlinker coremidi

The error message is:

ld: framework not found coreaudio
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The correct capitalization of these framework names is CoreAudio and CoreMIDI, respectively.

See also #1865.

---

[theGreatWhiteShark]

Bummer!

Unfortunately, I do not have access to a case-sensitive macOS and can not reproduce it or check whether a patch is sufficient.

The correct capitalization of these framework names is CoreAudio and CoreMIDI, respectively.

See also #1865.

In case of CoreMIDI I understand the problem. One of the header files was spell all lower-case.

But we do not seem to import a "coreaudio.h" directly anywhere. Our CoreAudioDriver uses

#include <AudioUnit/AudioUnit.h>
#include <AudioToolbox/AudioToolbox.h>
#include <AudioUnit/AudioComponent.h>
#include "CoreServices/CoreServices.h"

Well, there is a reference in CMakeLists.txt

find_helper(COREAUDIO CoreAudio-2.0 coreaudio.h coreaudio)
find_helper(COREMIDI CoreMidi coremidi.h coremidi)

But this smells more like a problem that would occur during build time and I wonder how the first line would mess up linking since we do not directly import the header.

@ryandesign could you tweak the lines above and check whether this would fix the problem?

@cme any idea?

[ryandesign]

The problem is not at compile time and the problem is not headers; the problem is at link time due to the miscapitalization of the framework names which stand in as libraries.

You could easily create a case-sensitive volume on an existing APFS partition, or create a case-sensitive disk image, and build there. But even that is not necessary to verify a fix. All that's needed is to look at the build log. If it says -Xlinker -framework -Xlinker coreaudio -Xlinker -framework -Xlinker coremidi, that's wrong. If it says -Xlinker -framework -Xlinker CoreAudio -Xlinker -framework -Xlinker CoreMIDI, that's right.

Thanks for pointing out that spot in CMakeLists.txt; I had not immediately been able to find it. Perhaps I will have time to test a fix later.

[cme]

Yeah I think the CMakeLists.txt miscapitalisation will be responsible.

I don't think that reproducing this is as simple as creating a new case-sensitive volume and building from there, as the name lookup failure is for libraries that are on the system volume, so it would need a fresh install of macOS and dev tools on that as well.

I think the most reasonable way forward is for @ryandesign to try changing the capitalisation in CMakeLists.txt and verify that fixes their issue (PR it if you like) and the regular Appveyor builds verify that it doesn't regress on the case-insensitive build?

[theGreatWhiteShark]

You could easily create a case-sensitive volume on an existing APFS partition, or create a case-sensitive disk image, and build there.

I do not have access to a macOS device. The only thing I can check is whether it breaks the build in our case-insensitive AppVeyor pipeline. Otherwise it would have been fixed along with #1865. So, instead of me changing a line in the CMakeLists.txt and hoping the problem will be gone in the next patch release, it would be great - as @cme already said - if you could make a PR and verify that the build is indeed working.