prefix-dev
Missing libglib-2.0.0.dylib, libgobject-2.0.0.dylib, libgio-2.0.0.dylib, and libaravis-0.8.0.dylib When Using GI Repository Modules Outside Pixi on macOS
Checks
-
[x] I have checked that this issue has not already been reported.
-
[x] I have confirmed this bug exists on the latest version of pixi, using
pixi --version.
Reproducible example
First I install gobject-introspection and aravis with brew. I do this because there is no pixi build available for aravis, and gobject-introspection is an aravis dependency.
brew install gobject-introspection
brew install aravis
Then I try to install my other dependencies with pixi install. Here is pixi.toml
[project]
authors = ["Leila <[email protected]>"]
channels = ["conda-forge"]
description = "USB3 version of the laser server"
name = "laser-server-ft-aravis"
platforms = ["osx-arm64", "osx-64"]
version = "0.1.0"
[tasks]
[dependencies]
libjpeg-turbo = ">=3.0.0,<4"
libusb = ">=1.0.27,<2"
libpng = ">=1.6.44,<2"
llvm-openmp = ">=19.1.0,<20"
python = "3.9.*"
pillow = ">=10.4.0,<11"
numpy = ">=2.0.2,<3"
scikit-image = ">=0.24.0,<0.25"
[pypi-dependencies]
pygobject = ">=3.50.0, <4"
Issue description
Hi there 👋
I’m encountering a shared library error when trying to use gi.repository modules (specifically Aravis) from a Python project running inside a Pixi-managed environment on macOS.
I'm not installing Aravis or gobject-introspection via Pixi — Aravis doesn’t have a Pixi build, and gobject-introspection is a dependency of Aravis. Until recently, this setup worked fine. But now I'm seeing the following errors:
GLib-GIRepository-WARNING **: Failed to load shared library 'libgobject-2.0.0.dylib'...
GLib-GIRepository-WARNING **: Failed to load shared library 'libglib-2.0.0.dylib'...
gi._error.GError: gi-invoke-error-quark: Could not locate g_option_error_quark: dlopen(libglib-2.0.0.dylib, 0x0009): tried: ...
It looks like the dynamic libraries aren’t being found by the environment. Some of the attempted paths include:
/System/Volumes/Preboot/Cryptexes/OSlibglib-2.0.0.dylib
.pixi/envs/default/lib/libglib-2.0.0.dylib
/usr/lib/libglib-2.0.0.dylib
This same code used to run fine. I'm on macOS, and haven’t tested this setup on Linux yet.
Temporary Solution
I was able to resolve the issue by manually creating symlinks to the necessary dynamic libraries:
ln -s /opt/homebrew/lib/libglib-2.0.0.dylib .pixi/envs/default/lib/
ln -s /opt/homebrew/lib/libgobject-2.0.0.dylib .pixi/envs/default/lib/
ln -s /opt/homebrew/lib/libgio-2.0.0.dylib .pixi/envs/default/lib/
ln -s /opt/homebrew/lib/libaravis-0.8.0.dylib .pixi/envs/default/lib/
This works, but it feels a bit brittle, and I wanted to check if there's a more idiomatic solution using Pixi's environment configuration.
Thanks again for the amazing work on Pixi — happy to provide more info if needed!
— Leila
Expected behavior
Pixi should automatically detect and use the necessary .dylib files (such as libgobject-2.0.0.dylib, libglib-2.0.0.dylib, libgio-2.0.0.dylib, and libaravis-0.8.0.dylib) when installed via Homebrew. This would allow Pixi to function without requiring manual intervention (e.g., creating symlinks) for the required shared libraries. Pixi should be able to find these libraries in their default Homebrew installation locations or use the appropriate environment paths for them.
Hey!
This workflow is not a recommended way of using pixi as we have a big focus on reproducibility. Depending on brew installed shared libraries makes that really hard.
My guess is that somehow parts of the glib are now pulled in by other dependencies.
I tried your pixi.toml example and with some tweaks I got it working without brew installations:
[project]
authors = ["Leila <[email protected]>"]
channels = ["conda-forge"]
description = "USB3 version of the laser server"
name = "laser-server-ft-aravis"
platforms = ["osx-arm64", "osx-64"]
version = "0.1.0"
[dependencies]
libjpeg-turbo = ">=3.0.0,<4"
libusb = ">=1.0.27,<2"
libpng = ">=1.6.44,<2"
llvm-openmp = ">=19.1.0,<20"
python = "3.9.*"
pillow = ">=10.4.0,<11"
numpy = ">=2.0.2,<3"
scikit-image = ">=0.24.0,<0.25"
cmake = ">=4.0.1,<5"
cairo = "*"
libgirepository = "*"
pycairo = "*"
meson-python = "*"
pkg-config = "*"
zlib = "*"
expat = "*"
gobject-introspection = "*"
glib = ">=2.84.0,<3"
[pypi-dependencies]
pygobject = ">=3.50.0, <4"
I hope that helps.
But seeing that pygobject is also a conda package, you could also skip all the glib issues by using it from the normal dependencies.
To explain the error you are getting, we are only adding the pixi environment to the PATH, so the compilers will first look in the pixi environment. Depending on the package's CMake setup, it will try to figure out where to get the dependencies from. Mixing brew and pixi will almost always result in weird states, as there is no guarantee they work together.
Wow, there are good people in the world, and they're open source software devs :)
The real solution to my problem is for me to get up the guts to do a pixi build of aravis. Thanks for looking at this issue even when it's only happening because I'm operating outside of Pixi's intended use-case.
What do you mean you got it working? I don't understand how you can have pixi.toml work outside of the context of the codebase.
Thank you again for looking at this!!
Linking against Hombrew installed libraries will eventually cause some real nightmare scenario situations. The reason is that the libc++ used by the conda-forge packages is not compatible with the one used by Hombrew. While it loads at runtime, the layout of a lot of STL structures is different resulting in really bizarre crashes that are quite confusing until you look at their assembly and see that they're using mis-matched class definitions.
It would be nice if it were not possible to accidentally link against Homebrew-installed dependencies, but cmake automatically adds Homebrew paths to the compiler on macOS. There is a way to prevent this at CMake configure time with -DCMAKE_IGNORE_PREFIX_PATH="/opt/homebrew;/usr/local/homebrew".
Thanks for the appreciation!
What do you mean you got it working?
The build of pygobject was only working after my modifications to your initial pixi.toml in the original question. My original understanding was that you were limited by not being able to build it through conda-forge only dependencies.
If the answers are doing what we can right now please close the issue 😄
