Description
TLDR
Currently, anyone building runtime
can't easily and correctly add to the C compiler flags (CFLAGS
) used by runtime
. This is required by Linux distributions. A naive workaround results in various side-effects and can produce broken .NET Core builds.
The Full Version
We are trying to work on getting .NET Core integrated into various Linux distributions. Some of them have a policy about using "standard" compiler flags (often via the CFLAGS
environment variable). That, along with how runtime builds, makes it difficult to produce known-to-work builds of .NET Core.
Linux Distribution policies
Many Linux distributions have a packaging policy/suggestion/requirement to produce "secure" builds by using the distributions' standard CFLAGS
/CXXFLAGS
.
Debian has a Release goal for supporting standard (security) flags :
This goal is to update as many packages as possible to use security hardening build flags via dpkg-buildflags. These flags enable various protections against security issues such as stack smashing, predictable locations of values in memory, etc.
Even more information here: https://wiki.debian.org/Hardening. This also applies to Ubuntu, since it follows Debian's packaging rules. In fact, Ubuntu recommends you get your package into Debian first.
Fedora says:
Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build.
The Fedora compiler flags include -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
but also -Wall
.
Gentoo says:
In Gentoo-based systems, set the CFLAGS and CXXFLAGS variables in /etc/portage/make.conf. Variables set in this file will be exported to the environment of programs invoked by portage such that all packages will be compiled using these options as a base.
Mixing this with .NET Core
Over in Fedora Linux, we have been building/packaging .NET Core, including coreclr and corefx (now libraries) from source. Fedora, as mentioned above, requires that we build .NET Core with distribution-standard compiler options.
The normal way to do that is by exporting environment variables like CFLAGS
and CXXFLAGS
. Fedora provides a bunch of values that we can use . But this doesn't play very nice with the liberal use of -Werror
in corefx. Worse, the flags leak into various configure tests . For example HAVE_IN_PKTINFO
would fail due to an unrelated warning. I use this to work around this sort of test: https://gist.github.com/omajid/2e31ae5262256c275716d9c374dabe20.
What makes this even worse is Unfortunately, the configure tests are quite spread out. So it's possible for me to miss saving/setting/restoring CFLAGS
in a custom patch. I have had configure tests that conclude that the system is different than what it really is just because of a CFLAGS
confusion :
runtime/src/libraries/Native/Unix/configure.cmake
Lines 324 to 334 in 1d70b31
Fedora would set CFLAGS
to a value that included -Wall
and this configure check would fail to compile code (because of unused variable, if I recall correctly) and decide HAVE_GNU_STRERROR_R
is false
.
See https://pagure.io/dotnet-sig/dotnet-2-1/c/29673bc6dc37f205890fa1090e58d757bd262afb?branch=master for a hacky workaround.
Some common/possible solutions
-
Generally, this problem is avoided entirely by most applications/libraries using
autotools
andcmake
because the Linux distributions let us split out theconfigure
/cmake
call (the "configuration phase") from the finalmake
call (the actual "build phase"). It's common to not touchCFLAGS
and friends for the configuration phase and only set it to the distribution's required values during the build phase. Unfortunately this doesn't work forruntime
. Bothcmake
andmake
are called indirectly by a single build script./build.sh
. This makes it difficult for builders to overrideCFLAGS
just for themake
call. -
Another common solution is to provide some way way for users to provide
CFLAGS
, maybe through a flag like--with-cflags
, and this value is used to initialize the environment variableCFLAGS
only for invokingmake
(not forcmake
). -
We could accept some special environment variables, and use that to append to
CFLAGS
, but only for invokingmake
(not forcmake
).
This was originally opened as dotnet/source-build#745, but I think this is mostly a problem in the runtime code.