Re: --with-babeltrace generates many FAILs

[Yao Qi <yao@codesourcery.com>]

On 08/20/2014 05:41 PM, Pedro Alves wrote:
> As there's been fixed babeltrace versions for a while, I'd go with
> simply dropping the workaround, and have integrators build newer
> GDB with newer babeltrace.  I suppose we have a testcase in our
> testsuite that fails if we remove the workaround and GDB is built with
> broken babeltrace?  That should let the integrator know that it's
> building again a broken lib.

Yes, we have such test case, such as actions.exp, at least.  Without
the workaround, GDB with libbabeltrace 1.1.0 will fail in actions.exp.
However, is it a good idea that let test failure signal a wrong version
lib is used?  I am not sure.  It is the configure's job to check whether
the library is wrong or broken.

> 
> IOW, why do we still need to support 1.1.0?

No special reason, 1.1.0 was just used when I did the CTF work in GDB,
and was used on my laptop since then.  IIRC, 1.1.0 was released in 2013
March, so it isn't very old and it might be used somewhere.  Shouldn't
we be conservative in this case?

In general, GDB and GDBserver uses a set of libraries, what are the
criteria of

 1. stop supporting a version of a library, such as libbabeltrace 1.1.0
 2. stop supporting or using a library, such as the UST stuff in GDBserver,

-- 
Yao (齐尧)