OCPNsenc runtime error on RPi with Raspbian 9.1

[stygge-ulv]

Hi,

after building OpenCPN and s63_pi from source code on a RPi 3 with Raspbian 9.1 I get a runtime error in the pre-built ARM binary OCPNsenc when trying to create a new signature file in the s63_pi plugin. The plugin calls OCPNsenc to to this. When running OCPNsenc from the command line it yields the following runtime error:

OCPNsenc
OCPNsenc: Symbol _ZN12wxTextBuffer6ms_eofE' has different size in shared object, consider re-linking 15:22:32: Warning: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8). 15:22:32: Warning: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8), and program used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8). *** Error in OCPNsenc': corrupted size vs. prev_size: 0x00826d90 ***
Aborted

I interpret this as an inconsistency among the C++ compilers ABI version used when the binary was compiled by you and the C++ compiler ABI version that were used to build the stdc++ libray of the Raspbian. As far as I can see the only real solution is if you can provide a new OCPNsenc built with a newer C++ version used by Raspbian ? When running ldd -r on the distributed OCPNsenc bnary i find the following:

ldd -r /usr/bin/OCPNsenc
linux-vdso.so.1 (0x7ef57000)
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f9a000)
libwx_baseu-3.0.so.0 => /usr/lib/arm-linux-gnueabihf/libwx_baseu-3.0.so.0 (0x76d3b000)
libwx_baseu_net-3.0.so.0 => /usr/lib/arm-linux-gnueabihf/libwx_baseu_net-3.0.so.0 (0x76ced000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76ba5000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76b26000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76af9000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76ad0000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76991000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x7696a000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76957000)
/lib/ld-linux-armhf.so.3 (0x76faf000)
/usr/bin/OCPNsenc: Symbol `_ZN12wxTextBuffer6ms_eofE' has different size in shared object, consider re-linking

Looking into the stdc++ library I find the following :

strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | egrep 'LIB|ABI'
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.2
CXXABI_1.3.3
CXXABI_1.3.4
CXXABI_1.3.5
CXXABI_1.3.6
CXXABI_1.3.7
CXXABI_1.3.8
CXXABI_1.3.9
CXXABI_1.3.10
CXXABI_TM_1
CXXABI_ARM_1.3.3
GLIBC_2.4
GLIBC_2.18
GLIBC_2.17

and when I do the same for OCPNsenc I get:

strings /usr/bin/OCPNsenc | egrep 'LIB|ABI'
GLIBC_2.4
GLIBCXX_3.4.11
CXXABI_1.3
CXXABI_ARM_1.3.3
GLIBCXX_3.4
3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8)
.note.ABI-tag

My RPi has the following release info:

lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.1 (stretch)
Release: 9.1

Hope you have a solution for this problem.

b.r.
Jan

[leamas]

Now, the binary has been updated and has more sane dependencies -- the wxWidgets deps seems to be trimmed:

ldd OCPNsenc
linux-vdso.so.1 =>  (0x7ef8e000)
libz.so.1 => /lib/libz.so.1 (0x76eb5000)
libdl.so.2 => /lib/libdl.so.2 (0x76ea0000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0x76dc6000)
libm.so.6 => /lib/libm.so.6 (0x76d4a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x76d1b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x76cf4000)
libc.so.6 => /lib/libc.so.6 (0x76ba0000)
/lib/ld-linux-armhf.so.3 (0x76ed9000)

So, I guess this issue could be closed (?).