Bug#873708: libsystemd-shared: symbol collisions
Johan Carlquist
jocar at su.se
Thu Aug 31 09:19:47 BST 2017
> On 30 Aug 2017, at 15:32, Felipe Sateler <fsateler at 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 at 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
More information about the Pkg-systemd-maintainers
mailing list