However, I need to build a static library for iOS from some code that is built on top of JUCE. Any ideas how I can manage that?
So far I define the SDK and architecture that I want to use (e.g. iPhone Simulator, i386, or iOS device, armv7s) by using the appropriate -isysroot and -arch flags. But still, I get some strange errors like:
juce_ios_UIViewComponentPeer.mm:919: error: ‘UIStatusBarAnimationSlide’ was not declared in this scope
How can it happen that the .h file that defines the corresponding enum is not included?
after spending several days on this problem, I found out that it actually works fine to compile a library for actual iOS devices (i.e. for ARM architectures), but the problem persists when compiling for the simulator. Here’s some more precise information:
My compile command for the simulator is:
$COMPILER -DNDEBUG -ObjC++ -O3 Source/*.cpp -c -arch i386 -isysroot $SIMSDKDIR
while the command for the devices is:
$COMPILER -DNDEBUG -ObjC++ -O3 Source/*.cpp -c -arch armv7 -arch armv7s -isysroot $SDKDIR
where
COMPILER="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/llvm-gcc-4.2"
SDKDIR="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk"
SIMSDKDIR="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk"
(yes, I did leave out a few -I and -D flags which are identical between the two commands and which should not affect this problem).
Does anybody have an idea where the problem could be? Why does compiling for the simulator behave differently from compiling for the devices? It by the way seems to affect only the UIKit, since many files actually compile fine also for the simulator.
Thanks a lot in advance for any sort of help with this problem!!!
Some additional information that may help to find the source of the problem: before the actual error, there is also this warning:
[…]/juce_ios_UIViewComponentPeer.mm:35: warning: class ‘UIView’ is unavailable
Update: I contacted Apple developer support concerning this problem and they told me they are not providing support for this kind of problems. They also literally told me “You will need to contact the author of JUCE for assistance with integrating it with your project.”, which is basically what I’ve been doing since February 13th in this forum, without success.
So dear Jules, could you pleeeaaaase have a look at this problem? I can also send you a zip file with a shell script that reproduces the error in order to facilitate the process of solving the problem (it’s > 5 Mb, so I’m waiting for your response before sending it to you).
This really is an issue we definitely have to solve in order to enable iOS support in the audio plugin generator.
And like Apple, I’m very happy to help with actual bugs in my code, but can’t be expected to do your job for you… If you choose to try to stuff my code into places it wasn’t designed for, you’re on your own!
thank you for your reply. Please try to understand our situation a bit: we bought a JUCE license specifically to develop our Audio Plugin Generator product, which relies on a static library that can be linked with code dynamically generated by Simulink. And since then we’ve invested the full-time equivalent of several months of work in improving and extending the APG. I am just hoping you’re not trying to tell us that you are not willing to give any kind of support for this application anymore?
That’s unfortunately not an option since it would mean that each time one wanted to export a Simulink model to VST or iOS, the JUCE library would have to be compiled. That would definitely go against the whole idea of a rapid prototyping tool…
No… I’ll support any problems you find in my code. Any bugs you find, I will fix, etc. But if you decide to take my code and squash it into a build system that it wasn’t designed for, then it’s a bit cheeky to expect me to help you to make your own build system work!
All C++ classes can be compiled into static libraries if you want to, and juce is no exception to that. I hope you manage to get it going. And if you find any specific things in the codebase that cause you trouble in what you’re doing, and want to request me to change them, fire away! But helping you make your own build system work is way beyond my responsibility, I’m afraid.
Have you timed it before making that assumption? As discussed on another thread, my laptop can compile all the juce modules in < 7 seconds, and obviously that’ll only happen once if you’re doing incremental builds. I’ve done static libs in the past, but would always avoid them where possible now.
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…
Bingo! It turned out that NDEBUG was not defined in the static library project. Now the apps run reliably and actually the library size shrank to about 100 MB. Thanks a lot for the hint.
Basically, Simulink allows to create models of dynamical systems, similar to pure data or Max/MSP, but with many of advanced features like multiple sample rates in a single model, a lot of different datatypes, etc. Using an extension called Simulink Coder it allows also to create plain (but pretty unreadable) C code from these models and to compile this code, where everything from the code generation process to the compile commands is customizable using hook functions (Matlab .m files) and special target language compiler scripts (to be written in a funny scripting language apparently inspired by Perl and HTML and where almost everything has to be preceded by a percent sign). Under Windows, when Matlab is configured to use the VisualStudio tools, the final compilation and linking step is done using nmake.exe, so from there on it’s pretty standard.
However, since it seems that finally the static library is working on all platforms, we prefer to stick to that solution.
