I notice the plugin wrappers are all in the “shared code” part of the project.
It seems that moving them to the individual plug-format targets could let you have multiple plugins in the same project (like a delay and a filter or something).
You can’t currently do that (at least, with any shared code), since the juce_core code seems to want an entrance point now (ie. createPluginFilter()).
Any chance we could figure out a way to have multiple plugins in the same project? It was fairly easy to do in the old polymorphic way.
How does one go with stripping symbols in the new scheme?
By previously running strip in a post-build step our plugins only exposed 13 required symbols, which can be checked by doing nm <EXECUTABLE> -s __TEXT __text.
Looks like all the symbols in the framework are exposed now. This is a major concern for developers of closed-source software.
Besides exposing all the symbols the framework also leads to bloat. Can OSX load only the needed parts of a framework to memory or do plugins now use more memory due to larger binaries?
Wouldn’t it be possible to offer the option to link with a static library instead of a framework? That way symbol stripping and dead code stripping could work.
I also imagine the framework build doesn’t work very well with some copy protection schemes.
Is this actually the case? And if yes, what copy protection schemes are breaking? This would be great for us to know as we are thinking about how to further improve the plug-in build mechanism.
I totally agree with you pflugshaupt, I guess however that having static libraries could increase build times due to the linker stage?
At the moment we handle exported symbols using an exported symbols file to explicitly declare the symbols to export. I haven’t tried this with JUCE 4.2 yet but I suspect this won’t work (at least not without an impressive post-build script). As I assume the exported symbols file will be applied to both binaries (Shared code and which ever wrapper I’m building), Unfortunately if the exported symbols file contains any symbols NOT in the binary it will fail. Plus I assume the process becomes more complex as the file would need to include various C++ symbols so that the wrapper can access them, right?
As it stands I think for me a static library could possibly be a better option even if it means increased build times!
I would also like to express that although I think a great deal of JUCE and it really is a fantastic library, in future when you are planning to make fundamental changes like this it would be greatly appreciated if you can announce the upcoming change as soon as possible… but at the very least add it to the release notes. Unless I’m sadly mistaken this post from pflugshaupt is the only place where this change has been documented.
I haven’t really tested JUCE 4.2 yet because of all the uncertainties it brought along, I will wait a little until the dust settles… However, my protection is dependent on a external copy protection software being able to search and access/modify a single executable (Mach-O) file that contains the required byte markers etc. I also need the software to be fully functional when every symbol not absolutely needed is stripped away.
We are trying out the static library approach right now! Hopefully it won’t increase the build times too much because it still has to compile the shared code only once, there’s just a bit more linking to do. And yes, obviously we’ll add stripping symbols, we just overlooked that with 4.2.
The new version with the static library instead of the framework fails compiling the standalone version with Scheme (AUv3 AppExtension):
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
(maybe you meant: __ZN4juce16jpeglibNamespace23jinit_c_main_controllerEPNS0_20jpeg_compress_structEh, __ZN4juce16jpeglibNamespace23jinit_d_main_controllerEPNS0_22jpeg_decompress_structEh )
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
EDIT: This is because i have reverted temporarily back the Deployment Target to 10.7. Since AUv3 cannot be compiled with anything less than 10.10 as Target, would be cool to have it set automatically by the jucer to 10.10 for the AUv3 Scheme and whatever you specified in the Projucer xcode exporter settings for the VST and AUv2 Schemes. This way i’m not forced to use 10.10 for those other formats, for which i would like to maintain compatibility with 10.7.
I think this is not going to work because most of your code will be compiled only once (the shared code part) and then the plug-in wrappers link to this statically. So you can’t use different build settings for different plug-in formats. This was never possible with the old polymorphic build, either.
What we can do though is check for <10.10 if you have AUv3 ticked, and give a warning, so peoplewon’t run into the same problem with the plug-in not compiling.
makes sense. anyway since there is no use for AU3 in any host at the moment i will disable it.
the only drawback is that it enabled the standalone build, which was really convenient and fast for testing changes right away without the hassle of starting a full host. would be cool if you could enable the standalone build even when not building AU3, wouldn’t be hard to do it as the StandaloneFilterWindow is there.
Thanks for addressing the framework issue and making it a high priority, the new static approach looks good to me and the newly added strip symbols options in projucer is very nice!
That is absolutely not true, there are hosts like GarageBand and Cubasis that can host AU3 on iOS, which is pretty cool and works well with JUCE 4.2.
Yep, this is definitely planned as we think it’s cool, too. We didn’t quite finish this for the JUCE 4.2 release, because we wanted the standalone build to also work on Windows and Linux, too, but didn’t have time to implement the multiple targets stuff necessary for it. I think we’ll add this very soon, though, as it is really useful.
I can guarantee you that neither me, nor Jules, nor Fabian deleted any posts in this thread. We care about the concerns of our customers very much and take it very seriously, we’d never just make it “conveniently disappear” like that.
I think there was one post here that was deleted by the poster himself. (don’t remember what it was about though.) There is also another thread about this whole topic going. Maybe you were looking for a specific post in the wrong thread or something?
Oh sh**t I’m sorry it’s my fault, I didn’t notice there were two similar threads (the one i think of is the “bloat” thread)… I take it all back! not the good critique of course)
@kraken now added a more meaningful compile error that Xcode will display to the user if you try to compile AUv3 with 10.7, to avoid future confusion due to the “undefined symbol _main” error you posted above. This should not happen anymore.
not the good critique of course)