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

[Steve Kargl]

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.

-- 
Steve