bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] underlinking of readline-6.3


From: Allan McRae
Subject: Re: [Bug-readline] underlinking of readline-6.3
Date: Wed, 05 Mar 2014 09:32:25 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 05/03/14 01:56, Natanael Copa wrote:
> On Tue, Mar 4, 2014 at 3:53 PM, Chet Ramey <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On 3/4/14 3:06 AM, Natanael Copa wrote:
>     > Hi,
>     >
>     > There is an (apparently intentional) underlinking issue in
>     readline. With
>     > readline 6.2 you could workaround that breakage with:
>     >
>     >   make install SHLIB_LIBS=-lncurses
> 
>     The relative merits and `breakage' of `underlinking' aside, it seems
>     more
>     likely that this is a behavior of your make program.  There have not
>     been
>     any significant changes in {,shlib}/Makefile.in between readline-6.2 and
>     readline-6.3 that would affect this.
> 
> 
> Something must have changed because things broke badly after upgrade to
> readline-6.3 on Alpine Linux.
> 
>  
> 
>     In fact, I ran configure on a clean readline-6.3 build directory,
>     then ran
> 
>     gmake install DESTDIR=/some/scratch/directory SHLIB_LIBS=-lncurses
> 
>     and watched make run gcc with the new value of SHLIB_LIBS:
> 
>     gcc -shared -Wl,-soname,libreadline.so.6.3 -Wl,-rpath,/usr/local/lib
>     -Wl,-soname,`basename libreadline.so.6.3 .3` -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
>     -lncurses
> 
>     If you mean something else, please let me know.
> 
> 
> Indeed. Seems like adding --disable-static fixed it. When I check the
> output here I also  see the -lncurses (even when it gets underlinked):
> 
> ccache gcc -shared -Wl,-soname,libreadline.so.6.3 -Wl,--as-needed
> -Wl,-rpath,/us
> r/lib -Wl,-soname,`basename libreadline.so.6.3 .3` -o libreadline.so.6.3
> readlin
> e.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so
> complete.so bi
> nd.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
> histfil
> e.so histsearch.so shell.so mbutil.so tilde.so colors.so parse-colors.so
> xmalloc
> .so xfree.so compat.so -lncurses
> 
> but readelf clearly shows that ncurses is not in NEEDED section.
> 
> Ok. I figured it out now. What actually happened is that I only added
> SHLIB_LIBS=-lncurses during 'make' phase but not during 'make install'. 
> Adding SHLIB_LIBS to 'make install' or adding ./configure
> --disable-static solved it. I guess that building static makes the
> shared lib relink during make install phase. possibly due to a gnu make
> race condition on multicores but I havent investigated that.
> 
> I bet Arch Linux gets bitten by this too (but since glibc is more
> forgiving they havent noticed yet):
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/readline&id=e6dc8e460c2b120c10215c67688d9ccc200efc9d
> 

Arch Linux is fine:

$ readelf -d /usr/lib/libreadline.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libncursesw.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

(we always link to the wide-character version of ncurses)

Allan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]