On Wed, Apr 8, 2020 at 7:34 PM Pierre Labastie via lfs-dev
<[email protected]> wrote:
>
> On Wed, 2020-04-08 at 14:06 +0200, Tadeus Prastowo via lfs-dev wrote:
> > Hello Pierre,
> >
> > On Wed, Apr 8, 2020 at 11:55 AM Pierre Labastie via lfs-dev
> > <[email protected]> wrote:
> > > Hi,
> > >
> > > We say that SHLIB_LIBS="-L/tools/lib -lncursesw" is needed to force
> > > Readline to link against the libncursesw library. But:
> > > 1) Even if readline uses the tremcap functions, it does not link
> > > against any library containing it (see the INSTALL file in source).
> > > 2) This switch had not effect to the only file where termcap
> > > appears:
> > > readline.pc, which has "Requires.private: termcap" anyway.
> > >
> > > Packages using the Requires.private field may therefore be fooled
> > > by this, but I have found none until now, so the problem is
> > > unlikely
> > > to occur.
> > >
> > > Anyway, there is a configure switch, --with-curses, which allows
> > > generating the correct readline.pc.
> > >
> > > So we should use this switch, and remove the SHLIB_LIBS settings,
> > > which
> > > do not bring anything.
> >
> > Have you taken into account the following messages for the reason to
> > have SHLIB_LIBS="-L/LFS-tools/lib -lncursesw"?
> >
> > https://lists.gnu.org/archive/html/bug-readline/2007-03/msg00003.html
> > and its reply
> > https://lists.gnu.org/archive/html/bug-readline/2007-03/msg00005.html
> >
> > https://lists.gnu.org/archive/html/bug-readline/2014-04/msg00007.html
> > and its reply
> > https://lists.gnu.org/archive/html/bug-readline/2014-04/msg00024.html
> >
> >
>
> No I didn't (before you pointed to them), but I think I came to the
> exact same conclusion as the person who replied in both threads: that
> could have been anticipated, since I used the present (readline-8.0)
> doc, specially INSTALL, which most likely has been written by the same
> person.
> I have tried everything I said. Linking both libraries completes OK
> even if SHLIB_LIBS is not passed. And adding --with-curses just changes
> the readline.pc file to reference ncurses instead of termcap.
I want to say that by specifying `-lncursesw' when building the shared
library, the resulting shared library clearly indicates the need to
link with (i.e., being forced to link against) libncursesw. This is
based on the first link, quoting:
When readline-5.2 builds its sharead library, it does not "-lcurses"
to the ld command. Consequently, the resultant .so file does not
indicate the it needs libcurses.so. So, attempts to link to link
agaisnt readline using "ld --if-needed" will fail.
End quote.
The reply to the first link says that indeed the forcing to link to
libncursesw has to be done manually.
I want to say by the third link that indeed the resulting shared
library needs to link with some library (libncursesw or such) although
the resulting shared library is built without any -lncursesw and such,
quoting:
On the other side, under Linux, shlib/libreadline is liked with:
$(CC) -shared -Wl,-soname,libreadline.so.6.3 -L/usr/lib -L/lib
-Wl,-rpath,/usr/lib -Wl,-soname,libreadline.so.6 -o libreadline.so.6.3
readline.so vi_mode.so funmap.so keymaps.so parens.so search.so
rltty.so complete.so bind.so isearch.so display.so signals.so util.so
kill.so undo.so macro.so input.so callback.so terminal.so text.so
nls.so misc.so history.so histexpand.so histfile.so histsearch.so
shell.so mbutil.so tilde.so colors.so parse-colors.so xmalloc.so
xfree.so compat.so
-> without passing TERMCAP_LIB, which leads to undefined symbols:
nm shlib/libreadline.so.6.3 | grep " U " | grep -v GLIBC
U BC
U PC
U tgetent
U tgetflag
U tgetnum
U tgetstr
U tgoto
U tputs
U UP
End quote.
The reply to the third link says that it is indeed the case while
confirming message that the forcing to link to libncursesw has to be
done manually.
> But I do not intend to commit this until I have done a complete rebuild
> of lfs, with ICA to make sure this problem has gone away.
Perhaps you need to check with a program that links to libreadline
using the --if-needed option.
> Pierre
--
Best regards,
Tadeus
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
