Void-packages: -fstack-clash-protection breaks clang-built packages

[Francesco149]

clang doesn't support -fstack-clash-protection. because of this, packages such as godot fail to build with errors like clang-7: error: unknown argument: '-fstack-clash-protection

seems like this was introduced in 6b81302e380aaf6688982b932a4efff7c642a7f5

not sure if it's worth removing the flag when you can just remove it from CFLAGS in such packages, but i thought it's worth reporting

[maxice8]

On Sun, Mar 24, 2019 at 08:05:28PM -0700, Franc[e]sco wrote:

clang doesn't support -fstack-clash-protection. because of this, packages such as godot fail to build with errors like clang-7: error: unknown argument: '-fstack-clash-protection

seems like this was introduced in 6b81302e380aaf6688982b932a4efff7c642a7f5

not sure if it's worth removing the flag when you can just remove it from CFLAGS in such packages, but i thought it's worth reporting

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/void-linux/void-packages/issues/10244

That is a very important security flag, i think it is better to just work around it on Clang until they get around to it.

[Anachron]

I've just hit the same issue on hedgewars: https://travis-ci.org/void-linux/void-packages/jobs/596499816#L4439

[Anachron]

@Hoshpak could we make the build-system smart enough to figure out were usingclanand not add thissecurity flagto theCFLAGS`?.

@Hoshpak wait, how can I override CFLAGS and CXXFLAGS when it's overwritten by the build_system?

[Anachron]

@leahneukirchen @pullmoll

I think we should handle it like the linux kernel and not add this protection unless our clang supports it.

[Duncaen]

I don't think there is a good way to know which CC is going to be used, configure and make can do all sorts of things to use a different CC than what xbps-src exports.
xbps-src assumes gcc is the default compiler. I don't see a problem with templates that use a non default option having to work around the default CFLAGS compared to adding a probably more broken and unpredictable workaround to xbps-src.

[Hoshpak]

I agree. We could of course add a compiler variable to specify if clang or gcc is used for the build but every build might still pull in the other compiler indirectly. So waiting for a clang fix and working around in the templates that need it seems the best option for me.