Windows linker issue on develop

1

:wave:

I’m getting the following linker error:

error: undefined symbol: bool __cdecl juce::detail::isRunningInUnity(void)

This occurs on

  1. develop
  2. Windows only
  3. Only targets that have the JUCE target as a dependency

The JUCE targets themselves seem to build fine. Mac/Linux also seem fine.

You can see it happen on an Catch2 target linking against a JUCE target here: Bump JUCE develop · sudara/pamplejuce@ef77da5 · GitHub

I tried 8efadd1 and it didn’t exhibit the problem. I suspect the issue comes from some of the plugin client reorganization stuff after this commit (cc @reuk).

2

Thanks, I see what’s going wrong. We’re currently trying to determine the cleanest solution, but should have something out shortly.

Tangentially-related: when I build your project locally with ClangCL, I get quite a lot of duplicate symbol warnings (ODR violations) when linking the test target. I think the problem is that the JUCE_DEPENDENCIES are linked separately to the plugin target and the test target. JUCE modules are interface targets, which means that they are built separately for each non-interface target that links against them. In turn, this means that the test binary contains two copied of the JUCE modules; one from the plugin shared-code target, and one linked directly to the test target.

To avoid the ODR violations, you could consider only linking JUCE_DEPENDENCIES to the shared-code target, then re-exporting the shared-code target’s preprocessor definitions and include directories. That way, when you add the shared-code target as a dependency of the test target, the test target will still inherit all of the JUCE flags and include directories.

target_compile_definitions(${PROJECT_NAME} INTERFACE $<TARGET_PROPERTY:${PROJECT_NAME},COMPILE_DEFINITIONS>)
target_include_directories(${PROJECT_NAME} INTERFACE $<TARGET_PROPERTY:${PROJECT_NAME},INCLUDE_DIRECTORIES>)
2 Likes
3

Ahhhhh, I’ve been wondering about how to do this! This is really useful, thank you for the heads up and solution…

4

This should now be fixed on develop:

1 Like
5

Just wanted to follow up and say that this worked, but we’re having some debate over on the pamplejuce repo about the visibility of modules.

Basically, our Tests target might need to specify different compile definitions, such as JUCE_MODAL_LOOPS_PERMITTED=1 or RUN_TESTS_IN_MODULES=1 — to accommodate this, it seems like there would need to be two compiled shared plugin targets?

We’re not quite sure how to approach that with the shared plugin target. I’ve been doing everything wrong (setting my modules to PUBLIC visibility) and that’s somehow been working for me with no linker warnings…

6

For some reason I wasn’t ever able to set additional definitions via target_compile_definitions for our Test target when going the “copy defs and dirs from the plugin target” route.

I’ve tried out @chrhaase’s suggestion of creating an INTERFACE target that houses the shared app code and definitions. The main juce shared plugin target as well as the Tests target then link to that.

target_link_libraries("${PROJECT_NAME}" PRIVATE SharedCode)
target_link_libraries(Tests PRIVATE "${PROJECT_NAME}" SharedCode Catch2::Catch2WithMain)

Things seem happy now, but thought I’d share in case this is still unideal in some way. The other route I considered was just setting up a cmake flag/option, but that’s sort of bulkier/more manual…