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