Linux Ubuntu 16.04 - exported standalone / plugins not starting
-
@andioak It shouldn't be neccessary but since that OS isn't working for you it might be a good idea to compile on that OS to check.
Can you send me the standalone and I'll test it on my system? I'm running Debian Buster which is later than Ubuntu 16 but should still provide some useful info.
Are you testing a debug build or release build?
-
@d-healey Release build. Never tried a debug. But I´ll send you a copy for testing, thanks a lot! Perhaps the compiler from your video (or the version apt installed in the end is too new)..
-
@andioak Debug is better for... debugging :p You'll get more useful error messages/crash reports.
-
@d-healey hahaha, got it. Will test a debug as well. But perhaps my compiler needs to be another, an older one or different? Perhaps Debian 10 is to be preferred for all debian based OS:es? It´s the origin after all. And then do another for Arch, on actual Arch or Manjaro.
-
@andioak Debian 10 is the latest stable. Ubuntu 14 is Debian 7 I believe.
-
@d-healey so too new then. Would have worse backwards compatibility. Linux should be called "distro-wars" instead :)
-
@d-healey said in Linux Ubuntu 16.04 - exported standalone / plugins not starting:
Can you send me the standalone and I'll test it on my system?
Just sent a folder for testing. PM.
-
Both the standalone and VSTi (in Ardour) work on my computer so I suspect the problem is with your Ubuntu 16 system rather than your Linux Mint 17 system.
-
@d-healey Lovely to hear! I love when it´s just me, especially regarding instruments I build that for unknown reasons dont run on my own systems hahaha.
So that´s great, but I think HISE / JUCE may have set the bar a bit too high/low. In regards to CPU support. It seems that my Iintel Xeon X56xx system was too old for it. That´s in spite of it being 4 generations newer than the first one using SSE 4.1 instructions, that has been mentioned in the docs as being the requirements of a CPU that can be supported without "Legacy CPU support" in the settings.
This is the same processor/cpu that was in the Mac Pro models. So I´m worried about support for very normal studio computers out there, if you don´t set legacy cpu support to
true.But I´m gonna try to reproduce my plugin toady with legacy cpu support, cause if it won´t run on a Mac Pro, any 64-bit model, it feels a bit limiting.
-
@andioak Xeon X56 supports SSE3 and SSE4.1 so it shouldn't require legacy support. Legacy is really only needed for old AMD chips as far as I know. Let me know if legacy gets it working for you though.
-
@d-healey I know, but we are not using only those, we are using JUCE 5 that require and needs AVX, or at least makes use of this newer instruction set! The docs should be updated here.
Here´s an issue in JUCE forums, talking about instruction sets and how to deal with them.
The JUCE docs don´t seem to include any complete list of what functions/features require or use what instruction sets. But since it´s extensible, perhaps @Christoph-Hart used other libs that require more? Or the instruction set was not documented past JUCE v4.x. Either way, the specs of JUCE are fishy at this point. Check out my forum post on JUCE forums and see what people are saying about this.
AVX was introduced in the Sandy Bridge set, so the Mac Pro 4.1 is the earliest you could run it on. Not sure about the instruction sets introduced in Ivy Bridge (my macbook pro 2012 model for example) if that may even be the requirement for default settings. Seems that you can add flags though for
-AVXetc.It also seems that having the Projucer´s setting "Architecture" set to "native" gives you the enabled instruction set of your build computer. So if it has AVX or even AVX2, your product will not start on any older model. So if you got a v4 xeon, you can forget about selling to even Mac Pro 6.1 "trashcan" customers, because that one has an old Ivy Bridge cpu, Xeon/i7 v2.
Not sure what "legacy cpu" is setting it down to, but it´s probably better setting the flags in the Projucer to specify maximum vector instruction sets.
-
@andioak Are you setting the architecture to native?
-
@d-healey checking that out. But it might be set by HISE upon export, although that would of course perhaps depend on the setting in the Projucer that built my HISE itself, right?
-
@andioak Shouldn't be affected by your HISE build
-
@d-healey I tried my plugin on my build system on Ubuntu instead. Moved the hard drive over. It works and so does the CollaB3. Phew... so it´s not just me who´s misunderstanding 'chmod 755' :) Good to know.
Building my app for older CPU:s but still retaining usage of newer instruction sets, from juce extra flags in the "architecture" setting in the Projucer. The problem is that Projucer does not have a setting for custom Architecture flags, doesn´t have a label to fill in there, so figuring out how that works. So...
@Christoph-Hart Is this the proper way to set the exact cpu-type / generation of computers? :
With this GNU/GCC compiler flags doc you can then use the desired CPU-type as your desired target, setting compiler flags to put into the Projucer (.jucer) -> Exporters -> Linux Makefile is like this:
Will that work for HISE? I am using g++ on linux here.
Update: after some more reading,
-mtune=cpu-typeis the thing to use, as -march docs say:"... the compiler does not generate any code that cannot run on the default machine type unless you use a -march=cpu-type option. For example, if GCC is configured for i686-pc-linux-gnu then -mtune=pentium4 generates code that is tuned for Pentium 4 but still runs on i686 machines."
The unnecessary optimisation is not what I want though, so maybe just specifying all sets I don´t want to use and that wont run on Nehalem (45nm Mac Pro 3.1 at least. ), like so:
-mavx
-mavx2
-mavx512fExcept for the amount of sets available... :/ WIll have to check with JUCE docs for the highest used set.
(I realize that the normal setting in "debug/release" will have to be set to "architecture: none", or will this simply override it?)
-
Did you try compiling with legacy mode enabled?
-
@d-healey I didn´t make that work yet. It gets a failure. But any hour now.
Do you know what system max SSE instructions will be included in the "legacy mode"? SSE2? 3?
-
@andioak Shouldn't use any SSE at all, but I'm sure this is only for AMD CPUs - https://forum.hise.audio/topic/1639/who-uses-amd-cpus
-
@d-healey AAaaahh, now I remember. I was in on this conversation
Yeah Hart removed the entire line of SSE instructions. But building my own yesterday yielded the same unwanted results, nothing. No startup on my xeon X56xx system. Tried on 2 OS:es. But I kept IPP on, which is probably the issue, since it wants SSE 4.1. Building now without it, let´s see.Update: Built it again using "Legacy cpu support" on and IPP off. No dice. Doesn´t start on my older machine, also tried setting correct permissions and
chmod +x, nothing. In terminal it says "Illegal instruction (core dumped)". That means there are non supported instruction sets involved, if I got it correctly.My testing cpu is an Intel Xeon X5667, Westmere EP, that has SSE 4.2, and all others the other xeons have, except for AVX and newer ones. looks like it may be one of those who are still going in there, even after @Christoph-Hart removed the SSE altogether?
Min the .jucer project file the setting for Architecture is "native", which if
HI_ENABLE_LEGACY_CPU_SUPPORTdoesn´t change that setting will export the AVX, because I have it on my i3 ivy bridge cpu in my build machine and it is most likely used by JUCE and g++. I understand that it is supposed to work with that set to enabled, but it is not working.Perhaps you have a "legacy build" of CollaB3 for me to try with along side my own?
-
Finally made it work, but not with
HI_ENABLE_LEGACY_CPU_SUPPORT! That never worked. Instead I changed the .jucer file, under Linux Makefile -> Release -> "Architecture = m64". That reduces the instruction set to SSE and SSE2, according to this thread. No other setting has worked as long as I had "Architecture = native", which is what HISE Scriptnode exports. That´s what is in the .jucer file, no matter the setting.And it makes sens of course, unless you add compiler flags, it is just going to use the native set available on the cpu that is building it. Aka, your computer. If it is new, so is the set. That´s how it seems now.
