Skip to content
Snippets Groups Projects
  • Nick Alcock's avatar
    caf606c9
    libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case · caf606c9
    Nick Alcock authored
    My previous nm patch handled all cases but one -- if the user set NM in
    the environment to a path which contained an option, libtool's nm
    detection tries to run nm against a copy of nm with the options in it:
    e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
    test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
    This is unlikely to be desirable: in this case we should run
    "/usr/bin/nm --blargle /usr/bin/nm".
    
    Furthermore, as part of this nm has to detect when the passed-in $NM
    contains a path, and in that case avoid doing a path search itself.
    This too was thrown off if an option contained something that looked
    like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
    "nm -B../prev-gcc nm" which rarely works well (and indeed it looks
    to see whether that nm exists, finds it doesn't, and wrongly concludes
    that nm -p or whatever does not work).
    
    Fix all of these by clipping all options (defined as everything
    including and after the first " -") before deciding whether nm
    contains a path (but not using the clipped value for anything else),
    and then removing all options from the path-modified nm before
    looking to see whether that nm existed.
    
    NM=my-nm now does a path search and runs e.g.
      /usr/bin/my-nm -B /usr/bin/my-nm
    
    NM=/usr/bin/my-nm now avoids a path search and runs e.g.
      /usr/bin/my-nm -B /usr/bin/my-nm
    
    NM="my-nm -p../wombat" now does a path search and runs e.g.
      /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm
    
    NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
      ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm
    
    This seems to be all combinations, including those used by GCC bootstrap
    (which, before this commit, fails to bootstrap when configured
    --with-build-config=bootstrap-lto, because the lto plugin is now using
    --export-symbols-regex, which requires libtool to find a working nm,
    while also using -B../prev-gcc to point at the lto plugin associated
    with the GCC just built.)
    
    Regenerate all affected configure scripts.
    
    	* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
    	options, including options containing paths.
    caf606c9
    History
    libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
    Nick Alcock authored
    My previous nm patch handled all cases but one -- if the user set NM in
    the environment to a path which contained an option, libtool's nm
    detection tries to run nm against a copy of nm with the options in it:
    e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
    test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
    This is unlikely to be desirable: in this case we should run
    "/usr/bin/nm --blargle /usr/bin/nm".
    
    Furthermore, as part of this nm has to detect when the passed-in $NM
    contains a path, and in that case avoid doing a path search itself.
    This too was thrown off if an option contained something that looked
    like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
    "nm -B../prev-gcc nm" which rarely works well (and indeed it looks
    to see whether that nm exists, finds it doesn't, and wrongly concludes
    that nm -p or whatever does not work).
    
    Fix all of these by clipping all options (defined as everything
    including and after the first " -") before deciding whether nm
    contains a path (but not using the clipped value for anything else),
    and then removing all options from the path-modified nm before
    looking to see whether that nm existed.
    
    NM=my-nm now does a path search and runs e.g.
      /usr/bin/my-nm -B /usr/bin/my-nm
    
    NM=/usr/bin/my-nm now avoids a path search and runs e.g.
      /usr/bin/my-nm -B /usr/bin/my-nm
    
    NM="my-nm -p../wombat" now does a path search and runs e.g.
      /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm
    
    NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
      ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm
    
    This seems to be all combinations, including those used by GCC bootstrap
    (which, before this commit, fails to bootstrap when configured
    --with-build-config=bootstrap-lto, because the lto plugin is now using
    --export-symbols-regex, which requires libtool to find a working nm,
    while also using -B../prev-gcc to point at the lto plugin associated
    with the GCC just built.)
    
    Regenerate all affected configure scripts.
    
    	* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
    	options, including options containing paths.