Re: RFH: nsd on mips

[Ben Burton <bab@debian.org>]

Hi.

> nsd doesn't have it's own xfer program, so it uses bind as build depends
> and copies named-xfer to nsd-xfer on build time.  On mips (and only on
> mips) it breaks when dependencies are tried (ldd nsd-xfer).  Could
> someone please look at this issue and try to build it manualy?

I've taken a look at this -- the build fails in my mips/unstable chroot
also.

The problem is at the dh_strip stage.  Your package takes the
(already-stripped) named-xfer from bind and runs dh_strip, which strips
it again.  It is after this that the executable becomes broken.

Some further testing shows that on my main sarge system (binutils
2.14.90.0.7-8), running strip on the original named-xfer does nothing to
the executable (as expected, since it was already stripped during the
bind build).  In my sid chroot (binutils 2.15-1), running strip on the
original named-xfer results in a further reduction in size and a broken
executable.

    metebelis$ ls -l named-xfer
    -rwxr-xr-x  1 root root 421940 Aug 24 12:07 named-xfer
    metebelis$ ldd named-xfer
            libc.so.6 => /lib/libc.so.6 (0x2ab02000)
            /lib/ld.so.1 => /lib/ld.so.1 (0x2aaa8000)
    metebelis$ strip named-xfer
    metebelis$ ls -l named-xfer
    -rwxr-xr-x  1 root root 421268 Aug 24 12:07 named-xfer
    metebelis$ ldd named-xfer
            not a dynamic executable
    metebelis$

I'm not sure precisely what's breaking, but as a temporary workaround
you could simply exclude nsd-xfer from dh_strip (e.g., pass a -X
argument to dh_strip, but I don't know what the cdbs mechanism is for
doing this).  Strictly speaking this should be fine since named-xfer
should be stripped anyway according to policy.

HTH - Ben.