0

I am migrating a Xilinx Zynq board from from the CodeSourcery armel (gnueabi) toolchain (from Vivado 2015.2) to a Linaro armhf, so we could instal Debian/Ubuntu armhf (gnueabihf).

While attempting to dlopen() and dlsym() a shared library, we get the next error from dlerror():

/.../controller.so: undefined symbol: _ZTVN10__cxxabiv119__pointer_type_infoE

The issue is present if the Linaro toolchain is used while software compiled with the CodeSourcery toolchain works properly.

I checked both libraries for the reported symbol and it is present in both:

$ grep -r cxxabiv119__pointer_type_info .
./controller.so.armel.simbols:U _ZTVN10__cxxabiv119__pointer_type_infoE
./controller.so.armhf.simbols:U _ZTVN10__cxxabiv119__pointer_type_infoE

It seems that if controller.so contains only C code (no C++ code) it works properry with Linaro. But the difference might be something else than the language used.

Regards, Iztok Jeras

Iztok Jeras
  • 81
  • 7
  • This is the detail on how the library was opened: app->handle = dlopen(app_file, RTLD_LAZY); – Iztok Jeras Jul 13 '15 at 13:47
  • Don't use grep; use `objdump` to list the symbols. You may find that the broken library uses the symbol but doesn't define it. – ams Jul 14 '15 at 21:34

1 Answers1

0

There was no simple answer to this problem, in the end I switched from cross compiling to a native compiler inside a QEMU emulated ARM environment. This was suggested by various Raspberry PI users. On the other hand every cross compiler solution just unearthed a new set of problems.

Iztok Jeras
  • 81
  • 7