[
https://issues.apache.org/jira/browse/ARROW-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432484#comment-16432484
]
Antoine Pitrou 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?
Apparently another solution would be to use something called a "version script"
to control which symbols are exported from the Arrow library, so that the
static libstdc++ doesn't participate in dynamic symbol resolution:
[https://www.technovelty.org/c/what-exactly-does-bsymblic-do.html]
[http://anadoxin.org/blog/control-over-symbol-exports-in-gcc.html]
(I may be speaking cluelessly here)
> 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)
