On Mon, Oct 01, 2007 at 09:18:22PM +0200, Michael Koch wrote: > On Mon, Oct 01, 2007 at 05:47:34PM +0200, Raphael Hertzog wrote: > > Hello,
> > since library maintainers will soon have the possibilty to use > > symbol-based dependencies (instead of shlibs) I setup a system > > to keep up-to-date ready-to-use symbols files using Mole: > > http://qa.debian.org/cgi-bin/mole/seedsymbols > I dont know how common that is but I maintain for example some libraries > that exports different APIs on 32-bit userland and 64-bit userland > ([1] and [2], I haven't looked for more). > What do you recommend for such a case? Using debian/package.symbols and > overriding all 64-bit archs with debian/package.symbols.$ARCH? diff -u <(c++filt libskstream-0.3-4_i386) <(c++filt libskstream-0.3-4_amd64) --- /proc/self/fd/63 2007-10-01 14:36:26.997477143 -0700 +++ /proc/self/fd/62 2007-10-01 14:36:26.997477143 -0700 @@ -1 +1 @@ -libskstream-0.3-4_i386 +libskstream-0.3-4_amd64 The fact that C++ symbols will be mangled differently on different architectures was discussed, but I don't remember seeing a decision that the unmangled symbol names would be used in symbol manifests for dpkg-shlibdeps. Surely the symbol tables should be demangled here? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
