Have not tried to reproduce in containerized environment Wes.
-Brian
On 4/3/20, 11:42 AM, "Wes McKinney" wrote:
EXTERNAL
Are you able to reproduce the issue in a Dockerfile?
Because you are building with gcc 7.4, you need to ensure either that you
build everything wit
Are you able to reproduce the issue in a Dockerfile?
Because you are building with gcc 7.4, you need to ensure either that you
build everything with the gcc < 5 ABI otherwise (if you want the new gcc
ABI) ensure that the machine where you deploy has libstd++ for gcc 7. Using
Redhat's devtoolset to
Antoine/Wes,
Thanks for your assistance!
Here is the relevant info. We suspect that our production build machines being
at RHEL 6.7 is an issue.
OS: RHEL 6.7
Tools: gcc 7.4, bison-3.2, cmake-3.13.1, automake 1.16.1, autoconf 2.69,
libtool 2.4.6, pkgcnf 1.1.0, texinfo 6.6, help2man 1.47.11,
On Thu, Apr 2, 2020 at 12:06 PM Antoine Pitrou wrote:
>
>
> Hi,
>
> On Thu, 2 Apr 2020 16:56:06 +
> Brian Bowman wrote:
> > A new high-performance file system we are working with returns an error
> > while writing a .parquet file. The following arrow symbol does not
> > resolve properly a
Hi,
On Thu, 2 Apr 2020 16:56:06 +
Brian Bowman wrote:
> A new high-performance file system we are working with returns an error while
> writing a .parquet file. The following arrow symbol does not resolve
> properly and the error is masked.
>
> libparquet.so: undefined symbol: _ZNK
A new high-performance file system we are working with returns an error while
writing a .parquet file. The following arrow symbol does not resolve properly
and the error is masked.
libparquet.so: undefined symbol: _ZNK5arrow6Status8ToStringB5cxx11Ev
> nm libarrow.so* | grep -i ZNK5ar
