Re: the help about the symbols list by using nm

[Nick Clifton <nickc at redhat dot com>]

Hi Zhangwen,

  Thanks for the test case.  (The attachment did make it through the first time).

  I have now found the cause of the difference in behaviour.  The 2.22 binutils
  version of nm is using the default program "C" locale, whereas the 2.24 binutils 
  version is using the locale settings from your environment.  The en_US.UTF-8 setting
  that you have for LC_COLLATE ignores a leading period ('.') character so that the
  .LC0 symbol is treated by binutils 2.24 as if it started with an 'L' character and
  by the binutils 2.22 as if it started with a '.' character.

  The reason for the change in behaviour is that there was a bug in the 2.22 sources.
  The configure script did not check for the presence of the setlocale function in the
  system libraries, and instead always marked it function as being unavailable.  The 
  main function of nm looks like this (for both 2.22 and 2.24):

int
main (int argc, char **argv)
{
  int c;
  int retval;

#if defined (HAVE_SETLOCALE) && defined (HAVE_LC_MESSAGES)
  setlocale (LC_MESSAGES, "");
#endif
#if defined (HAVE_SETLOCALE)
  setlocale (LC_CTYPE, "");
  setlocale (LC_COLLATE, "");
#endif
  [...]

  But the bug in the configure script meant that setlocale (LC_COLLATE, "") was never
  called.  In 2012 however I checked in a patch that fixed this bug:

    2012-04-05  Nick Clifton  <nickc@redhat.com>

	* configure.in (AC_CHECK_FUNCS): Add setlocale.
	(AM_LC_MESSAGES): Add.
	* aclocal.m4: Regenerate.
	* config.in: Regenerate.
	* configure: Regenerate.

  So now nm's main knows that setlocale exists, and so it uses it to set the LC_COLLATE
  locale.  That is why the behaviour changed.

  I hope that this explanation helps.

Cheers
  Nick Clifton