Undefined symbol in einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON
13 Sep 2016 10:56:01 UTC
Topic 201078
(moderation:
I must be doing something blindingly stupid because I do not understand why this problem has not been reported before. My tasks all end with a "Computation Error" fairly immediately, and stderr.txt looks like...
<core_client_version>7.7.0</core_client_version> <![CDATA[ <message> process exited with code 127 (0x7f, -129) </message> <stderr_txt> [10:55:16][443][INFO ] Application startup - thank you for supporting Einstein@Home! [10:55:16][443][INFO ] Starting data processing... ../../projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON: relocation error: ../../projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON: symbol __default_sa_restorer_v2, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
</stderr_txt>
]]>
The symbol __default_sa_restorer_v2 was removed from glibc way back in June 2014 so versions of glibc since then - 2.20 onwards (we are currently on 2.24); don't have it. It has been replaced with __default_sa_restorer i.e. the _v2 suffix has been dropped.
The only place in the entire source code for my system where the text __default_sa_restorer_v2 appears is in the ChangeLog file for glibc, so this call MUST be coming from the NEON binary.
How are other people working around this problem ?
LD_DEBUG gives this output ...
# LD_DEBUG=files /var/lib/boinc/projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NE
ON
457:
457: file=libpthread.so.0 [0]; needed by /var/lib/boinc/projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON [0]
457: file=libpthread.so.0 [0]; generating link map
457: dynamic: 0x76f20ef0 base: 0x76f04000 size: 0x0001f24c
457: entry: 0x76f088c8 phdr: 0x76f04034 phnum: 7
457:
457:
457: file=libm.so.6 [0]; needed by /var/lib/boinc/projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON [0]
457: file=libm.so.6 [0]; generating link map
457: dynamic: 0x76f02f00 base: 0x76e91000 size: 0x00072090
457: entry: 0x76e94c00 phdr: 0x76e91034 phnum: 6
457:
457:
457: file=libstdc++.so.6 [0]; needed by /var/lib/boinc/projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON [0]
457: file=libstdc++.so.6 [0]; generating link map
457: dynamic: 0x76e88ef0 base: 0x76dc3000 size: 0x000cdee0
457: entry: 0x76e08d10 phdr: 0x76dc3034 phnum: 7
457:
457:
457: file=libc.so.6 [0]; needed by /var/lib/boinc/projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON [0]
457: file=libc.so.6 [0]; generating link map
457: dynamic: 0x76dbef28 base: 0x76c8f000 size: 0x00133568
457: entry: 0x76ca5ef8 phdr: 0x76c8f034 phnum: 10
457:
457:
457: file=libgcc_s.so.1 [0]; needed by /usr/lib/libstdc++.so.6 [0]
457: file=libgcc_s.so.1 [0]; generating link map
457: dynamic: 0x76c8e26c base: 0x76c6a000 size: 0x00024494
457: entry: 0x76c76d58 phdr: 0x76c6a034 phnum: 5
457:
457:
457: calling init: /lib/libpthread.so.0
457:
457:
457: calling init: /lib/libc.so.6
457:
457:
457: calling init: /lib/libgcc_s.so.1
457:
457:
457: calling init: /lib/libm.so.6
457:
457:
457: calling init: /usr/lib/libstdc++.so.6
457:
457:
457: initialize program: /var/lib/boinc/projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON
457:
457:
457: transferring control: /var/lib/boinc/projects/einstein.phys.uwm.edu/einsteinbinary_BRP4_1.42_arm-unknown-linux-gnueabihf__NEON
457:
[11:27:23][457][INFO ] Application startup - thank you for supporting Einstein@Home!
#
and then the program terminates.
What is the recommended solution ? Thanks.
What operating system do you
)
What operating system do you have installed on the Pi?
Linux 4.1.12It is my own
)
uname -a gives
Linux rfm69cw 4.1.21-v7 #13 SMP Tue Sep 13 14:26:09 BST 2016 armv7l GNU/Linux
It is my own system build from scratch.
I have made a workaround by writing a __default_sa_restorer_v2 routine which simply calls __default_sa_restorer and stuffed that in glibc. It works, but this problem is surely going to trip other people up.
The BRP app for ARM with NEON
)
The BRP app for ARM with NEON (aka Raspberry Pi) is targeting Debian Wheezy and Jessie, both have a libc <2.20 so it makes sense that this is not a widespread problem.
OK. Thanks. That clears up
)
OK. Thanks. That clears up why it has not been reported before.