CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found

[Mark Johnston]

On Mon, Mar 11, 2013 at 02:18:51PM -0700, Steve Kargl wrote:
> On Mon, Mar 11, 2013 at 10:05:47PM +0100, Dimitry Andric wrote:
> > On 2013-03-11 20:00, Jan Beich wrote:
> > > Dimitry Andric <dim at FreeBSD.org> writes:
> > > 
> > >> $ echo 'sub/foo.barx' | grep sub/foo.bar
> > >> $ echo $?
> > >> 1
> > > 
> > > $ echo 'sub/foo.barx' | env -i grep sub/foo.bar
> > > $ echo 'sub/foolbarx' | env -i grep sub/foo.bar
> > > $ echo 'sub/foo.barx' | env -i grep 'sub/foo\.bar'
> > > sub/foo.barx
> > > $ echo 'sub/foo.barx' | env -i grep -o sub/foo.bar
> > > sub/foo.bar
> > > $ echo 'sub/foo.barx' | env -i grep --color=no sub/foo.bar
> > > sub/foo.barx
> > > 
> > > A buggy shortcut?
> > 
> > No, after some digging in and debugging of the bsdgrep code, I
> > found out it is a regression caused by r246917, which is a fix
> > for "bin/175213: [patch] bsdgrep(1) segfaults upon malicious input".
> > If you revert it, bsdgrep starts working correctly again.
> 
> First, I can report that bootstrapping gcc-4.8.0 works if I use
> gnugrep instead of bsdgrep.  The above explains why I had previously
> seen the failure as I was using an older bsdgrep.
> 
> Second, an apology is owed to the clang gang as I attributed the 
> problem to clang as it showed up on my system after converted 
> everything over to clang.  
> 
> > I think it would be best to back out r246917 for now, until the
> > regression can be fixed properly.  Having bsdgrep crash is bad,
> > but not returning any results while it should is even worse...
> 
> I tend to agree with your assessment that r246817 should be
> reverted, because I hit this issue in configure scripts and
> there is a large amount of software that uses autotool for
> configuration.

Sorry about this, I will revert it and revisit the problem. I've been
using bsdgrep by default for a while and somehow haven't run into this.

-Mark