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, ld
2.20.51.0.2-5.43.el6
Best,
-Brian
On 4/2/20, 1:22 PM, "Wes McKinney" <wesmck...@gmail.com> wrote:
EXTERNAL
On Thu, Apr 2, 2020 at 12:06 PM Antoine Pitrou <solip...@pitrou.net> wrote:
>
>
> Hi,
>
> On Thu, 2 Apr 2020 16:56:06 +0000
> Brian Bowman <brian.bow...@sas.com.INVALID> 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: _ZNK5arrow6Status8ToStringB5cxx11Ev
> >
> > > nm libarrow.so* | grep -i ZNK5arrow6Status8ToStringB5cxx11Ev
> > 00000000002b7760 t _ZNK5arrow6Status8ToStringB5cxx11Ev
> > 00000000002b7760 t _ZNK5arrow6Status8ToStringB5cxx11Ev
>
> For clarity, you should use `nm --demangle`. This will give you the
> actual C++ symbol, i.e. "arrow::Status::ToString[abi:cxx11]() const".
>
> > One of our Linux dev/build experts tracked this down to an issue in
arrow open source. He says the lowercase ‘t’ (text) code (… 7760 t _ZNK …) in
the nm command output is incorrect and it should instead be an uppercase ‘T’.
>
> I have the right output here:
>
> $ nm --demangle --defined-only --dynamic .../libarrow.so | \
> grep Status::ToString
> 00000000012f1ff0 T arrow::Status::ToString[abi:cxx11]() const
>
> Which toolchain (linker etc.) are you using?
My guess is also that you have a mixed-gcc-toolchain problem. What
compiler/linker (and gcc toolchain, if you built with Clang) was used
to produce libparquet.so (or where did you obtain the package), and
which toolchain are you using to build and link your application?
> Regards
>
> Antoine.
>
>
