x265: shared lib should be linked with -Bsymbolic and one other issue

[bergerspencer]

See pull request #208. Recently, when I was building an x265 that supported multiple bit depths, I discovered a couple of issues with the patch that was introduced in TritonDataCenter/pkgsrc-legacy#455.

The first issue with the patch is that it went further than it needed to, and completely removed -Bsymbolic on SunOS when it was only necessary to remove it from the executable target. This breaks bit-depth introspection. Even if you don't care about bit-depth introspection, it's best to stay as close to upstream as possible; it's possible other programs that link x265 also rely on it being compiled with -Bsymbolic

The second issue is that the patch adds "-Wa,--noexecstack" to the linker flags, which does nothing.

There are 3 reasons it does nothing:

1. cmake only sends the flag to gcc at the linking stage, it is never sent during the compilation stage
2. x265 doesn't use gcc to assemble its handwritten assembly, it uses nasm (formerly yasm), so passing -Wa,--noexecstack in the correct place wouldn't help; gcc of course already marks its generated assembly without needing this flag
3. As the patch comment questions, solaris ld ignores this anyway; if you compile a one-file c-program with gcc7 from pkgsrc it's not marked as noexecstack

This isn't a big deal because the default for 64 bit executables is a nonexecutable stack, even if they don't have the appropriate ELF header. But I figured I may as well pass a flag that generates a PT_SUNWSTACK header since it's necessary to pass -mimpure-text anyway.

[despair86]

nice. I knew I was missing something in my own patch, but I hardly use symbolic linkage in my own projects 🤷🏻