Linux public beta (4408)

[mevla]

It would be interesting to know which functionality requires the addition of xcb-util, which is not there in previous synths and plugins. Probably the new preset browser.

[David Else]

I can understand that my kxstudio 14.04 doesn't work due to gcc ABI/API but this way to almost require people to use a specific distro and a specific version instead of making the plugin less picky is unfortunate

I would hope kxstudio 14.04 would work, check out the kxstudio creator's opinion from earlier this year Still gcc 5? :

No, the older needs to be default.
You can run old binaries on new distros (for the most part), but not the other way around.
I'm really not that interested on reconfiguring the repositories all over again.

I hate this trend of always-changing, always-updating software.

How much faster is the latest GCC? Here is your answer:

GCC 7.0 vs. 6.3 vs. 5.4 vs. 4.9 Compiler Benchmarks On Linux x86_64

I assume that Repro-5 would need it's own testing, but would it really provide lower CPU use compiled with the newer GCC?

[hihu]

@ krans: When you use Debian 9 you definitely have the old library we where talking about the last two pages.

I mean there are always pros and cons for statically linked libraries.

When using open source software it's definitely a pro when you use dynamically linked libraries. But you also have to consider that the guys who make the distribution can choose which software they will include and check the libraries before and do changes if they have to.

But in commercial software it has disadvantages. For me the worst example is the steam client. They suppose to use ubuntu but in other distributions you can only use it with a lot of bug fixes. or you have to symlink the libraries. As it's closed source the maintainer of the distribution cannot actually make changes to the software to make it work. And steam refuses to support 20 different distributions. Thats the reason I installed SteamOS only for the client because there it works without hassle.

However you are right the library on Debian 9.3 is old. But is Debian 9 old? I don't know. But I like the fact that they change less because I have never problems. When using a rolling release you sometimes get into trouble and when you don't want to spend lots of hours fixing stuff then it's sometimes better to use the more stable version (on my server I have CentOS because of this)

[mevla]

Debian 9 (Stretch) was released on June 17th 2017.

Linux Mint 18 LTS (Long Term Support - Sarah), the one I use, was released on June 28th 2016.

[abique]

Here is the thing, if you don't want to update your system then you agree to live in the past with things of the past. And if something from the present is not working on your system why complain at all? It is part of your choice isn't it?

Anyway I'm trying to make a build with statically linked libraries, but that will also have drawbacks, it will increase the memory usage of the plugins, and if some libraries requires distribution specific settings for the font rendering or what ever, then we will get in trouble.

The benefit of dynamic libraries is that you can provide it, and if there is a bug in this shared library you can replace it with a fixed one. Everybody should be happy that a software is using dynamic linking because it gives you control over the software while a statically linked one doesn't.

I can be more precise, lets say that you can build an optimized version of pixman on your system then you could speedup the plugins GUI. Or if you want the default font rendering to work differently you can also provide that with a shared library. So this is the freedom/possiblities that you can get from shared libraries, people should enjoy it, instead of fighting for using old crap, because the distribution is too slow/lazy to be updated.

Last point is instead of thinking "software should all be compatible with my old distribution" why don't you think "my distribution should offer me maximum compatibility"? And then wonder why it is a problem to update a library which is stable since 3 years.

[mevla]

Alex, I for one is not interested in a statically linked, not because everything works fine, but because of the memory footprint. In serious projects/sessions there can be up to 40 original tracks and more (tracks with synths/loops) plus all busses for FXs, so I do not really want to tax the system even if only 5 of those tracks are running a Repro.

However, if there are code updates other than the static compile link, could you please also issue a dynamic version if it's not asking for too much and label each accordingly ?

Many thanks for all the work, tschüß !

[abique]

The code size of the library will increase, but this one is read-only so it will be shared on your system across all instances of the same plugin.

Also things like the font rendering can be configured via files in /etc/ (subpixels hint, or font locations, ... I'm not an expert here), some paths are hardwired in the library, so for instance if I statically build a library with hardwired paths and those paths are incorrect on distribtion X or Y, then will come the troubles.

[Subarumannen]

Here is the thing, if you don't want to update your system then you agree to live in the past with things of the past. And if something from the present is not working on your system why complain at all? It is part of your choice isn't it?

Correct, We are in the hands of the developer. If the developer makes software that requires the very latest of a specific distro to be able to use it, fine. We will then have to potentially change distro and version and so on for one specific plugin that is super picky about the underlaying OS and libs. Or just stop using it. In my case I have been very reluctant to change distro or versions of libs and packages since the box I am using is very stable and used a lot on gigs where stability is the most importandt factor. Again, everything else is running so well so I feel that this change is a bit odd. Many other developers actively tries to use as old libs as possible for backwards compabilty without sacrificing performance and so on.

Anyway I'm trying to make a build with statically linked libraries, but that will also have drawbacks, it will increase the memory usage of the plugins, and if some libraries requires distribution specific settings for the font rendering or what ever, then we will get in trouble.

The benefit of dynamic libraries is that you can provide it, and if there is a bug in this shared library you can replace it with a fixed one. Everybody should be happy that a software is using dynamic linking because it gives you control over the software while a statically linked one doesn't.


I can be more precise, lets say that you can build an optimized version of pixman on your system then you could speedup the plugins GUI. Or if you want the default font rendering to work differently you can also provide that with a shared library. So this is the freedom/possiblities that you can get from shared libraries, people should enjoy it, instead of fighting for using old crap, because the distribution is too slow/lazy to be updated.

After reading the issues people have, Performance doesn't seem to be the biggest problem but shared libs that doesn't interact with what the plugin need to work at all.
I would trade a little performance improvements in the GUI for less picky dependencies any day.

Last point is instead of thinking "software should all be compatible with my old distribution" why don't you think "my distribution should offer me maximum compatibility"? And then wonder why it is a problem to update a library which is stable since 3 years.

There are good and bad ways to make software and I am no developer myself but I think this is a case where things is going in the wrong direction... just based on the latest plugin betas and all the trouble people have just getting it running. Also I don't think the solution is to require very specific versions and distros but should be addressed elsewhere.

/Anders

[hihu]

Sorry don't get me wrong. Dynamically linking is far better. And it's definitely "my problem" when my distribution is too old. I have to take care that my system is up to date and regularly updating software is very important which every user should do.

But I also see the perspective from the user view. The user is also somehow bound to what the maintainers of the distribution do. For the hardcore users it might be an option to compile and fix things all day, but when you take in account that someone only wants to make music he will not want to deal with this kind of things.

That's why many software companies stick to Ubuntu as supported platform and the others aren't supported.

I will try to update the library an check what happens then and write the maintainer there that this one is too old.

[mevla]

Just to ask again, what are the changes in the Repros that calls for xcb-util which is not found in any other u-he plugin ? Just curious.

[mevla]

The code size of the library will increase, but this one is read-only so it will be shared on your system across all instances of the same plugin.

Yes, but then if the principle is adopted for all other plugins updates, eg. new preset browser update perhaps that calls for xcb-util, then the resource impact will be more significant.

[David Else]

Here is the thing, if you don't want to update your system then you agree to live in the past with things of the past. And if something from the present is not working on your system why complain at all? It is part of your choice isn't it?

This depends on your distro. If you want an LTS version that has 5 years of support, should developers not offer programs that work with it throughout it's life? If there is an updated version that people can move onto without problems then they should, but there are a lot of factors to take into consideration.

In the case of RHEL/Centos version 7.4 was only released August 2017, but they choose to keep using gcc 4.8.x to maintain compatibility. All libraries/apps/kernel have upstream bug fixes applied, so you end up with a super stable system. It's not a case of being too lazy to update, I agree the lazy should be punished, but not the seekers of stability

Thanks for listening to all the testers, the spirit of Tux is strong in abique

[mevla]

This depends on your distro. If you want an LTS version that has 5 years of support, should developers not offer programs that work with it throughout it's life?

It does - works fine here ! Linux Mint 18 LTS Sarah.

We could assume that the LTS definition by itself is not enough. It might be that in the end it will narrow, for all practical (testing) purposes, the choice of a distro. Does it actually make sense to try to support 5 distros ? Is there any real benefit in doing so ? Is that too much luxury to be able to fancy any distro and expect everything to work especially closed source software ? Is there any business common sense in doing that ?

Not because the distro I use happens to have everything working, but if u-he, or rather Alex in this case, would say, well, I tested the plugins on the popular Distro X and it works fine, so if you're using anything else it's at your own risks, I think I would consider changing the distro to the popular Distro X. Why would I stick absolutely to a distro ? I can have my user experience in KDE on any distro. The Linux shell commands are the same. A low-latency kernel for a distro is always available. Why should I be stubborn ? And if I do use a specific distro for specific purposes, I don't know, like hacking networked systems, then I can dual boot another distro for specific musical purposes. It's a matter of 60 seconds. All data is shared by both distros since just about nothing is in /home/user/ anyways.

I use Linux Mint 18 and do not use any audio/musical repo. I do not need to. jackd, qjackctl, envy24, and others are all part of the regular distro. If I need Calf, I can install from source, for instance.

Cheers.

[Subarumannen]

With this approach we will soon have to dual/tripple boot between distros to use our different plugins.

If U-he distro only works in distro X version x.x and other closed source software requires distro y version y.y and so on we will have a big mess.

Harrisson mixbus as well as other binary bundles are provided in 32bit and 64bit and in a regular and gcc5 version and that is sufficient to work in most distros out there.

Switching between different distros for running different plugins is not something I could do when playing live but it could work at home but is this really what we aim for ?

I feel we are making this to Repro-1/5 centric question

eg. "You will probably have to change your Linuxdistro to be able to run our software"...

LSB (Linux Standrad Base) https://en.wikipedia.org/wiki/Linux_Standard_Base might help getting on a good track

[mevla]

True. Each company could ask for a specific distro.

In the case of Mixbus32C, it's using quite a few system libs:

Code: Select all

ldd mixbus32c-4.2.15
        linux-vdso.so.1 =>  (0x00007ffd769d8000)
        libardourcp.so => not found
        libwaveview.so.0 => not found
        libptformat.so.0 => not found
        libardour.so.3 => not found
        libmidipp.so.4 => not found
        libevoral.so.0 => not found
        libaudiographer.so.0 => not found
        libcanvas.so.0 => not found
        libwidgets.so.0 => not found
        libgtkmm2ext.so.0 => not found
        libpbd.so.4 => not found
        libtimecode.so => not found
        libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f466a335000)
        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f466a0f9000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f4669e56000)
        libglibmm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 (0x00007f4669be8000)
        libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f4669997000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f466968f000)
        libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x00007f466948a000)
        libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f4669288000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4669080000)
        libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f4668a43000)
        libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007f4668790000)
        libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f4668583000)
        libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f4668361000)
        libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f4668056000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f4667e35000)
        libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f4667ac2000)
        libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f46678ad000)
        libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f4667660000)
        libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f4667457000)
        libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f46671f0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4666fec000)
        libgtkmm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1 (0x00007f46669b2000)
        libatkmm-1.6.so.1 => /usr/lib/x86_64-linux-gnu/libatkmm-1.6.so.1 (0x00007f466676a000)
        libgdkmm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libgdkmm-2.4.so.1 (0x00007f466651f000)
        libgiomm-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1 (0x00007f466619f000)
        libpangomm-1.4.so.1 => /usr/lib/x86_64-linux-gnu/libpangomm-1.4.so.1 (0x00007f4665f75000)
        libcairomm-1.0.so.1 => /usr/lib/x86_64-linux-gnu/libcairomm-1.0.so.1 (0x00007f4665d52000)
        libfftw3f.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007f466594d000)
        libfftw3f_threads.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x00007f4665746000)
        liblo.so.7 => /usr/lib/i386-linux-gnu/liblo.so.7 (0x00007f4665535000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4665317000)
        libtag.so.1 => /usr/lib/x86_64-linux-gnu/libtag.so.1 (0x00007f4665040000)
        libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f4664cd9000)
        libsuil-0.so.0 => not found
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f46649a4000)
        libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f466473c000)
        libarchive.so.13 => /usr/lib/x86_64-linux-gnu/libarchive.so.13 (0x00007f466449b000)
        libaubio.so.2 => not found
        libsamplerate.so.0 => /usr/lib/x86_64-linux-gnu/libsamplerate.so.0 (0x00007f466412f000)
        liblrdf.so.2 => not found
        libvamp-sdk.so.2 => not found
        libvamp-hostsdk.so.3 => /usr/lib/x86_64-linux-gnu/libvamp-hostsdk.so.3 (0x00007f4663eec000)
        librubberband.so.2 => /usr/lib/x86_64-linux-gnu/librubberband.so.2 (0x00007f4663cba000)
        liblilv-0.so.0 => /usr/lib/liblilv-0.so.0 (0x00007f4663a9f000)
        libsratom-0.so.0 => /usr/lib/x86_64-linux-gnu/libsratom-0.so.0 (0x00007f4663896000)
        libsord-0.so.0 => /usr/lib/x86_64-linux-gnu/libsord-0.so.0 (0x00007f466368c000)
        libserd-0.so.0 => /usr/lib/x86_64-linux-gnu/libserd-0.so.0 (0x00007f466347a000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4663176000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4662e70000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4662c5a000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4662895000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f466266b000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4662452000)
        libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f466222c000)
        libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f4662028000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f4661e20000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f4661be2000)
        libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f46619dc000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f46617d2000)
        libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f46615cf000)
        libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f46613bf000)
        libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f46611b5000)
        libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f4660fab000)
        libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f4660da8000)
        libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f4660ba5000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f4660993000)
        libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f46606ea000)
        libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f46604e7000)
        libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f46602de000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f46600bf000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f465fe9c000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f465fc81000)
        libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f465fa2c000)
        libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f465f823000)
        libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f465f5f0000)
        librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0 (0x00007f465f3d6000)
        libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f465f177000)
        libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f465ed9c000)
        libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f465eb55000)
        liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f465e946000)
        libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f465e6f5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f466a566000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f465e4d3000)
        libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f465e004000)
        libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f465ddd7000)
        libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x00007f465dba8000)
        libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f465d9a3000)
        liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x00007f465d782000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f465d572000)
        libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3 (0x00007f465d17a000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f465cf76000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f465cd70000)
        libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f465cb54000)
        libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f465c94d000)
        libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f465c68f000)
        libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f465c40f000)
        libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f465c144000)
        libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f465bf15000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f465bd11000)
        libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f465bb06000)
        libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f465b8eb000)
        libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f465b6ad000)
        libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f465b499000)
        libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f465b257000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f465b052000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f465ae4e000)
        libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f465ac45000)
        libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f465a9bd000)
        libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f465a71c000)
        libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f465a4e9000)
        libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f465a2d4000)
        libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f465a0ab000)
        libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f4659e9d000)
        libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f4659c54000)
        libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f465999b000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4659762000)

I'm afraid LSB does not seem to be the answer. Will LSB say that xcb-util have to be of a certain version ? Linux Mint 18, where Repro 1/5 works very well is not LSB. Debian 9 OTOH seemingly is. And has an older version of xcb-util.

A company is about making money. If Bitwig adopts Ubuntu, and I think they did, it is hard to imagine that another company making closed source commercial Linux software could be clueless enough to choose another distro out of the whim of one of its developers or managers, w/o assessement of that aspect of the business model. Of course, if a company makes it so that it runs everywhere so much the better, but a company cannot test on 5 distros in parallel.

Bitwig uses Ubuntu, I use Linux Mint. So I thought, hmmm, maybe it will not work. But it does, since LM is based on Ubuntu. I was aware that there could have been a risk.

There are not enough commercial Linux companies out there to make dialogue impossible after all. It's a pretty small gang.