zstream: remove duplicate highbit64 definition

[robn]

Motivation and Context

I tried a static build and it didn't work, oh no!

Description

When building a static build (--disable-shared), zstream fails to link because of the duplicate highbit64() in libzpool/kernel.c. Since they're identical, and the libzpool one is visible to zstream, we remove zstream's copy and just use the common one.

How Has This Been Tested?

Build with --disable-shared. Before:

  CCLD     zstream
/usr/bin/ld: ./.libs/libzpool.a(libzpool_la-kernel.o): in function `highbit64':
/home/robn/code/zfs/lib/libzpool/kernel.c:712: multiple definition of `highbit64'; cmd/zstream/zstream_redup.o:/home/robn/code/zfs/cmd/zstream/zstream_redup.c:63: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:7359: zstream] Error 1

After:

  CCLD     zstream

(Thrills amirite).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[behlendorf]

Looks like some accidental breakage from ccf89b3 which added libzpool.la. I'm a little surprised this didn't result in a warning.

[robn]

Ahh, and that explains why I hadn't seen it before - I've only ever done static builds from 2.1.x.

It's been many many years since I thought much about linking, but I think it sort of makes sense that it doesn't throw a warning. For shared, the symbol is visible in that compilation unit, so it never would have generated a relocation stub for it, so the runtime linker would never have known. For static though, the linker mostly just collects up a list of all the visible symbol names and hooks them all up, and it would have found two with the same name.

If anything, I guess we should have a static build test somewhere too. Someday maybe.

Cheers :)