search

surge-synthesizer / surge

Synthesizer plug-in (previously released as Vember Audio Surge)
https://surge-synthesizer.github.io/
GNU General Public License v3.0
3.15k stars 400 forks source link

Linux VST2: undefined references for __cpu_model, __cpu_indicator_init #130

Closed whydoubt closed 5 years ago

whydoubt commented 5 years ago

As a quick-n-dirty check for undefined references on Linux, I run

ld -o /dev/null target/vst2/Debug/Surge-Debug.so

I get __cpu_model and __cpu_indicator_init reported as undefined. I found that it seems to be related to the use of __builtin_cpu_supports. It can be fixed in one of two ways: link with gcc instead of g++, or add libgcc and libgcc_s to the libraries to link.

I wondered if anyone else had seen this?

This is on current master (5e6a7351) with no changes to it or vst3sdk,

rm -rf *.make Makefile obj target
VST2SDK_DIR=... premake5 gmake
make surge-vst2

It applies to the release version as well. I read that this was supposed to be fixed in gcc 6, but I am using gcc/g++ version 7.3.1 on fedora 27.

19

baconpaul commented 5 years ago

That ld trick is cute. I always used a version of nm -g and grep and un-doing the name mangle in my head.

Anyway I can't build VST2 but I can build VST3 and then I get __cpu_mode and moduleHandle being undefined as well as all the stuff in SurgeVst3EditController which didn't build on mac.

baconpaul commented 5 years ago

Apologies for screenshots. My VM isn't copy and pasting to my browser properly.

With these three diffs

First stub out SurgeVST3EditController just like I did on mac (two diffs)

screen shot 2018-12-20 at 7 30 42 pm

Second add -lgcc_s and -lgcc to premake5.lua

screen shot 2018-12-20 at 7 32 03 pm

your LD trick shows me

screen shot 2018-12-20 at 7 33 04 pm

Without the premake change I also see __cpu_blah and without the ifdef a bunch of SurgeVST3Blah

Can you try with those diffs?

whydoubt commented 5 years ago

I actually have several patches prepared for all of these. Just checking if others were getting them. Note: I have submitted a fix for the missing getTicks64 reference to Steinberg: https://github.com/steinbergmedia/vst3_base/pull/1

baconpaul commented 5 years ago

Oh OK cool I'll stop hacking on them then. You added linuxmain to the vst3 files for linux too? That got rid of moduleHandle.

Is there something to do about getTicks64 while we wait for steinberg? Could we include a patch file that we apply for instance?

whydoubt commented 5 years ago

I wasn't using linuxmain before, but I will be now. It looks like it will solve a couple of other things I was doing another way.

baconpaul commented 5 years ago

Hey cool! Feels like we are closing in on a working VST3 on Linux! Nice.

whydoubt commented 5 years ago

I know I'm getting off-topic, but oh well....

FWIW, I have gotten the GUI partially visible from the VST SDK's editorhost but there are still several other things that need to be ironed out in Surge and the SDK just getting to that point. It's pretty hacked together at this point. I haven't found any VST (2 or 3) plugins using VSTGUI4 on Linux, besides those in the SDK, and Surge isn't using VSTGUI4 the way those plugins are at all.

baconpaul commented 5 years ago

Hmm ... sounds tricky. Do you have those patches in a way which we could non intrusively merge so other people can look? But I’m sympathetic - I went through a few tries before I got Mac au to a point where I was even willing to think about a pr!

Also curious how the ui code is different.

jarkkojs commented 5 years ago

This issue must have been caused by me with the changes to CpuArchitecture.cpp. Checked but I don't see cpu_* to be undefined. My GCC version is gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0.

jarkkojs commented 5 years ago

@baconpaul I'd just SSH to the VM.

jarkkojs commented 5 years ago

BTW, what is the function of vst2wrapper.cpp and vst2wrapper.sdk.cpp?

jarkkojs commented 5 years ago

I looked into another open source synth called Tunefish. Their evolution with the UI was

  1. VSTGUI
  2. Qt
  3. JUCE

Would be interesting the know for long-term plans what were the core reasons to eventually migrate to JUCE and is that something that we should consider in long-term. With my VSTGUI experience I can't really tell. Maybe @asimilon has some views on this because he at least has the JUCE repository forked.

asimilon commented 5 years ago

I just forked that yesterday to add in some newer hosts in their host detection code, as we are using it in my day job and so for the people signed up to analytics it's good for us to know about the newer hosts :) I like JUCE as it's what I started off with for audio plugin dev. If there is a specific reason to migrate (something JUCE can do that VSTGUI doesn't) then I can see the value, otherwise it feels a bit like "if it ain't broke, don't need to fix" :) tbh though I haven't really been looking at any of the code, my involvement in this project has just been in the build and package process so far, and that was all I was really interested in, as I used it before, but since upgrading to Cubase 9.5 which doesn't support 32bit plugins without a bridge I was SooL. Having said that I haven't really had a chance to play with it beyond testing that it loads and produces some sound, so I don't know if there are any problems that need addressing. edit : just occurred to me that perhaps VSTGUI isn't supporting Linux? I guess that would be a pretty big driver if you're interested in Linux (personally I have zero love for Linux desktop, only care about it server side).

jarkkojs commented 5 years ago

Yeah, definitely better to fix what we have first to see where the cracks are kind of. Still, something to reconsider when things get more stable. Here is the link to Tunefish: https://www.tunefish-synth.com/. Tunefish has been developed by pretty capable people and they must have really good reasons why they have moved to that direction. I think I'll drop an email and just ask.

jarkkojs commented 5 years ago

Emailed. Hope we get some feedback :)

baconpaul commented 5 years ago

I think the practical reason for why this isn’t a JUCE application has, at least in part, the fact that it was version 1.0 in 2005. I agree that JUCE could make a lot of our wrangling easier - it’s a pretty good bit of kit with a great license for open source projects - and could also save us pain on things like an AUv3 port in the future.

But I also completely agree: We should get what we have working and maybe call it a version “1.7 open source” or some such and then do some sort of re-plan pow wow. If you ask me, that 1.7 should be close to current surge with bugs fixed and compatible formats on all three OSes. Maybe not 32 bit but definitely one or both VST and AU.

jarkkojs commented 5 years ago

@baconpaul, fully agree.

whydoubt commented 5 years ago

Having poked at both Surge and VSTGUI on Linux for a bit now, I feel that VSTGUI on Linux is rather unstable. Some things are getting fixed, while others get broken. It's no wonder I wasn't finding other Linux VST plugins using VSTGUI.

jarkkojs commented 5 years ago

My wild guess is that it is the conclusion that they ended up with Tunefish.

baconpaul commented 5 years ago

Rewriting the ui and build deploy process in juce is “a lot of work” though. Is that work which you conclude is needed? Or is there some other idea of what to do?

Also what’s needed to run it and see the bugs? Currrmt master isn’t even that far is it?

Thanks!

jarkkojs commented 5 years ago

We could target 1.7 release DoD that it works for macOS and Windows. I do agree that it would be grazy to do any type of switch right now. Still waiting response from Tunefish devs. That is worth looking through. But yeah, that is what I think would be sane way to manage this project further with the current knowledge.

jarkkojs commented 5 years ago

If we ignore the GUI, most of the time fixing something for macOS, will fix it also for any *nix.

baconpaul commented 5 years ago

@whydoubt lots of folks in #19 reporting that Linux links so i think this particular symbol issue is resolved. So I’m going to close this ticket.