We're using Houdini 19 successfully on Fedora 35. While it does not work out of the box, the workaround described above using LD_PRELOAD works. To my knowledge disabling jemalloc slows down Houdini, while the LD_PRELOAD workaround does not, therefore it's probably the better solution, although a little cumbersome.

so it isn;t easy to choose a LINUX distro coming from mac os. which one do you advice?

This is going to be a religious war that we probably should branch to a different thread instead.

My favorite currently has been Pop!_OS [pop.system76.com] (but make sure to get the 20.04 LTS version! not the newer one). If you want something with more macOS-like skin but still free, then I recommend Elementary OS [elementary.io] but I haven't used it much. I've also heard good things about Zorin OS [zorin.com] too but I've never tried it, and they charge for the Windows/macOS skins as well. I'm heavily biased towards Debian-based distributions as you can tell here.

A final note is to try things out first on a USB key loaded with the distro iso. Play with the UI and see what you like.

thanks for your advice, I downloaded Pop_os and Rocky_Os. I really liked the latest Fedora, but I want a system that is fully compatible with Houdini and Nuke

Most VFX tools, like Nuke, Houdini, Maya, Pixar USD, etc. are officially compatible with CentOS 7 and 8. CentOS overall is closely tied to Red Hat Enterprise Linux (RHEL), so you'll likely get the best compatibility out of a distro that is related to RHEL. In addition, most VFX tools are trying to build against the VFX reference platform [vfxplatform.com], which specifies a set of tools and library versions.

CentOS would be your best option for a Linux distro for Houdini and other VFX tools, as it is often the officially supported one. Now, CentOS 7/8 has been discontinued last year, it is replaced with a rolling release called CentOS Stream, which is more upstream in the release cycle than CentOS 7/8 has been, and might therefore not have the same compatibility with the VFX tools you use.

That's why we are currently going with Fedora. It's the cutting edge release of an "RHEL related" Linux distro with the latest features and kernel, that will in some adjusted form, after testing and changing, become RHEL. While Fedora is great and has the latest features, it'll inevitably produce compatibility issues like the one covered in this thread, as it uses later versions of libraries and tools, than what has been tested by SideFX and other vendors.
CentOS Stream is a safer bet, but since it's a rolling release,it has similar issues with compatibility, like Fedora, but is lacking the latest Linux features and kernel. It's the closest you get to RHEL though without paying.
Or you can flat out pay for RHEL, if you really need production ready and professional support for the OS.

We have also tried other distros, but be aware that this will likely become a rocky road, as you are trying to get various VFX tools that come op in you pipeline working or compiling. While PopOS, Debian, Mint, and many more are great and appealing Linux distros, I'd recommend sticking with a RHEL related distro, based on our experience.

Thanks for this clear explanation. So I could download Fedora 34. And upgrade to 35 when the software is ready for it? I’m now playing with Linux on a spare system before I decide what district I’m going to use.

If you don't care too much about the latest Linux features and kernel (device support), you can go with CentOS Stream 8, which is likely to be have good compatibility. You can then later upgrade to CentOS Stream 9 (which is also already available).

If you care about a more modern release, you can go with Fedora. As mentioned, we are using Fedora 35, which also works fine with all of our VFX tools, with the caveat that Houdini requires a custom start up file to deal with the jemalloc issue, which is an acceptable solution though.

One important thing to consider with Fedora: It aims at being the latest and greatest, therefore you'll not get long term support if you want to stick with a version for a longer period of time. Fedora is doing two releases a year, and with each release drops support for an older release. E.g. when Fedora 36 comes out this year, Fedora Linux 34 will enter End-of-Life, meaning it will no longer receive updates. This is planned for May 17, 2022, therefore it probably doesn't make much sense to rely on Fedora 34 at this point. Fedora is built in a way that you'll have to regularly upgrade to a newer version, not all VFX tools can keep track to that.

That's the main advantage of CentOS stream over Fedora: it's supported and updated much longer. End-of-Life for CentOS Stream is May 31st, 2024, so you can run it for a long time.

Aietes
You can then later upgrade to CentOS Stream 9 (which is also already available).

For the record, CentOS Stream 9 is on glibc 2.34 and will share Fedora 35's problems with running Houdini.

Hello, I tried running latest houdini 19.0.561 in pop!os but got this segfault

I already try export LD_PRELOAD, reinstall xinerama, even install lsb-core. I have another 18.5.672 and it's working fine.

aditiavfx
Hello, I tried running latest houdini 19.0.561 in pop!os but got this segfault

I already try export LD_PRELOAD, reinstall xinerama, even install lsb-core. I have another 18.5.672 and it's working fine.

Crash report from aditia; Unknown App Version 19.0.561 [linux-x86_64-gcc9.3]
Uptime 0 seconds
Sun Apr 10 00:31:02 2022
Caught signal 11

Traceback from 267789 ThreadId=0x7f00e3155e00
AP_Interface::coreDumpChaser(UTsignalHandlerArg) <libHoudiniUI.so>
AP_Interface::si_CrashHandler::chaser(UTsignalHandlerArg) <libHoudiniUI.so>
signalCallback(UTsignalHandlerArg) <libHoudiniUT.so>
UT_Signal::UT_ComboSignalHandler::operator()(int, siginfo_t*, void*) const <libHoudiniUT.so>
UT_Signal::processSignal(int, siginfo_t*, void*) <libHoudiniUT.so>
__sigaction <libc.so.6>
pthread_mutex_lock <libc.so.6>
je_arena_dalloc_large (mutex.h:77)
_nv014glcore <libnvidia-glcore.so.470.86>
_nv014glcore <libnvidia-glcore.so.470.86>
[0x4be18] <libGLX_nvidia.so.0>
vk_icdNegotiateLoaderICDInterfaceVersion <libGLX_nvidia.so.0>

Just quick update, this version of houdini which didn't work is the installation from the launcher. I tried remove it and install using the old installer (not via launcher) and now houdini 19.0 run well. So, probably the issue is with launcher installer.

Thank you.

Good news!

changelog
Houdini 19.0.591

Fixed crash on Linux distro's using glibc version 2.34 or later (eg. Ubuntu/Pop_OS 21.10, Fedora 35, CentOS Stream 9, etc) resulting from libcurl using both jemalloc and libc malloc.

Give it a try and report back please! Remember to unset all those hacky variable workarounds you had first.

Hi, I just tried the latest daily build, and it still has the same crashing issue for Manjaro 21.2.6 (KDE full)

For me on Fedora35 it runs after some tries with the hack like before, without the hack it does not start.

19.0.594 daily build has another fix

changelog
Second attempt at fixing crash on Linux distro's using glibc 2.34 or later.

edward
19.0.594 daily build has another fix

changelog
Second attempt at fixing crash on Linux distro's using glibc 2.34 or later.

Is this fix working? I just switched to a distro that is using 2.31 from Fedora 35 so I can't test it. If it works then I'm coming back to Fedora, ha.

19.0.594 works for me on pop!OS 21.10 even without the LD_PRELOAD hack,
no more random crashes at startup too,
so I guess it's fixed, thank you SideFX !!

It is working for me too on Fedora 35, yay!

19.0.956 Works on Manjaro 21.2.6 Thanks again SideFX

Upgraded Ubuntu from 20.04 to 22.04 and Houdini 19.0.589 no longer works.

I tried all the fixes in this thread and non work.

Downgraded back to Ubuntu 20.04 and everything works ok.

I have no idea why Houdini fails in 22.04. Sorry I do not have the time to trouble shoot.

alunablue
Upgraded Ubuntu from 20.04 to 22.04 and Houdini 19.0.589 no longer works.

I tried all the fixes in this thread and non work.

Downgraded back to Ubuntu 20.04 and everything works ok.

I have no idea why Houdini fails in 22.04. Sorry I do not have the time to trouble shoot.

But the fix was in the nightly builds beyond 589 - no?