Site navigation

JUCE & apps on Linux distros and backwards compatibility / cross-distribution

Linux
#1

Hey there. I´m quite new to JUCE as a framework. I am trying to compile an app that compiles fine on my Linux Mint 17 system, based of Ubuntu 14.04. I am using JUCE 5 (unsure of the version atm).

The app works fine on Mint but as I try to run it on Ubuntu 16.04 (LTE, updated) it refuses to start, the standalone as well as VST2 in linux vst in Ardour and in Reaper. Both black-list the plugin.
JACK installed and is running fine and so is ALSA, thanks to the daw:s.

What in your opinions as JUCE devs is the proper setup for the most backwards compatible and cross-distribution ready release of an instrument?

  • which distro is best to compile on? (do I need several? Like one Arch, one Debian (original) etc)
  • which compiler and version is best to use for maximum backwards compatibility on Linux kernels?
  • I see a lot of clang and clang++ here, but I am using g++, is that my issue?

I make vst-instruments. I have a working instrument made in VST2 and AU + standalone, working perfectly in macOS and now Linux Mint 17. Not sure about a fresh Mint machine (so big question there still un-verified).

#2

I don’t think that the compiler (clang++ vs. g++) matters when it comes to backwards compatibility, please correct me if I’m wrong. I personally tend to chose clang because it’s supported on all three major platforms (macOS, Windows, Linux), find the warning/error output to be the best of all compilers out there and had the feeling that it works slightly faster on weak linux machines.

Are you maybe just facing a missing dependency here? here is a list of all linux dependencies needed to build a JUCE app. While you won’t need the dev packages to execute the plugin, you still might need to have the regular packages present on the target system. Did you check that already?

#3

I suppose using clang or g++ is not the issue, but the backwards compatibility is according to my googling set by the age of the compiler. So using clang old, or g++ old has better backwards compatibility. That´s not my opinion, but answers on other issues/forums.

Are you maybe just facing a missing dependency here?

It could very well be. I´m trying to assertain the issue, building a debug-version hoping that will tell me. But the version of JUCE is version 5.x. The oldest availeble clang/g++ versions supported by my version of JUCE would probably be set by the latest available in the Build OS, a.k.a Linux Mint 17 in my case. Right? Or can I force installation of a certain version?

here is a list of all linux dependencies needed to build a JUCE app. While you won’t need the dev packages to execute the plugin, you still might need to have the regular packages present on the target system.

Thanks for the link, I checked it out and found the developmant requirements were not a problem, but the “deployment targets” are incredibly vague:

  • Linux : Mainstream Linux distributions

Not sure that narrows it down. What is a mainstream distro? And what version?

#4

Hi,

I use openSUSE for my builds, Tumbleweed and Leap 15.2
If you familiar with deb-based distros, then Ubuntu 18 is standard de-facto.

1 Like
#5

I do my builds with ubuntu 16.04 , statically link the libstdc++ (not the libc) and avoid “heavy” dependences in juce (the web browser component)

3 Likes