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@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
smime.p7s
Description: S/MIME cryptographic signature
