Lmms: Update rpmalloc

[shlyakpavel]

Hello. I have found some problems related to rpmalloc_thread_collect working improperly. However, it is fixed on both rpmalloc develop and master branches
It would be nice if you merged the up to date version of the code :)
Have a nice day!

[shlyakpavel]

Calf seems to be outdated as well...

[tresf]

Calf seems to be outdated as well...

Calf submodule is master branch only but it's a special LADSPA fork and won't merge directly. The fork is located here: https://github.com/LMMS/veal. Feel free to submit a PR. @JohannesLorenz is the maintainer of that fork.

It would be nice if you merged the up to date version of the code ... [to fix] ... some problems related to rpmalloc_thread_collect working improperly

👍 We'll take a look, thank you!

[JohannesLorenz]

As no one has asked to update rpmalloc, I'll update if from 1.3.0 to 1.3.1 and start in 5 days if there's no veto.

Considering CALF, this can not be tagged as 1.2.0, since CALf is no submodule in 1.2.0. We'll update the LADSPA submodules anyways before releasing 1.3.0 (or discard them with LV2), so it's not useful opening an issue for that now.

[zonkmachine]

OK. I assigned you to the issue and since no one has said anything I just assume you can go ahead and work on it right away.

[JohannesLorenz]

Just to explain why we re-opened that. I made an update, but the CI for 14.04 failed. rpmalloc 1.3.1 uses features which gcc 4.8 (the 14.04 compiler) does not support due to a compiler bug (4.7 and 4.9 are not affected).

I see multiple options:

• :rocket: Discard 14.04 for 1.2 completely (maybe use 16.04 or 18.04), as any support for 14.04 runs out on April 2019.
• :eyes: Somehow patch 14.04 to user gcc 4.9 or higher
• :tada: Refuse to update rpmalloc for 1.2

Voting time!

[tresf]

This is a tough topic to vote on because each decision has its own ramifications. Sorry, I have more questions than answers...

• What are the major ramifications of leaving stable-1.2 on 14.04 and keeping our current version of rpmalloc? We need less changes to the stable-1.2 branch, not more and @lukas-w has already started refactoring the memory management in master.
• I've used gcc 4.9 on 14.04 without any major issues, are there any anticipated problems (e.g. such as with the AppImage?) If not, this seems like a completely reasonable approach, assuming there are major ramifications (depends on bullet 1)
• Again, not updating depends on the severity of not updating rpmalloc.

[tresf]

• Use 16.04 (support for 12.04 runs out in April) - This decision frightens me a bit because of our reliance on the trusty PPAs for the Windows builds but may actually be the best since we still haven't released stable-1.2 and at the current rate will need to support it (even on life support) past April from a critical patch perspective.

[JohannesLorenz]

I'm for :rocket: btw:

• Using an operating system that's not updated anymore makes you totally vulnerable to security issues. Using such a system is a fault, and we should not support faults. I'd even vote for LMMS refusing to build on 14.04 on purpose (after support end). No offense.
• We're going to drop 14.04 anyways. The longer we support it, the longer we forbid new standards, like C++14, which will keep our software quality from increasing.

[tresf]

@JohannesLorenz yes, but switching away from 14.04 too early can also cause other issues (such as this one: https://github.com/probonopd/linuxdeployqt/issues/340). :man_facepalming:

[JohannesLorenz]

I agree to @tresf that the severity of not updating rpmalloc must be specified. @shlyakpavel What exactly are your issues? What do you mean by "problems related to rpmalloc_thread_collect working improperly"?

[dvzrv]

You can install higher versions of gcc on 14.04 though and generally 14.04 reaches EOL in April. I would not put my money on it. At all :)

[jasp00]

If we want to release quickly, I propose to drop this bug from milestone 1.2.0 until these problems related to rpmalloc_thread_collect are explained.

[shlyakpavel]

@jasp00 I don't feel like I will explain them since it was too long ago and I don't remember exactly

[lukas-w]

I agree with moving to 1.3 then since we don't even have a reproducible or confirmed bug. We don't have to do everything in 1.2, there can be a 1.2.1.

[JohannesLorenz]

This will now be handled in PR #5696 .