Direct binding and libumem

[Dagobert Michelsen]

Hi folks,

I just encountered an interesting case: when compiling the latest xjobs (which does
not have funky linker magic at all) I got the following checkpkg result:

> CHECKPKG_OVERRIDES_CSWxjobs += no-direct-binding|/opt/csw/bin/xjobs|is|not|directly|bound|to|soname|libumem.so.1


Inspection of the build process showed that -B direct is correctly passed.
Using the excellent documentation at the checkpkg error tag wiki at
  http://wiki.opencsw.org/checkpkg-error-tags#toc31
showed the following issue:

> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/xjobs/trunk > $(mgar show-buildsys | cut -f1)/bin/check_db_symbols work/solaris10-sparc/pkgroot/opt/csw/bin/xjobs
> Use of uninitialized value $library_path in string eq at /home/dam/mgar/pkg/.buildsys/v2/bin/check_db_symbols line 64, <$ldd> line 4.
> Use of uninitialized value $soname in hash element at /home/dam/mgar/pkg/.buildsys/v2/bin/check_db_symbols line 67, <$ldd> line 4.
> 
> Library                 Directly bound    Not directly bound    Not directly bindable
> libumem.so.1                    0                  0                      3
> libc.so.1                      74                  0                      2
> libm.so.2                       2                  0                      0


It seems that some libraries contain only not directly bindable symbols,
essentially these should be excluded from the test.
@Yann: Do you think this is possible?


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20140304/ca2f949b/attachment.p7s>