You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[C++] libarrow2500 is not usable with pyarrow==25.0.0 #50648
Describe the bug, including details regarding any error messages, version, and platform.
A C++ open source library (icebug) provides python bindings. It needs to link to both C++ libarrow2500 and pyarrow. This was possible in the 23.x and 24.x releases and failing with 25.x as follows:
is used by .venv/lib/python3.12/site-packages/pyarrow/libarrow_acero.so.2500, so we get a failure at "import pyarrow" time. Looking for suggestions on how to resolve.
@raulcd Can we ensure using libarrow*.so bundled in PyArrow from PyArrow even when there are libarrow*.so in system or system libarrow*.so in system are already loaded?
Mangling or other techniques would still load two full copies of Arrow in the process, so two memory pool registries, two compute function registries, etcetera.
I think the only sensible solution for a use case like that is that a C++ library shipping Python bindings that interop with pyarrow has to load the same Arrow the wheels ships, via pyarrow.get_include() / get_library_dirs() / create_library_symlinks.
I don't know the exact use case but this working previously seems to have been just a coincidence rather than something supported.
Can't you avoid linking system libarrow.so (or not adding it into the wheel) and on import to load the libarrow.so provided?
cc @pitrou
Activity
[-]libarrow2500 is not usable with pyarrow==25.0.0[/-][+][C++] libarrow2500 is not usable with pyarrow==25.0.0[/+]libarrow: workaround for linux
libarrow: workaround for linux
libarrow: workaround for linux
kou commentedon Jul 26, 2026
@raulcd Can we ensure using
libarrow*.sobundled in PyArrow from PyArrow even when there arelibarrow*.soin system or systemlibarrow*.soin system are already loaded?libarrow: workaround for linux
libarrow: workaround for linux
apacheGH-50648: [Packaging][Linux] Enable OpenTelemetry
fix: resolve CI failures in build_wheels workflow
fix: resolve CI failures in build_wheels workflow
fix: resolve CI failures in build_wheels workflow
apacheGH-50648: [Packaging][Linux] Enable OpenTelemetry
raulcd commentedon Jul 27, 2026
Mangling or other techniques would still load two full copies of Arrow in the process, so two memory pool registries, two compute function registries, etcetera.
I think the only sensible solution for a use case like that is that a C++ library shipping Python bindings that interop with pyarrow has to load the same Arrow the wheels ships, via pyarrow.get_include() / get_library_dirs() / create_library_symlinks.
I don't know the exact use case but this working previously seems to have been just a coincidence rather than something supported.
Can't you avoid linking system libarrow.so (or not adding it into the wheel) and on import to load the libarrow.so provided?
cc @pitrou
adsharma commentedon Jul 27, 2026
icebug/networkit is also a standalone C++ library that has real world users. It needs to link to libarrow.so to be functional.
pitrou commentedon Jul 27, 2026
Hmm, perhaps our official Debian / Ubuntu packages should have OpenTelemetry enabled? Other than that, I do not see any simple way to fix this issue.
apacheGH-50648: [Packaging][Linux] Enable OpenTelemetry
apacheGH-50648: [Packaging][Linux] Enable OpenTelemetry
GH-50648: [Packaging][Linux] Enable OpenTelemetry (#50650)
raulcd commentedon Aug 3, 2026
Issue resolved by pull request 50650
#50650