> On 30 Aug 2017, at 15:32, Felipe Sateler <fsate...@debian.org> wrote: > > BTW, defining generic symbol names like `parse_time` in a public > library like heimdal does is a bad idea. It would be nice to have > heimdal either properly namespace their public symbols or hide > nonpublic symbols. Johan, could you file a bug on heimdal for this issue?
Looking at both `libkrb5.so.26` which needs the symbol and `libroken.so.18` which holds the symbol both have versions: ``` # readelf --syms /usr/lib/x86_64-linux-gnu/libkrb5.so.26 | grep parse_time 537: 0000000000000000 0 FUNC GLOBAL DEFAULT UND parse_time@HEIMDAL_ROKEN_1.0 (7) ``` ``` # readelf --syms /usr/lib/x86_64-linux-gnu/libroken.so.18 | grep parse_time 143: 0000000000008e80 29 FUNC GLOBAL DEFAULT 13 unparse_time@@HEIMDAL_ROKEN_1.0 153: 0000000000008e70 15 FUNC GLOBAL DEFAULT 13 parse_time@@HEIMDAL_ROKEN_1.0 267: 0000000000008ea0 29 FUNC GLOBAL DEFAULT 13 unparse_time_approx@@HEIMDAL_ROKEN_1.0 ``` What seems to be happening is that the currently unversioned symbol in `libsystemd-shared-232.so` is allowed to satisfy the reference even if the requesting library is specifying a specific version: ``` # readelf --syms /lib/systemd/libsystemd-shared-232.so | grep parse_time 546: 0000000000110430 2646 FUNC GLOBAL DEFAULT 12 parse_timestamp 1454: 000000000010e4d0 828 FUNC GLOBAL DEFAULT 12 parse_time ``` Looking around we found an old (and generally unrelated) Debian bug which discusses a similar issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=232920 -- jocar