Skip to content

[C++] libarrow2500 is not usable with pyarrow==25.0.0 #50648

Closed

Description

@adsharma

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:

arrow::internal::tracing::UnwrapSpan(arrow::util::tracing::SpanDetails*)

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.

Repro:

uv venv --python 3.12
uv pip install pyarrow
sudo apt-get install -y libarrow-dev=25.0.0-1 # from the apache arrow ubuntu 24.04 repo

nm -D /usr/lib/x86_64-linux-gnu/libarrow.so.2500.0.0 | grep UnwrapSpan # not present
nm -D .venv/lib/python3.12/site-packages/pyarrow/libarrow.so.2500 | grep UnwrapSpan # present
import mylib  # links to /usr/lib/x86_64-linux-gnu/libarrow.so.2500.0.0 
import pyarrow # fails with undefined UnwrapSpan

This is working ok on windows/macosx. Fails only on linux.

Ladybug-Memory/icebug#56

Component(s)

C++

Activity

  1. changed the title [-]libarrow2500 is not usable with pyarrow==25.0.0[/-] [+][C++] libarrow2500 is not usable with pyarrow==25.0.0[/+] on Jul 26, 2026
  2. kou commented on Jul 26, 2026

    @kou
    Member

    @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?

  3. added a commit that references this issue on Jul 27, 2026
  4. added a commit that references this issue on Jul 27, 2026
  5. raulcd commented on Jul 27, 2026

    @raulcd
    Member

    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

  6. adsharma commented on Jul 27, 2026

    @adsharma
    Author

    icebug/networkit is also a standalone C++ library that has real world users. It needs to link to libarrow.so to be functional.

  7. pitrou commented on Jul 27, 2026

    @pitrou
    Member

    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.

  8. added 2 commits that reference this issue on Jul 30, 2026
  9. added a commit that references this issue on Aug 3, 2026
  10. added this to the 26.0.0 milestone on Aug 3, 2026
  11. raulcd commented on Aug 3, 2026

    @raulcd
    Member

    Issue resolved by pull request 50650
    #50650

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions