On 9/5/18 5:26 PM, Alec Leamas wrote: > On 05/09/18 09:18, Sebastiaan Couwenberg wrote: >> On 9/4/18 7:46 PM, Alec Leamas wrote: >>> On 04/09/18 10:16, Sebastiaan Couwenberg wrote: >>>> There are some lintian issues that need to be addressed: >>>> >>>> Since it's a C library adding a symbols files is a must, >>> >>> Done >> >> Note quite, there are no actual symbols in the file as generated by >> dpkg-gensymbols. >> >> You can update the symbols file with the patch generated by >> dpkg-gensymbols as found in the build log. > > This symbols file thing is clear as mud for me, I just don't get it. > Running dpkg-gensymbols does not produce any diff I can see, the > created debian/tmp/DEBIAN/symbols is identical to the original > debian/libunarr1.symbols. > > The more I look into this, the more weird. I cannot see any usable > symbols in the generated solib using objdump or nm. Is this the reason > gensymbols doesn't generate anything?
You just need to build the package, and feed the build log to patch: patch -p0 < ../unarr_0~20150801.d1be8c43-1_amd64.build See also: https://wiki.debian.org/UsingSymbolsFiles > Isn't a library so-file without visible symbols terribly wrong? Yes, that implies that no methods are exported which can be used by other programs, defeating the purpose of being a shared library. How is opencpn supposed to use libunarr?
