Bug#890228: libexpect.so: undefined symbols: needs to link with Tcl

2018-02-16 Thread Paul Wise
On Sat, 2018-02-17 at 10:37 +0300, Sergei Golovan wrote:

> Well, I know that and I'd like to keep it underlinked in order to make
> it possible to link with libtlc8.5 or libtcl8.6 for application which use it.

I see, I was not aware of this.

> The libtcl ABI is sufficiently stable and I don't want to restrict libexpect
> to any particular version of libtcl.

I note that libtcl does not use symbol versioning. In other cases of
mixing two versions of a library in the same process without symbol
versioning, this results in crashes. Does libtcl ABI avoid these issues?

> The libexpect manual explicitly says that any application using libexpect
> has to be linked with it and with libtcl.

Is this enforced in some way?

> If there's another reason why it shouldn't be underlinked I'd be glad
> to hear it.

Nothing apart for the usual reasons for avoiding underlinking.

> CC: cont...@bugs.debian.org, 
> tags 890228 + moreinfo
> thanks

BTW, this is a newer and simpler way to do that:

Control: tags -1 + moreinfo

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Bug#890228: libexpect.so: undefined symbols: needs to link with Tcl

2018-02-16 Thread Sergei Golovan
tags 890228 + moreinfo
thanks

Hi Paul,

On Mon, Feb 12, 2018 at 11:27 AM, Paul Wise  wrote:
> libexpect.so needs to link with Tcl, see the output of adequate,
> symtree and objdump below. I detected this on amd64 but the Debian
> build log scanner also detected dpkg-buildpackage complaining about it
> on other architectures, see the w3m and build log output below.
>
> I filed this bug at severity minor since it looks like the code using
> libexpect.so (expect, skycat) also already uses Tcl libs.

Well, I know that and I'd like to keep it underlinked in order to make
it possible to link with libtlc8.5 or libtcl8.6 for application which use it.
The libtcl ABI is sufficiently stable and I don't want to restrict libexpect
to any particular version of libtcl.

The libexpect manual explicitly says that any application using libexpect
has to be linked with it and with libtcl.

If there's another reason why it shouldn't be underlinked I'd be glad
to hear it.

Cheers!
-- 
Sergei Golovan



Bug#890228: libexpect.so: undefined symbols: needs to link with Tcl

2018-02-12 Thread Paul Wise
Package: tcl-expect
Version: 5.45.4-1
Severity: minor
File: /usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4
User: debian...@lists.debian.org
Usertags: undefined-symbol adequate

libexpect.so needs to link with Tcl, see the output of adequate,
symtree and objdump below. I detected this on amd64 but the Debian
build log scanner also detected dpkg-buildpackage complaining about it
on other architectures, see the w3m and build log output below.

I filed this bug at severity minor since it looks like the code using
libexpect.so (expect, skycat) also already uses Tcl libs.

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ adequate tcl-expect
tcl-expect:amd64: undefined-symbol 
/usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4 => Tcl_ErrnoMsg
tcl-expect:amd64: undefined-symbol 
/usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4 => Tcl_Free
tcl-expect:amd64: undefined-symbol 
/usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4 => Tcl_Alloc

$ man adequate | grep -A4 undefined-symbol
   undefined-symbol
   The symbol has not been found in the libraries linked with the 
binary.  Either the binary either needs to be linked with an additional shared 
library, or the dependency
   on the shared library package that provides this symbol is too weak.

   References: Debian Policy §3.5, §8.6, §10.2.

$ lddtree /usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4
libexpect.so.5.45.4 => /usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4 
(interpreter => none)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

$ symtree /usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4
/usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4
libutil.so.1 => openpty
libm.so.6 => log,pow
libc.so.6 => 
fflush,strcpy,__printf_chk,exit,srand,fopen,strncmp,optind,wait,__longjmp_chk,pipe,perror,__isoc99_sscanf,signal,strncpy,__vsprintf_chk,fork,time,__stack_chk_fail,unlink,realloc,abort,stdin,getpid,strftime,gmtime,strtol,isatty,feof,fgets,strlen,strstr,strcspn,tcsendbreak,__errno_location,tcsetattr,read,ttyname,getopt,dup2,__fprintf_chk,__sigsetjmp,stdout,memcpy,memcpy,rand,malloc,__ctype_b_loc,getenv,optarg,stderr,ioctl,alarm,system,dup,execvp,freopen,fileno,fwrite,waitpid,close,open,localtime,strchr,__vfprintf_chk,fdopen,tcgetattr,sleep,__strcpy_chk,__cxa_finalize,setsid,fcntl,__sprintf_chk,link,__xstat,memmove,_IO_getc,__strcat_chk,setbuf,strcmp,write,free
WEAK => _ITM_deregisterTMCloneTable,__gmon_start__,_ITM_registerTMCloneTable
UNRESOLVED => Tcl_Free,Tcl_Alloc,Tcl_ErrnoMsg

$ objdump -T /usr/lib/x86_64-linux-gnu/libtcl8.6.so.0 | grep -E "($(symtree 
/usr/lib/x86_64-linux-gnu/libexpect.so.5.45.4 | sed -n 's/UNRESOLVED => 
//p' | tr , '|'))$"
00117f30 gDF .text  03db  BaseTcl_ErrnoMsg
0004af60 gDF .text  0005  BaseTcl_Free
0004ae20 gDF .text  0021  BaseTcl_Alloc

$ w3m -dump https://qa.debian.org/bls/packages/e/expect.html | grep -A2 symbol
  • W shlibs-symbol-not-found (alpha, arm64, armel, armhf, hppa, hurd-i386,
i386, ia64, m68k, mips, mips64el, mipsel, powerpc, powerpcspe, ppc64,
ppc64el, s390x, sh4, sparc64, x32)

$ w3m -dump https://qa.debian.org/bls/bytag/W-shlibs-symbol-not-found.html | 
grep -A12 description
description

The build logs contains a like like

dpkg-shlibdeps: warning: symbol NAME used by BINARY found in none of the 
libraries.

Possible reasons:

  • A library not linked with a library needed.
While this can sometimes make sense in order to allow the using binary to
decide which of multiple available implementations to use, it means that
dependency information might be incorrect, optimisations like prelinking
might fail and stuff like that.

$ chronic getbuildlog expect last

$ grep 'dpkg-shlibdeps: warning: symbol .* used by .* found in none of the 
libraries' *.log
expect_5.45.4-1_alpha.log:dpkg-shlibdeps: warning: symbol Tcl_Free used by 
debian/tcl-expect/usr/lib/alpha-linux-gnu/libexpect.so.5.45.4 found in none of 
the libraries
expect_5.45.4-1_alpha.log:dpkg-shlibdeps: warning: symbol Tcl_Alloc used by 
debian/tcl-expect/usr/lib/alpha-linux-gnu/libexpect.so.5.45.4 found in none of 
the libraries
expect_5.45.4-1_alpha.log:dpkg-shlibdeps: warning: symbol Tcl_ErrnoMsg used by 
debian/tcl-expect/usr/lib/alpha-linux-gnu/libexpect.so.5.45.4 found in none of 
the libraries
expect_5.45.4-1_arm64.log:dpkg-shlibdeps: warning: symbol Tcl_Free used by 
debian/tcl-expect/usr/lib/aarch64-linux-gnu/libexpect.so.5.45.4 found in none 
of the libraries
expect_5.45.4-1_arm64.log:dpkg-shlibdeps: warning: symbol Tcl_Alloc used by 
debian/tcl-expect/usr/lib/aarch64-linux-gnu/libexpect.so.5.45.4 found in none 
of the libraries
expect_5.45.4-1_arm64.log:dpkg-shlibdeps: warning