Re: Possible explanation for readline configuration problems - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Possible explanation for readline configuration problems
Date
Msg-id Pine.LNX.4.30.0104141052270.761-100000@peter.localdomain
Whole thread Raw
In response to Possible explanation for readline configuration problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Possible explanation for readline configuration problems  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> We've gotten several different reports lately of peculiar compilation
> errors and warnings involving readline in 7.1.  They look like configure
> is actively doing the wrong thing --- for example, how could we see
> reports like this:
>
> tab-complete.c:734: `filename_completion_function' undeclared (first use in this function)
> tab-complete.c:734: (Each undeclared identifier is reported only once
> tab-complete.c:734: for each function it appears in.)
>
> when the code makes a point of providing a declaration for
> filename_completion_function if configure didn't see it in the headers?

Because

(a) the readline dudes changed the type of filename_completion_function in
version 4.2 from
 extern char *filename_completion_function __P((char *, int));

to
 extern char *filename_completion_function __P((const char *, int));

and

(b) the readline dudes commented out (#if 0) the declaration of
filename_completion_function in the header in favour of the new
rl_filename_completion_function (but left the symbol in the library).

Other symbols were treated similarly, leading to implicit declarations
with ints.

Needless to say, the readline developers deserve to be shot for doing this
in a minor release.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: "Oliver Elphick"
Date:
Subject: Re: RPM upgrade caveats going from a beta version to RC
Next
From: Philip Warner
Date:
Subject: Re: pg_dump ordering problem (rc4)