The functions defined in these sources are referenced all over the place, however, compiler only when building with readline. Thus when building without it linker gets sad as it can't find them. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt;

Apparently we can't assume that people run readline recent enough to have rl_completion_quote_character (added in readline-5.0 released in 2011). However, we can't compile without it. So if not present, disable readline. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- Frankly, I hate this patch. How far into the past do we want to go when introducing something new? 10 years? 15? I've only written this patch because travis is unhappy without it (I'm looking at you Mac OS/X).

On Mon, 2018-01-15 at 10:26 +0100, Andrea Bolognani wrote: > macOS has brew, though. I've kicked off a Travis build with this > commit[1] included, let's see whether configure picks up readline > installed from brew instead of the obsolete one available in the > base system. Nope, it still picks up the one shipped with the OS :/ > If it does, then we can omit your patch and... Document the version > requirement somehow? If we used pkg-config to detect readline > availability, that would be easy. Alas, readline only introduced > pkg-config support relatively recently, so we can't do that. So, one way to solve this once and for all would be to: * try looking up readline through pkg-config. If that works, then we already know we're compiling against a recent readline version and everything will work; * if readline's pkg-config file is not available, try linking against it the old way. This will succeed on oldish versions like the one shipped with CentOS but fail because of missing functions on macOS. I could try cooking up something like the above, but I can never seem to get it right the first couple of times when m4 is involved, so in the interest of time - and not having to merge this patch you hate ;) - would you mind looking into it yourself instead?

On Mon, 2018-01-15 at 13:31 +0100, Michal Privoznik wrote: > > So, one way to solve this once and for all would be to: > > > > * try looking up readline through pkg-config. If that works, > > then we already know we're compiling against a recent > > readline version and everything will work; > > > > * if readline's pkg-config file is not available, try linking > > against it the old way. This will succeed on oldish versions > > like the one shipped with CentOS but fail because of missing > > functions on macOS. > > > > I could try cooking up something like the above, but I can never > > seem to get it right the first couple of times when m4 is involved, > > so in the interest of time - and not having to merge this patch you > > hate ;) - would you mind looking into it yourself instead? > > The reason I hate this patch is not because the patch itself looks ugly. > It's because we have to deal with the situation in the first place and > invest our time in resolving it. And what you're suggesting might sound > right but we'll end up with the same situation after all. I don't think that's the case. Right now we have to work around issues in macOS all the time because we're linking against the obsolete readline version included in the base system; if we implemented what I propose above, then we could just mandate that readline 6.0 or newer is required. macOS builds would then fail unless you install a recent readline using brew, but that's entirely acceptable, and we would have obtained a reasonable baseline to work against going forward. Plus it would allow us to get rid of some nasty hacks[1] on our CI as well :)

> So, one way to solve this once and for all would be to: > > * try looking up readline through pkg-config. If that works, > then we already know we're compiling against a recent > readline version and everything will work; I just found out that this will not work - even though there is readline.pc.in in the readline repo, they are lacking rule to install the .pc file. So nobody ships that. For instance, on my rawhide box: [root@fedora ~]# rpm -q readline readline-7.0-5.fc26.x86_64 [root@fedora ~]# rpm -ql readline | grep \.pc [root@fedora ~]#

> * if readline's pkg-config file is not available, try linking > against it the old way. This will succeed on oldish versions > like the one shipped with CentOS but fail because of missing > functions on macOS. I should have commented earlier too - what good it is to switch to pkg-config if we're keeping the old way of detecting the library (with this patch included) anyway?

Therefore I think we should merge this patch and switch to pkg-config later (when distros have it).

> At least FreeBSD ships it, though: > > # pkg list readline | grep pc$ > /usr/local/libdata/pkgconfig/readline.pc is this GNU readline? I've heard that FreeBSD is ditching GNU software.

> > > * if readline's pkg-config file is not available, try linking > > > against it the old way. This will succeed on oldish versions > > > like the one shipped with CentOS but fail because of missing > > > functions on macOS. 1: ^^^ > > I should have commented earlier too - what good it is to switch to > > pkg-config if we're keeping the old way of detecting the library (with > > this patch included) anyway? > > We wouldn't need to include this patch: we could just assume > a readline new enough to provide a .pc file contains all the > functionality we need. Well, what if isn't? We would just disable readline? We can't because you're advocating for linking the old way [1]. However, that wouldn't work on systems where we require more than just -lreadline (which is current situation). Currently, the problem is that my code requires this rl_completion_quote_character variable from readline.h. It's not a function, it's a variable. And if not present, compilation fails. So what should we do if pkg-config fails?