AFAICT this issue was introduced in OpenVDB 6.2.0 when it started
linking in jemalloc all the time, including when being built as a shared
library.
My understanding is that shared libraries should absolutely not be doing
this, as safely linking allocators such as jemalloc into a shared
library is very tricky to do correctly, and can also make it impossible
to use the shared library dynamically via `dlopen`.
In my case I ran into this via OpenImageIO which had a dependency on
libopenvdb.so.6.2, and I was getting the error "/usr/lib/x86_64-linux-
gnu/libjemalloc.so.2: cannot allocate memory in static TLS block" when
doing a `dlopen`.
OpenVDB addresses this as of v7.1.0, though this hasn't actually been
released. The changelog [1] reads:
- jemalloc/tbbmalloc are no longer linked into library artifacts of the
OpenVDB CMake build. The CONCURRENT_MALLOC CMake option now only applies
to the executables.
My understanding is that this is fixed in the proposed libopenvdb
package for groovy which uses OpenVDB v7, but getting that working as a
dependency of OpenImageIO on a focal system might be tricky. For my
situation I'm intending to build OpenImageIO from source, link it
statically, and exclude OpenVDB at build time because I don't actually
need it anyway.
Hopefully there's a backport of the fix removing jemalloc to the OpenVDB
6.x series that can become part of an update to focal, or perhaps focal
could use the proposed package for groovy.
[1]
https://github.com/AcademySoftwareFoundation/openvdb/blob/master/CHANGES
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1882998
Title:
openvdb6.2 is non functionnal on Focal due to jemalloc
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jemalloc/+bug/1882998/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
