You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by "clamydo (via GitHub)" <gi...@apache.org> on 2023/05/09 04:57:56 UTC

[GitHub] [arrow] clamydo commented on issue #35394: Use statically linked cpp-(py)arrow with cxx11 ABI with vanilla manylinux2014 pyarrow fails (segfault)

clamydo commented on issue #35394:
URL: https://github.com/apache/arrow/issues/35394#issuecomment-1539405701

   That is a very good point, you are raising, thank you! Using the C-API/ABI is probably the right answer.
   
   However, I fail to truly understand how the ABI is of importance in the case. Here, Python is (kind of) in the middle of my my self-compiled arrow world and the vanilla manylinux2014 arrow, isn't it? We exchange a `PyObject`, not an `AOyrrowTable` directly.
   
   I thought the in-memory layout of Arrow-object (I specifically mean an instance of the `ArrowTable` class) is well-defined and stable (and therefore independent of the ABI stability)? Or is this just the case for the core data structure and C++ is allow to shuffle the memory representation of the Arrow- and PyArrow-objects around?
   
   Perhaps the wrong place to discuss this: When thinking about this, I wonder how is it even possible to link to pre-compiled binaries in C++ like for example `Boost`. How can this be ABI compatible when the linking is basically undefined behavior?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org