Fixed the dynamic link library symbol export for ARA Host classes

[FangCunWuChang]

Some ARA Host classes do not add the JUCE_API macro, which makes it impossible to export these symbols when compiling JUCE into a dynamic link library, resulting in the generated dynamic link library being unable to be linked.

[reuk]

What exactly is your use-case for building JUCE as a dynamic library in this way? Generally speaking, DLLs with C++ exports are extremely brittle. If they use C++ types in their interfaces, they may break when any one of those types (including standard library types!) changes for any reason, and it's very unwise to attempt things like throwing exceptions across DLL boundaries.

I'd strongly encourage you to consider whether your application can be structured differently, e.g. by building JUCE directly into your application. If you really need the properties of a dynamic library (for sharing common code between multiple artifacts, or to implement a plugin-like system), then it's probably best to do this through a plain C API instead.

[FangCunWuChang]

What exactly is your use-case for building JUCE as a dynamic library in this way? Generally speaking, DLLs with C++ exports are extremely brittle. If they use C++ types in their interfaces, they may break when any one of those types (including standard library types!) changes for any reason, and it's very unwise to attempt things like throwing exceptions across DLL boundaries.

I'd strongly encourage you to consider whether your application can be structured differently, e.g. by building JUCE directly into your application. If you really need the properties of a dynamic library (for sharing common code between multiple artifacts, or to implement a plugin-like system), then it's probably best to do this through a plain C API instead.

Hi, Reuk.

My partners and I are developing an open-source DAW called VocalShaper. We chose JUCE, the most popular audio application framework, as the development framework for VocalShaper's audio system and GUI.

For various necessary reasons, VocalShaper consists of multiple processes, each being an independent executable. For example, to prevent malfunctioning audio plugins from adversely affecting the main program, we separated the audio plugin scanning tool from the main program; to enhance permissions for registering file types with the operating system, we also separated the registry read/write tool from the main program.

Since these separate executables all use the JUCE framework, compiling JUCE into each program would result in multiple copies of JUCE's binary code within our application, increasing its size and build time.

In our current CI/CD pipeline, we pre-compile JUCE and some other necessary SDKs into dynamic link libraries and cache them to avoid rebuilding these libraries every time there are new code changes in the remote repository, which significantly saves CI/CD runtime.

Additionally, our application extensively uses the functionalities of various JUCE modules, and wrapping all these classes in C API is a huge task, making it nearly impossible to complete. Therefore, we rely on the JUCE_API macro provided by the JUCE framework.

In most class declarations in JUCE, the JUCE_API macro has been properly added, with only a few classes lacking this macro. We have supplemented these missing macros and attempted to submit PR to the official repository, which will not affect situations where JUCE isn't compiled as a dynamic link library.

[reuk]

Thanks for the additional information. We've pushed some fixes for DLL builds here: 90f37e2

Hopefully this will resolve the issues you've been seeing. Please let us know if you run into further problems.

[FangCunWuChang]

Thank you. This has been very helpful to us!

[FangCunWuChang]

Additionally, we found that on the Windows platform, Clang uses __declspec(dllexport)/__declspec(dllimport) for symbol export/import, while __attribute__((visibility("default"))) does not effectively export symbols.