)]}'
{
  "commit": "bef9ef8ca0f941d743c77cc55b5fe7985990b2a7",
  "tree": "003940f0f2dca29ffca164ba3ea7bad813bdb94d",
  "parents": [
    "bc4b1401129c755eb78d434ae88605478f4299f1"
  ],
  "author": {
    "name": "Nick Alcock",
    "email": "nick.alcock@oracle.com",
    "time": "Mon Sep 27 20:31:21 2021 +0100"
  },
  "committer": {
    "name": "Nick Alcock",
    "email": "nick.alcock@oracle.com",
    "time": "Mon Sep 27 20:31:23 2021 +0100"
  },
  "message": "libtool.m4: fix nm BSD flag detection\n\nLibtool needs to get BSD-format (or MS-format) output out of the system\nnm, so that it can scan generated object files for symbol names for\n-export-symbols-regex support.  Some nms need specific flags to turn on\nBSD-formatted output, so libtool checks for this in its AC_PATH_NM.\nUnfortunately the code to do this has a pair of interlocking flaws:\n\n - it runs the test by doing an nm of /dev/null.  Some platforms\n   reasonably refuse to do an nm on a device file, but before now this\n   has only been worked around by assuming that the error message has a\n   specific textual form emitted by Tru64 nm, and that getting this\n   error means this is Tru64 nm and that nm -B would work to produce\n   BSD-format output, even though the test never actually got anything\n   but an error message out of nm -B.  This is fixable by nm\u0027ing *nm\n   itself* (since we necessarily have a path to it).\n\n - the test is entirely skipped if NM is set in the environment, on the\n   grounds that the user has overridden the test: but the user cannot\n   reasonably be expected to know that libtool wants not only nm but\n   also flags forcing BSD-format output.  Worse yet, one such \"user\" is\n   the top-level Cygnus configure script, which neither tests for\n   nor specifies any BSD-format flags.  So platforms needing BSD-format\n   flags always fail to set them when run in a Cygnus tree, breaking\n   -export-symbols-regex on such platforms.  Libtool also needs to\n   augment $LD on some platforms, but this is done unconditionally,\n   augmenting whatever the user specified: the nm check should do the\n   same.\n\n   One wrinkle: if the user has overridden $NM, a path might have been\n   provided: so we use the user-specified path if there was one, and\n   otherwise do the path search as usual.  (If the nm specified doesn\u0027t\n   work, this might lead to a few extra pointless path searches -- but\n   the test is going to fail anyway, so that\u0027s not a problem.)\n\n(Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a\nsymlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where\n*that* is a symlink to /usr/bin/nm.)\n\nChangeLog\n2021-09-27  Nick Alcock  \u003cnick.alcock@oracle.com\u003e\n\n\tPR libctf/27967\n\t* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided\n\tNM, if there is one.  Run nm on itself, not on /dev/null, to avoid\n\terrors from nms that refuse to work on non-regular files.  Remove\n\tother workarounds for this problem.  Strip out blank lines from the\n\tnm output.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "dd1ba3d66b5a6490dbda80790d4fa72375d493dd",
      "old_mode": 33188,
      "old_path": "ChangeLog",
      "new_id": "afa6629abd13cba29f7dbfd188395227b715ce87",
      "new_mode": 33188,
      "new_path": "ChangeLog"
    },
    {
      "type": "modify",
      "old_id": "7a711249304886a5ef4a0338c1d972cda6bf7377",
      "old_mode": 33188,
      "old_path": "libtool.m4",
      "new_id": "a216bb14e991f45a556401db6417902d17ce552c",
      "new_mode": 33188,
      "new_path": "libtool.m4"
    }
  ]
}