toolchain/44613: Tools pick up gsed from pkgsrc if installed

[jmmv%netbsd.org@localhost]

>Number:         44613
>Category:       toolchain
>Synopsis:       Tools pick up gsed from pkgsrc if installed
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 20 15:20:01 +0000 2011
>Originator:     Julio Merino
>Release:        NetBSD 5.1_STABLE
>Organization:
Julio Merino
>Environment:
        
        
System: NetBSD homeworld.netbsd.org 5.1_STABLE NetBSD 5.1_STABLE (NBMAIL_DOMU) 
#1: Sat Dec 25 13:12:37 UTC 2010 
root%franklin.NetBSD.org@localhost:/home/netbsd/5/amd64/kern-compile/NBMAIL_DOMU
 amd64
Architecture: x86_64
Machine: amd64
>Description:
        After removing the 'gsed' package from my system, I have realized that
        update builds on a previously-compiled release trees fail because they
        cannot find /usr/pkg/bin/gsed any more.

        The problem lies in that the configure scripts of several tools (e.g.
        src/tools/file/) look for a sed binary and stick its path into the
        generated 'libtool' script.  These tests only check for 'sed' and
        'gsed' and there is no sane way of overriding the names of the tools
        nor the paths they are looked for into.
>How-To-Repeat:
        1) Install pkgsrc/textproc/gsed and ensure gsed is in your path
        2) build.sh tools
        3) grep -r gsed obj
>Fix:
        My naive attempt at adding SED=${HOST_SED:Q} to the CONFIGURE_ENV
        variables of Makefile.gnuhost and Makefile.gmakehost failed.  The
        offending configure scripts do not honor the SED variable.

        These configure scripts do honor defining a lt_cv_path_SED variable
        instead, but this is private.  I am not sure if we really want to
        override this variable with a valid path or attempt to do something
        else (hence why I am filing the PR instead of sending a fix).

>Unformatted: