Support `-fvisibility=hidden`, use explicit visibility attributes for both private and public symbols about blst

[arnetheduck]

Regarding the last point, without a linker script or -fvisibility=hidden, the code can not be linked into a pic/pie executable due to lack of the right kind of relocations necessary for default-linkage symbols, making the build fail on __blst_platform_cap requires dynamic R_X86_64_PC32 reloc against....

[dot-asm]

Currently, symbol exports are controlled via a linker script

Not anymore:-) But even if it still was, you can rely on the fact that private symbols originating from C are all static and those coming from assembly module - hidden. As build.sh does now.

__blst_platform_cap should ideally be marked with hidden visibility

Done. [There also were hidden directives missing in src/asm/ct_* modules.] Thanks!

[arnetheduck]

you can rely on the fact that private symbols originating from C are all static

cap was not, which caused a fair bit of headscratching ;) thanks for looking into it.

[dot-asm]

can not be linked into a pic/pie executable due to lack of the right kind of relocations necessary for default-linkage symbols

-Bsymbolic is the answer to this question. It's argued that the option is more than appropriate, even necessary, for security libraries. Point is that symbols in non-Bsymbolic modules are easily overridden by other modules leaving you not knowing what's going on.

[arnetheduck]

thanks, lgtm! closing, was able to integrate successfully

[arnetheduck]

-Bsymbolic - I would assume that for hidden symbols, this wouldn't be a problem?

[dot-asm]

-Bsymbolic - I would assume that for hidden symbols, this wouldn't be a problem?

Correct. Linking to .hidden symbols is equivalent to -Bsymbolic. -Bsymbolic is still appropriate though, it helps in cases you both refer to a symbol internally and export it.