libgdal.so has undefined symbol

GDAL works fine on Drive Software 9.0, but show error when we upgrade to Drive Software 10.0:

The error

$ gdalinfo
gdalinfo: symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol: _ZN11xercesc_3_211InputSource11setEncodingEPKDs.

I tried to remove and reinstall by “sudo apt install libgdal-dev”, the error still exists.

Dear terry.shi,
This package is not shipped on platform by default. Could you share the steps to reproduce this issue. Also, can you tell what features you are looking from this library.

Here is the steps:
1.Upgrate Xavier system to DRIVE Software 10.0.
input command “gdal-config --version”
########################
$ gdal-config --version
2.2.3
########################
So the GDAL version you provided is 2.2.3.

2.Install gdal-bin.(just a tool for gdal)
Then input command “gdalinfo”.
########################
$ gdalinfo
gdalinfo: symbol lookup error: /usr/lib/libgdal.so.20: undefined symbol: _ZN11xercesc_3_211InputSource11setEncodingEPKDs.
########################
It shows the GDAL lib has error.

However, no error showed on Xavier Drive Software 9.0 and Host PC.

We have two target systems, they act the same as i described above. So is it a bug just in Drive software 10.0 ?

The jsk_rviz_plugin for ROS will use this lib. This plugin can display overlayText in RViz.

Hi Terry,

Having analyzed your issue very thoroughly, please do the following:

Check if you are including ubuntugis ppa via:
$ sudo apt policy | grep gis
If so, please comment them out in /etc/apt/sources.list.d/ubuntugis-ubuntu-ppa-bionic.list.

apt remove gdal-bin libxerces-c3.2

apt autoremove && sudo apt update

rm /usr/lib/libxerces-c*

apt install gdal-bin

Keep on reading if you want to get a deeper insight…

Comparing Ubuntu Xenial Xerus to Bionic Beaver I found out a change in the released libxerces-c-dev packages:
xercesc_3_1::InputSource::setEncoding(unsigned short const*) to
xercesc_3_2::InputSource::setEncoding(char16_t const*)

Now when listing the symbols from the shared object files on the device, we see

$ nm /usr/lib/libxerces-c-3.2.so | grep setEnc
00000000002e2a04 T _ZN11xercesc_3_211InputSource11setEncodingEPKt
000000000023e06c T _ZN11xercesc_3_214DOMLSInputImpl11setEncodingEPKt
000000000023e4dc T _ZN11xercesc_3_215DOMLSOutputImpl11setEncodingEPKt
000000000035b324 W _ZN11xercesc_3_217SchemaElementDecl17setEnclosingScopeEj
0000000000257130 T _ZN11xercesc_3_218Wrapper4DOMLSInput11setEncodingEPKt
000000000025783c T _ZN11xercesc_3_219Wrapper4InputSource11setEncodingEPKt
00000000002afbf4 W _ZN11xercesc_3_220XSElementDeclaration24setEnclosingCTDefinitionEPNS_23XSComplexTypeDefinitionE
00000000002afc6c W _ZN11xercesc_3_222XSAttributeDeclaration24setEnclosingCTDefinitionEPNS_23XSComplexTypeDefinitionE
0000000000364544 T _ZN11xercesc_3_224XMLSchemaDescriptionImpl23setEnclosingElementNameEPNS_5QNameE
000000000029db6c T _ZN11xercesc_3_29XMLReader11setEncodingEPKt

The first function name shows the letter “t” at the very end which indicates an old implementation.
Additionally, following the .deb package provided for arm64, see https://launchpad.net/ubuntu/bionic/arm64/libxerces-c-dev/3.2.0+debian-2, one would expect it to be located under /usr/lib/aarch64-linux-gnu.
As the PATH variable got appended by /usr/lib/aarch64-linux-gnu it will check its location at last and as we also don’t have any use for the old library we can securely remove it with # rm /usr/lib/libxerces-c*.

Hope I could shed some light to you and that you are enabled to continue developing.

Thanks,
Fabian

Hi Fabian,
It works! Thank you so much for help and explanation!

I got an similar issue, our project depends on opencv libraries, and we install it by apt-get install libpython-dev. then we can successfully link binary file. But when we execute it, Terry’s issue shows up, then follow Fabian’s step, some opencv libraries also removed. It seems like a dead lock.How can we solve this “lock”?

I think i made a mistake, after deleting building files that cmake generated, and cmake again then make, it’s all good.Sorry.

Based on FabianWeise’s solution, I found that there will be mutiple libxerces-c3.2.so/libxerces-c.so (libxerces* for short to indicate these two libraries) co-existing in the system. There are three situations:

  1. on your host:
    Usually, the libxerces* can be found in /usr/lib. When you use command nm libxerces*, you will see what exact Fabian shows. This one is in x86_64 arch so there should be no problem to run it on host.
  2. cross compilation on your host:
    You may find multiple libxerces* in your cross compilation Vibrante_PDK folder. The one you find in drive-t186ref-linux/lib-target should be the x86_64 arch as well. The one you find in drive-t186ref-linux/targetfs_a(or b)/usr/lib/aarch64-linux-gnu should be in the arm64 arch if you installed it inside the PDK using apt install or by default (I can’t remember if I installed it manually or not). Use the same check method “nm libxerces*”, if it is x86_64 arch then it lists lots of lines and if it is arm64 arch then you receives no symbol warning. You should always use the arm64 arch libxerces*, so you need to rename the x86_64 arch libxerces* to something else (such as libxerces-c.3.2.so.x86arch). Then it will be fine to proceed.
  3. running the cross compiled binary on your Xavier:
    It is similiar that you can find libxerces* at /usr/lib and /usr/lib/aarch64-linux-gnu. You just need to rename the one in /usr/lib to something else.

Hope this will help