[Xapian-devel] Xapian core build failure under gcc 2.95

[David Sainty]

Olly Betts wrote:
> On Thu, Jan 15, 2009 at 04:53:52PM +1300, David Sainty wrote:
>   
>> David Sainty wrote:
>>     
>>> Under gcc 2.95 Xapian fails to build like so:
>>>       
>> I can confirm that the attached patch fixes the build under gcc 2.95 
>> (after an automake).
>>     
>
> Thanks for the patch.
>
> But it seems there's something odd going on, as other subdirectories
> also include headers from the same directory without an explicit -I.
> The files here are generated, but that shouldn't make a difference as
> they are shipped in the tarball and it appears you're building from the
> 1.0.10 source tarball.
>
> Perhaps the issue is the "#line" directives with full paths in
> queryparser_internal.cc - if GCC 2.95 resolves header includes relative
> to the filename given by "#line" then that would cause this problem.
>
> Could you try:
>
> perl -pi -e 's/^#line.*//' queryparser/queryparser_internal.cc
>   

Huh, mighty good guessing! Yeah, that also fixes the build (without the 
patch).

Cleaning out the "#line"s is a good thing, but I'm not totally sure it 
should replace the patch? (Since files are being included unqualified 
from "queryparser/" I think it deserves being in INCLUDES?)

I don't think gcc's behaviour here is universally true of all compilers 
(implying the source directory as an include path entry), but in saying 
that I'm not sure of a counterexample either. Obviously 2.95(.4) has the 
required behaviour in some form, but is confused by the #line lines.

> (Unfortunately I no longer have access to GCC 2.95 to test this myself).
>   

And nor should you :) I was taken aback when I noticed what version I 
had to work with too :)

> Another question - what's the reason for using GCC 2.95?
>
> We came quite closing to dropping support for GCC < 3 a while back (but
> instead we ended up requiring 2.95.3 which added <sstream>).  But I'd
> assumed that 2.95 was probably no longer used by now, and there are a
> few minor issues we currently work around to keep support for it, so if
> there are still people using it I'm interested as to why.
>   

Yeah, it's in use on some old systems that are long long overdue for 
updates. A separate project is working on that, but it's not a variable 
I can control. Essentially it's the usual reasons - the more important 
the server the harder it is to regularly maintain it :)

Cheers,

Dave