libpthread symbols duplicating libc ones confuse appchecker - add to LSB?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lsb |
Fix Committed
|
Medium
|
Unassigned | ||
Mandriva |
Fix Released
|
Medium
|
Bug Description
A list of libpthread symbols that duplicate libc interfaces
One of the common kind of issues reported by Linux AppChecker (in its 'main'
tab, not in the 'LSB Compliance' one) is "symbol is in LSB, but assigned to
another library".
A particular valuable example concerns symbols exported by both libc and
libpthread which are assigned to libc in LSB. Since libpthread normally
precedes libc in the NEEDED list, AppChecker honestly decides that such symbols
will be imported from libpthread.
When uploading application data to the database, we use a slightly 'hacked'
algorithm that always assigns such symbols to libc; not sure if we use the same
trick in the AppChecker right now, but independently of this, maybe it makes
sense to include libpthread symbols to LSB, as well? These symbols have the
same versions as the ones from libc, and seem to be exact duplicates of them.
(We already have an example of symbol 'migration' in the other direction in the
bug #1716; before the patch from that bug, it could seem quite confusing that
we include lseek from libc while lseek64 is from libpthread. Probably the
complete solution would be to include lseek and lseek64 from both libc and
libpthread.)
The whole list of libpthread symbols to be considered as LSB candidates is
attached.
Changed in mandriva: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |