--with-babeltrace generates many FAILs

[Pedro Alves]

On 08/20/2014 12:34 PM, Yao Qi wrote:
> 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?  

IMO, in this case, it's sufficient.  There are point releases that fix
the issue, which are supposedly compatible with 1.1.0 -- updating those
is just a normal maintenance issue, doesn't involve any sort of
porting in gdb, etc.

> I am not sure.  It is the configure's job to check whether
> the library is wrong or broken.

Note that there's a fundamental issue with the workaround -- it
assumes that the gdb that generates CTF is the same that consumes it.
It's certainly easy to imagine a CTF file generated by a gdb not
affected by the bug be consumed by a gdb with the bug.  Or the other way
around.

>> 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?

My point is exactly that this is new-ish code, and a moving target.
If bugs are fixed promptly, why go through trouble working around
them in gdb instead of just updating the version in the distro?
It'd be different if we were talking about a one liner instead of
a good chunk of autoconf/pkg-config glue.

I'm not strictly objecting your patch, but it does look like
the kind of code that: #1 will need further tweaking in the future;
#2 will become obsolete anyway as time passes anyway.  Couple that
with the generator != consumer issue, and it raises eyebrows.

> 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

When the burden of supporting it outweighs the benefits?

>  2. stop supporting or using a library, such as the UST stuff in GDBserver,

When nobody wants to maintain it anymore (I personally don't)?

Thanks,
Pedro Alves