UDF Problem: unresolvable relocation of 'ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4'

[#1]

CentOS 7.3 (C++ compiler: gcc-c++-4.8.5-11.el7.x86_64))

CDH 5.10.1 installed with Parcels

I am trying to compile the sample UDF , and getting the following error 

Linking CXX executable build/udf-sample-test
/bin/ld: /opt/cloudera/parcels/CDH/lib64/libImpalaUdf-retail.a(udf.cc.o)(.text+0x3): unresolvable R_X86_64_NONE relocation against symbol `_ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4'
/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [build/udf-sample-test] Error 1
make[1]: *** [CMakeFiles/udf-sample-test.dir/all] Error 2
make: *** [all] Error 2

(I don't have libImpalaUdf.a. For my parcel based installation, I have libImpalaUdf-retail.a and libImpalaUdf-debug.a. If I use the debug one , the unresolvable symbol becomes `_ZSt4cerr@@GLIBCXX_3.4' )

In a question against CDH 5.9.0 , it was suggested to use an older UDF SDK for CDH 5.8.4 . This seesm a bit old now. Is there any pre-compiled libImpalaUdf-retail.a for CDH 5.10.1 which fixes this problem?

[#2]

The CDH5.8 version of impala-udf-devel should work with CDH5.9 and CDH5.10, so continuing to use that seems fine. The UDF interface didn't really change in those releases.

The issue was fixed in CDH5.11 so once you get beyond CDH5.10 you can just use the matching versions (as was originally intended). Sorry for the inconvenience.

We did look at backporting the fixes to the 5.9.x and 5.10.x release series to avoid this pain but the fix required a change to our compiler toolchain, which we wouldn't normally do in a maintenance release.

[#3]

We tried CDH5.11 impala-udf-devel RPM and it seemed to work. Is it OK to use with 5.10?
Or it's recommended to revert to 5.8 RPM?

[#4 · Accepted solution]

I believe the 5.11 RPM should work ok.