[
https://issues.apache.org/jira/browse/ARROW-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432580#comment-16432580
]
Uwe L. Korn commented on ARROW-1171:
------------------------------------
> I'm assuming the issue is that the libstdc++ Arrow was (statically or not)
> linked with also gets used at runtime to resolve symbols in turbodbc (or the
> reverse)? Am I right?
Yes. There are some symbols that are in the C++ STL that are always statically
linked. We provide a version script and don't export our symbols but sadly
other libraries export theirs and this then leads to a crash in Arrow.
Using {{-Bsymbolic}} (and friends!) would be the path that would ensure that
Arrow actually uses the symbols that were packaged with it. Sadly this has some
nasty side effects. When I have some more time, I try to dive into this issue
again and read also the linked articles. Currently this problem here is no a
high priority for me.
> C++: Segmentation faults on Fedora 24 with pyarrow-manylinux1 and
> self-compiled turbodbc
> ----------------------------------------------------------------------------------------
>
> Key: ARROW-1171
> URL: https://issues.apache.org/jira/browse/ARROW-1171
> Project: Apache Arrow
> Issue Type: Bug
> Components: C++
> Affects Versions: 0.4.1
> Reporter: Uwe L. Korn
> Assignee: Uwe L. Korn
> Priority: Major
> Labels: pull-request-available
> Fix For: 0.10.0
>
>
> Original issue: https://github.com/blue-yonder/turbodbc/issues/102
> When using the {{pyarrow}} {{manylinux1}} Wheels to build Turbodbc on Fedora
> 24, the {{turbodbc_arrow}} unittests segfault. The main environment attribute
> here is that the compiler version used for building Turbodbc is newer than
> the one used for Arrow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
