Page MenuHome

Build with -fvisibility=hidden on Linux and macOS
Confirmed, NormalPublicTO DO


On Windows we already hide symbol visibility, but for Linux and macOS this is only done selectively.

There are a number of open reports that may be solved by doing this:

And there have been various other in the past.

It seems better to try compiling Blender and all external liibraries with hidden symbols instead of trying to play whack-a-mole with these symbols. This does require rebuilding all precompiled libraries.

Event Timeline

Brecht Van Lommel (brecht) changed the task status from Needs Triage to Confirmed.Tue, May 5, 12:22 PM
Brecht Van Lommel (brecht) created this task.
Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "To Do".

What might also help here is to use RLTD_DEEPBIND when loading libraries, so that those libraries use their own symbols over global symbols from Blender.

This could be done in clew and Python (with sys.setdlopenflags).

Will this break ctypes usage in Python scripts?

RLTD_DEEPBIND seems fine to just go ahead and do it. Just make sure this is done in upstream, covering the generator templates. Think you have commit access to all wranglers we use.

What is also not clear to me is whether anything special is to be done with Python modules ( for example). Are they not pulling symbols to global scope already? Is it controlled with sys.setdlopenflags? Or do we need to compile all dependencies with hidden visibility?

If ctypes is being used to access Blender symbols, that will indeed break. However that already would not have worked on Windows, so I guess none of the commonly used add-ons/plugins rely on it?

RTLD_DEEPBIND didn't seem to help in T68052. But probably it's the right thing to do regardless.

From my understanding RTLD_DEEPBIND is about preferring local symbols over globals ones when binding symbols. So for example if a Luxrender add-on Python module uses OpenImageDenoise, it would use its own version rather than Blender's.

sys.setdlopenflags sets the default flags used when loading Python modules. I don't think this matters much for bundled Python modules like ssl, it's for add-ons that ship binary Python modules.


The reason our tweaks might not have helped is because the driver might be doing library load, and then you have collision of symbols in the whatever ICD is loading.

In Python I remember having all symbols which are not Py*, _Py*, _py* be hidden. The reason of this was conflict with some of the addon which was loading another .so. Apparently, this mapping file got lost when we've switched to make deps for the release environment. So we either need to restore this mapping file, or use hidden visibility for Python as well. Do you have strong opinion on this topic?