[
https://issues.apache.org/jira/browse/ARROW-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16990210#comment-16990210
]
Neal Richardson commented on ARROW-6793:
----------------------------------------
I've picked this back up this week. Now that manylinux2014 is starting to
happen (ARROW-7344), I've tried to use that as a source for libarrow et al.,
hoping that a less-ancient base image would solve the ABI issues I experienced
with manylinux2010 wheels. Unfortunately, the behavior with manylinux2014 is
the same as with manylinux2010. To recap, in my R build script, I'm first
downloading a wheel, unzipping it, and pointing to it for the lib/include dirs
(cf.
[https://github.com/nealrichardson/sandbox/blob/5ad43525e8d5a9fc25e33fde888408629c421d52/.travis.yml#L11-L20]),
and:
* Building the R package without {{-D_GLIBCXX_USE_CXX11_ABI=0}}, I get an
undefined symbol (e.g.
[https://travis-ci.org/nealrichardson/sandbox/builds/621785506#L1603])
* Adding {{-D_GLIBCXX_USE_CXX11_ABI=0}}, the package installs and works
_except_ for when {{Rcpp::stop}} is called to raise an exception. This causes a
core dump, typically {{bad_alloc}} trying to handle the exception message
(backtrace here:
[https://travis-ci.org/nealrichardson/sandbox/builds/621402417#L1892]).
Symptoms are similar to
[https://stackoverflow.com/questions/56494095/rcppstop-crashes-r-under-g]
I'm struggling to figure out how to proceed. It looks like using the wheels
themselves won't work for R, but maybe using the wheel base image (stripped
down as it is) is a good starting point to build a generic library without
having to create as much parallel infrastructure. But I'm not sure how exactly
to tweak the cmake/flags to make this work–this is not my area of expertise. Or
maybe this is the wrong approach entirely.
Thoughts [~kou] [~kszucs]? (N.B. in reviewing this ticket you can disregard the
previous comment thread, it's unrelated to this problem.)
> [R] Arrow C++ binary packaging for Linux
> ----------------------------------------
>
> Key: ARROW-6793
> URL: https://issues.apache.org/jira/browse/ARROW-6793
> Project: Apache Arrow
> Issue Type: Improvement
> Components: R
> Reporter: Neal Richardson
> Assignee: Neal Richardson
> Priority: Major
> Fix For: 1.0.0
>
>
> Our current installation experience on Linux isn't ideal. Unless you've
> already installed the Arrow C++ library, when you install the R package, you
> get a shell that tells you to install the C++ library. That was a useful
> approach to allow us to get the package on CRAN, which makes it easy for
> macOS and Windows users to install, but it doesn't improve the installation
> experience for Linux users. This is an impediment to adoption of arrow not
> only by users but also by package maintainers who might want to depend on
> arrow.
> macOS and Windows have a better experience because at installation time, the
> configure scripts download and statically link a prebuilt C++ library. CRAN
> bundles the whole thing up and delivers that as a binary R package.
> Python wheels do a similar thing: they're binaries that contain all external
> dependencies. And there are pyarrow wheels for Linux. This suggests that we
> could do something similar for R: build a generic Linux binary of the C++
> library and download it in the R package configure script at install time.
> I experimented with using the Arrow C++ binaries included in the Python
> wheels in R. See discussion at the end of ARROW-5956. This worked on macOS
> (not useful for R, but it proved the concept) and almost worked on Linux, but
> it turned out that the "manylinux2010" standard is too archaic to work with
> contemporary Rcpp.
> Proposal: do a similar workflow to what the manylinux2010 pyarrow build does,
> just with slightly more modern compiler/settings. Publish that C++ binary
> package to bintray. Then download it in the R configure script if a
> local/system package isn't found.
> Once we have a basic version working, test against various distros on
> [R-hub|https://builder.r-hub.io/advanced] to make sure we're solid everywhere
> and/or ensure the current fallback behavior when we encounter a distro that
> this doesn't work for. If necessary, we can make multiple flavors of this C++
> binary for debian, centos, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
