[email protected] (Marco d'Itri) writes: > It is really simple, I just generated the symbols files for the > version in stable and then updated it with the symbols for the > version in testing. The first patch adds the symbols file.
Thanks! > Some symbols disappeared between the two releases, but since you > have not changed the SONAME I assumed that they are internal > symbols exported by mistake. If you want to fix this I added a > second patch which uses a linker script to suppress some symbols > (the list is just an example, I have no idea of the official > libpcap ABI!). Yeah, the library currently exports all its private symbols, and those come and go between releases. Up until recently upstream didn't even build a shared library and didn't really care about the ABI. It changed with version 1.0, they now promise to keep binary compatibility, but they don't provide an official ABI that I could use. In the past I've handled changes to the private symbols on a per-release basis based on what user applications actually link against in Debian; in practice I've never found any application that uses private stuff and upstream didn't break compatibility of the public interface, so the soname didn't change. I'm not sure if I should just define the ABI on my own based on what I think is public (e.g. what's defined in the headers), or just leave the private symbols in the symbols file... I don't think upstream wants to commit to maintain an ABI definition just yet. -- Romain Francoise <[email protected]> http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
