Message ID | 20210820161502.8497-1-jack@suse.cz |
---|---|
State | Accepted |
Headers | show |
Series | libss: add newer libreadline.so.8 to dlopen path | expand |
On Fri, Aug 20, 2021 at 06:15:02PM +0200, Jan Kara wrote: > OpenSUSE Tumbleweed now has libreadline.so.8. Add it to the list of libs > to look for. > > Signed-off-by: Jan Kara <jack@suse.cz> > --- > lib/ss/get_readline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Hum, why don't we look for libreadline.so BTW? That way we could save adding > now so version whenever one appears? We do actually look for libreadline.so; it's right after libreadline.so.4: > -#define DEFAULT_LIBPATH "libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so" However, we still need the libreadline.so.N in the path because at least for some distributions, they only install libreadline.so if you install the -dev package. For example, in Debian, libreadline.so.8 is installed from the libreadline8 package, while libreadline.so is installed from the libreadline-dev package (and it's not guaranteed to be installed). Fortunately for Debian users, openssh-client depends on libedit2, which means that even if they don't have libreadline-dev installed, we fall back to using libedit.so.2, which does work. So apparently no one noticed that a problem with debugfs on Debian Bullseye (which ships libreadline.so.8). But I agree that we should add libreadline.so.8 to the search path. Thanks, applied. - Ted
On Fri 20-08-21 17:07:39, Theodore Ts'o wrote: > On Fri, Aug 20, 2021 at 06:15:02PM +0200, Jan Kara wrote: > > OpenSUSE Tumbleweed now has libreadline.so.8. Add it to the list of libs > > to look for. > > > > Signed-off-by: Jan Kara <jack@suse.cz> > > --- > > lib/ss/get_readline.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Hum, why don't we look for libreadline.so BTW? That way we could save adding > > now so version whenever one appears? > > We do actually look for libreadline.so; it's right after > libreadline.so.4: > > > -#define DEFAULT_LIBPATH "libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so" > > However, we still need the libreadline.so.N in the path because at > least for some distributions, they only install libreadline.so if you > install the -dev package. For example, in Debian, libreadline.so.8 is > installed from the libreadline8 package, while libreadline.so is > installed from the libreadline-dev package (and it's not guaranteed to > be installed). Oh, right. I've just checked and on my openSUSE machine libreadline.so is also only provided by readline-devel package (which I have installed so I didn't originally noticed). Thanks for explanation. I'm just wondering if there isn't a better way to search for a suitable library... Honza
diff --git a/lib/ss/get_readline.c b/lib/ss/get_readline.c index 11c72b3387d1..aa1615747934 100644 --- a/lib/ss/get_readline.c +++ b/lib/ss/get_readline.c @@ -37,7 +37,7 @@ static void ss_release_readline(ss_data *info) #endif /* Libraries we will try to use for readline/editline functionality */ -#define DEFAULT_LIBPATH "libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so" +#define DEFAULT_LIBPATH "libreadline.so.8:libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so" #ifdef HAVE_DLOPEN void ss_get_readline(int sci_idx)
OpenSUSE Tumbleweed now has libreadline.so.8. Add it to the list of libs to look for. Signed-off-by: Jan Kara <jack@suse.cz> --- lib/ss/get_readline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Hum, why don't we look for libreadline.so BTW? That way we could save adding now so version whenever one appears?