Surge: Doesn't compile on xcode 9.4.1

[Jurek-Raben]

Hi,

I was not able to compile the VST3 version using High Sierra and XCode 9.4.1 so far, since I ran into multiple issues. Surely it is because I have no idea what I am doing :)

• Patched build-osx.sh to use premake5 instead premake4
• Some strange header include errors, fixed by using "always search user paths"
• Then libc++ problems with the math calls, "filesystem" not found.Adding header path "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/" did not work

[Jurek-Raben]

SurgeStorage.h:20:10: 'filesystem' file not found
it is not part of libc++ in xcode 9, cannot find it under "experimental/" either.
https://stackoverflow.com/questions/42633477/macos-clang-c17-filesystem-header-not-found
Seems that it will work with xcode 10, using experimental/filesystem.... Will do a system update soon.

[Jurek-Raben]

No change with xcode 10 on 10.13.6.

[asimilon]

using brew install llvm and some of the instructions here, I've managed to get beyond <filesystem> not being available to Xcode 9.2 (I'm trying to build on Sierra)
But got stuck with some Cannot initialize a parameter of type 'wchar_t *' with an lvalue of type 'Steinberg::Vst::String128' (aka 'Steinberg::Vst::TChar [128]') errors instead in calls such as SurgeSynthesizer::getParameterNameW when trying to build VST3.
I've got much further with VST2 (some errors to do with undefined symbols from filesystem, I suspect I've missed some linker flags).
AU complains about missing plugin.h.

[kurasu]

I think you could safely change these method to take a char* instead of a wchar_t* as it only assembles chars anyway in these 4 methods. (and then use swprintf and so on)

Longer term a better strategy would be good how to deal with strings at these layers in a nicer way, but for just getting mac building i'm happy with changing this.

[asimilon]

OK, so that didn't help, and it also made VST2 start complaining about no viable call to the swprintfs within those methods, but leaving those as wchar_t * I've succesfully built VST2 now!

[kzantow]

@kurasu any issue just changing usage of <filesystem>, which seems to be just fs::path to string?

EDIT: ehhh.. cross-platform operations like directory exists

[asimilon]

fs::directory_iterator is used too, there may be more

[kurasu]

yeah, i was moving over to using filesystem in order to make linux porting easier no that its finally moving into the c++ spec, but it seems macOS is lagging here. But using the experimental namespace should be ok with homebrew llvm, right?

[asimilon]

I had to remove the experimental portion of the namespace for it to build.
I pushed a separate branch on my fork so that others can build if they wish
but will look into how I can get it to work with premake before issuing a
pull request.

[esaruoho]

~using homebrew install llvm~

~@asimilon you wanna do brew install llvm instead? i pasted in your string and immediately got a "homebrew command not found" error ;)~

thanks for editing it, correct thing now referenced.

[esaruoho]

• Patched build-osx.sh to use premake5 instead premake4

hi @JurekR i'm just wondering, I don't find premake or premake5 on brew, and they don't seem to be a part of my macOS Mojave install or part of Xcode. If I run ./osx-build.sh all I get are tons and tons of errors.

./build-osx.sh: line 2: premake5: command not found
xcrun: error: active developer path ("/Applications/Xcode-beta.app/Contents/Developer") does not exist

seems like i can find premake5 from https://premake.github.io/download.html but is there no other way of getting it installed prior to running osx-build.sh? some way of tweaking osx-build.sh so it suggests downloading that, or even opens a browser window to download it first?

[Jurek-Raben]

Download and install it manually from premake webpage, there is a binary package.

[esaruoho]

thanks @JurekR i was able to progress with premake5 further and then downloaded vst3sdk from somewhere and.. am currently seeing this issue:

which i hope is just a path change away from working. mostly trying to get audiounit to work on osx.
(logged this issue at #31 )

[Jurek-Raben]

Did you do a "git submodule update --init --recursive" as stated in the readme? It should download the missing VST SDKs. Though I only tried to build the VST2 version so far, and kurasu seems to be pretty busy with upcoming Bitwig version now.

[esaruoho]

@JurekR yep, after doing the submodules, i was no longer having as many issues - other than the pluginterfaces/base/ path duplication (logged at #31) and plugin.h missing, of course.

[esaruoho]

AU complains about missing plugin.h.

yep, same issue here. not sure how to solve it, since i don't know what plugin.h should be, or what it should contain? logged this issue at #34

[esaruoho]

@JurekR are you still working on making this compile?

[esaruoho]

@kurasu

I think you could safely change these method to take a char* instead of a wchar_t* as it only assembles chars anyway in these 4 methods. (and then use swprintf and so on)
Longer term a better strategy would be good how to deal with strings at these layers in a nicer way, but for just getting mac building i'm happy with changing this.

how does one change the wchar_t * to take a char* instead? :)

[esaruoho]

OK, so that didn't help, and it also made VST2 start complaining about no viable call to the swprintfs within those methods, but leaving those as wchar_t * I've succesfully built VST2 now!

hi @asimilon - when you say you successfully built a vst - were you able to load it into any VST-supporting DAW? I have also been able to get a Surge.vst to appear, but when copying it to the plugins/VST folder, no app (Renoise, Ableton Live) is able to recognise it as a valid VST on macOS. Any ideas?

[kzantow]

@esaruoho I'm using xcode 10 and have the same problem -- got it compiling (submitted a patch), but it doesn't show up in any DAW. I am too much of a C++/VST/etc. noob to know exactly what the issue is, but I assume it's something to do with either a) files not being included in the contents of the .vst or b) not correctly building a shared library. I'll try to experiment a bit today and see if I can figure out the issue on my platform, probably the same as xcode 9...

[kzantow]

I think I may have figured this last bit out but now running into a build issue getting VST2 built. sigh

[kzantow]

I found a few things so far, but I figured out how to get plugin loading messages out of Bitwig, and it says:

2018-12-08 11:59:03.552 BitwigPluginHost[14732:14822587] Error loading /Library/Audio/Plug-Ins/VST/Surge.vst/Contents/MacOS/Surge:  dlopen(/Library/Audio/Plug-Ins/VST/Surge.vst/Contents/MacOS/Surge, 262): no suitable image found.  Did find:
    /Library/Audio/Plug-Ins/VST/Surge.vst/Contents/MacOS/Surge: mach-o, but wrong architecture

... getting closer, and at least I have a way to know what's going on during loading (at least in one host).

[kzantow]

I tried explicitly building x86_64, verified the dylib was correct:

$ lipo -info target/vst2/Release/Surge.dylib
Non-fat file: target/vst2/Release/Surge.dylib is architecture: x86_64

Verified the host had the same architecture (Bitwig has both 64 and 32 bit host processes):

$ lipo -info /Applications/Bitwig\ Studio.app/Contents/MacOS/Bitwig\ Plug-in\ Host\ 64.app/Contents/MacOS/BitwigPluginHost 
Non-fat file: /Applications/Bitwig Studio.app/Contents/MacOS/Bitwig Plug-in Host 64.app/Contents/MacOS/BitwigPluginHost is architecture: x86_64

(and also the binary in the VST directory)

lipo -info /Library/Audio/Plug-Ins/VST/Surge.vst/Contents/MacOS/Surge 
Non-fat file: /Library/Audio/Plug-Ins/VST/Surge.vst/Contents/MacOS/Surge is architecture: x86_64

But still it's reporting the same error, so I'm at a bit of a loss what to do now, any ideas?

[esaruoho]

@kzantow awesome! renoise and ableton live just don't recognize it at all, so it's good that bitwig gives some sort of data :) thanks for checking it out!

[kzantow]

Yeah, I found someone had a similar problem with JUCE plugins: https://forum.juce.com/t/logic-9-ignores-the-component/18764/11

It must be some obscure setting in my xcode config, but I've changed a ton of the things to no avail as of yet...

[kzantow]

I know very little about assembly programming and how it affects binaries, could it be that some of the __asm blocks targeting MAC are changing the architecture somehow?

[esaruoho]

@kzantow are you able to use http://github.com/tracktion/pluginval to be able to get some more validation out of the VST2/VST3? :)

[esaruoho]

@jurekr how are things post #92 PR getting merged in? Still the same issue?

[baconpaul]

So with all the PRs in the last week, multiple people have built on Xcode 9.4.1 10 and 9.2 all, fixing many of the errors which went by in this thread. So I’m going to close this issue. @JurekR if you pull to the top of master and follow the new README instructions you should get a good build. If not please let us know!

[esaruoho]

@JurekR were you looking to build a 32-bit macOS VST2,VST3,AU or 64-bit? If you were interested in trying to make it compile 32-bit versions, please join the conversation at #115 if you have something interesting to add.