Copy AU/VST/RTAS script

[zamrate]

On the Mac, there's this script that copies AU/VST/RTAS in their specific dirs. For me the copyVST flag is never set, because no symbol found that contains 'VSTPlugin', this is in the line:

Code: Select all

copyVST=1 #`nm -g "$CONFIGURATION_BUILD_DIR/$EXECUTABLE_PATH" | grep -i 'VSTPlugin' | wc -l`

For AU it works. And if I copy the .component into the VST dir and rename it, it also works. I assume that this test is wrong or not foolproof.

[jules]

Can't see anything wrong with that, and I've been using the same script for years... Have you tried running a

Code: Select all

nm -g whatever_your_exe_is_called | grep -i 'VSTPlugin'

to see what happens?

[zamrate]

Yes, nothing happens. But with 'AudioUnit' there are 3 entries.

[zamrate]

Hmm, weird. In the JUCE demo plugin "VSTPluginMain" actually shows up. In mine, it does not. But the plugin still works! That's mysterious.

[zamrate]

Another thing is that I can find it in my plugin using a Hex Editor, but only 2 times, although it should be 3 times (ppc, intel32, intel64).

[jules]

Silly question, but are you sure you enabled the JucePlugin_Build_VST flag?

[jules]

ah.. maybe the 'nm' command is looking at the wrong section of your binary, e.g. if you've built the 64-bit as only an AU, but the 32-bit as VST/AU, then if 'nm' only looks at the 64-bit symbols, it'd fail..

[zamrate]

Yes, the JucePlugin_Build_VST flag is set.
But what's weird is, I just did an extra check. I compiled again as 32/64Bit Universal binary (AU+VST in one).
AU works for all platforms (PPC/Intel32+64), but VST only works for Intel. Could there be something wrong with a condition in the VST wrapper? I'll check now...

[zamrate]

Hmm, try building as 64 Bit Intel only. After that, nm -g JuceDemoPlugin.component/Contents/MacOS/JuceDemoPlugin | grep -i 'VSTPlugin' doesn't produce anything. But when using 32 Bit Universal as architecture setting, then you'll get 2 values!

[jules]

hmm.. Anyone know if there's a command-line option for 'nm' that tells it to open a 64-bit binary?

[Franky47]

Yes, it seems there is:

Code: Select all

nm -arch yourarchname
or
nm -arch all


I had the same problem, I thought the symbols were stripped during the link step, but it seems they were just hidden in an other section of the binary.


I'm building a universal 32/64 bits (i386 and x86_64 archs) plugin in VST/AU/RTAS, here is what I have:

• AudioUnit: symbols are present in both archs.
• VST: _VSTPluginMain symbol is only present in i386 section.
• RTAS: _CProcess* symbols are only present in i386 section.

Maybe some of the symbols are shared between 32 and 64bit?

[Salvator]

Hello Jules,

Here the RTAS doesn't get copied when in universal 32-64 bits.
Is there any solution that could be implemented inside the introjucer's script ?

Thanks !

Salvator

[jules]

Hello Jules,

Here the RTAS doesn't get copied when in universal 32-64 bits.
Is there any solution that could be implemented inside the introjucer's script ?

Thanks !

Salvator

I don't understand.. why would the binary format make a difference to the process of copying the file?

[Salvator]

I don't understand either. it seems to be picky and not consistent on my machine...

But at least, more recently, it's definitively broken since the tip of 19 May GIT :

Removed some unnecessary files from linux plugin builds.

From then, even the juce plugin demo don't get copied as RTAS. And I'm not on Linux either
With the tip before that, it works.

Salvator

[jules]

Ok, try it now..