In message <[EMAIL PROTECTED]>, Peter Naulls writes: >Is there any identifier I can look for to check for any other broken >binaries on my system, with the misbehaving binutils?
If "objdump -R" reveals that the only reloc involving __gmon_start__ is an R_ARM_GLOB_DAT, you are OK. If there is an R_ARM_JUMP_SLOT reloc, you need to use "objdump --dynamic-syms"; if there is a weak definition, like this, you are OK: 02056438 w DF .text 00000000 Base __gmon_start__ but if there is a weak undefined reference, you may be in trouble: 020019d0 w DF *UND* 00000000 __gmon_start__ Not all binaries with this problem will crash today. The bug actually occurs if a binary was compiled under glibc 2.2 and uses shared libraries that were compiled under glibc 2.1 - when those libraries are themselves recompiled against glibc 2.2, the binary will start to crash. p.
