ok, one more working day spent on this particular issue (should be about the 7th or 8th day by now), with the following result: can compile the static library using xcode for all desired architectures (armv7, armv7s, i386), however, the resulting library is 123.5MB big (compared to approx. 7.5 MB per architecture using llvm-gcc directly), and worst of all: it’s unstable - it usually crashes with “EXC_BAD_ACCESS” in juce::Component::ComponentHelpers::convertCoordinate (though, depending on the compiler settings, I’ve seen other failures, too, including a failed assert).
Agreed, it would in principle be possible to switch the whole APG process from linking with a single static library to linking with a static library with our code plus compiling the JUCE source code. But would the Simulink template-makefile-based build environment be one that would be supported, just in the case similar problems occur there, too?
The incremental build argument is a good one (but not the 7 seconds one: currently, the entire build process from the Simulink model to the VST plugin takes as little as 5s, depending on the complexity of the model of course, so 7 s more is very significant). It would mean though that a lot of JUCE object files will be lying around in the build directories (and Simulink Coder creates a new build directory for each model, so unless you clean up manually from time to time, you’ll end up wasting a lot of space with numerous compiled versions of JUCE - and cleaning up automatically after each build would mean that incremental builds of JUCE are not possible).
Any suggestion on how to solve this problem is more than welcome…