Consider static linking xcb and others

[elcalenx]

Describe the bug

I haven't been able to make Surge run in Ardour on a Debian Buster system without installing libxcb-util1, which is not available in the Debian repositories. (Without this library version installed, Ardour simple blacklists the plugin when scanning.) However, the .deb package's dependency list apparently contains "libxcb-util1 | libxcb-util0", so there's no indication upon installation that there's a dependency problem.

Please let us know your surge version

• Surge Version: 1.6.1.1
• Plugin type (VST2, 3 or AU): VST2
• Bits (32/64): 64

Desktop (please complete the following information):

• OS: Debian Buster
• Host: Ardour 5.12

[baconpaul]

Hmm yeah so I think the person who wrote that meant “you need one of util0 or uyil1 to build” but I guess we perverted that meaning a bit with a binary deb file which probably builds against util 1. I am a touch out of my depth on deb packaging tbh.

Have you built from source against util0 and had it work?

It is super easy to change the deb though which I suppose is the right thing? @tank-trax any thoughts?

[tank-trax]

I use Debian Stretch and can build Surge locally using libxcb-util0 however to be able to install and use the prebuilt binary it is necessary to install libxcb-util1

If not mistaken I also needed libxcb-util1 for Bitwig to run.

Using Debian Stretch, Ardour can recognize and load Surge without issue. I would recommend to try clearing your blacklist and plugin cache in Ardour and rescan VST plugins again.

[baconpaul]

Right; So the deb should remov the |util0 then since it wont run with util0? (Even though the code would build with util0)?

I guess: is the .deb file supposed to indicate the build-time dependencies if you ship source; and runtime if you ship binary? That sounds right to me (and like I said it is a 20 character change) but just want to make sure that’s what’s expected.

[tank-trax]

It goes back to when the deb was initially being built

#452
#492

[baconpaul]

Right

So it looks like the “|” is correct for a source asset but not a binary one. I vote that I make the .deb say just the one we build with (xcbutil1) and then add to the README for linux that you can build against either but we build in our pipeline against 1 so our binary issue says that.

Sounds right yeah?

[tank-trax]

I tried this out, found the source xcb-util_0.4.0.orig.tar.gz at https://packages.ubuntu.com/source/disco/xcb-util

it builds on Debian but installs the file in /usr/local/lib/
whereas the .deb package installs in /usr/lib/x86_64-linux-gnu/

creating a symlink as follows:

sudo ln -s /usr/local/lib/libxcb-util.so.1.0.0 /usr/lib/x86_64-linux-gnu/libxcb-util.so.1

allows for Surge to open with this locally built xcb-util1

[baconpaul]

OK I am going to address this issue by removing the reference to lib-xcbutil-0 from the .deb file which we build in the images. Change to that effect inbound. If there's a different change to be made please reopen the issue once it auto closes on sweep!

[kpanic]

@baconpaul Maybe statically linking xcb-util might do the trick.
I did the symlink too although. Thanks for maintaining Surge! 🙇‍♂️

[baconpaul]

I was chatting with @jpcima and a few others and I think the answer we came to here was: (1) don’t statically link this entire mess of libraries; (2) one day make cmakebuilds work better and (3) have people build on their own system (which is why folks are doing things like putting the build into AUR)

I don’t know if that’s right but wanted to tag JP here also

[tank-trax]

some people are running into this error again

[baconpaul]

Well we haven’t changed anything so that is likely. I don’t know what to do other than suggest those people build the software themselves against the libraries they run

[tank-trax]

is there any way to bundle libxcb-util1 with the install

[baconpaul]

i'm so outside my depth with that question I just don't know

@falkTX any ideas on this one?

[falkTX]

for your official packages I think it makes sense to statically link.
otherwise it will be hard for general distros that do not match 100% the build env to be able to install this..
but it should be optional, we might even put custom stuff just for CI.

is the CI able to cache resources from one build to the next?

[baconpaul]

We can cache resources if we need to yeah but we haven't had to yet.

To statically link we need to build everything needed right? That's why yo worry about caching?

[falkTX]

yeah, we do not want to build a bunch of libs on every single commit or release on CI.
the libs should be static in both shared/static and also versioning/availability.
we create them once, then should be good to go for a long time

[mkruselj]

JUCE probably rids us of this issue as well?

[falkTX]

juce dlopens libX11, so yes

[mkruselj]

OK then let's close this one if @baconpaul agrees!

[baconpaul]

so we should close it, but not so much because the problem is solved, but just because the DAW manufacturers work around the problems you get if you use standard JUCE and we will use standard JUCE now, so nothing to be done! Binary distributions of surge-xt will have problems on some OSes still but we won't fix that any way other than making build instructions continue to get easier!