consistent aslr and nxcompat flags for gcc build

[revelator]

I changed things a little after examining some other gcc build examples.

so after this block in PKGBUILD ->

local _LDFLAGS_FOR_TARGET="$LDFLAGS" export LDFLAGS+=" -Wl,--disable-dynamicbase"

yank this in ->
# keep flags consistent export BOOT_CFLAGS="${CFLAGS}" export CFLAGS_FOR_TARGET="${CFLAGS}" export BOOT_CXXFLAGS="${CXXFLAGS}" export CXXFLAGS_FOR_TARGET="${CXXFLAGS}" export BOOT_LDFLAGS="${_LDFLAGS_FOR_TARGET}" export LDFLAGS_FOR_TARGET="${_LDFLAGS_FOR_TARGET}"

and delete this line from configure ->
LDFLAGS_FOR_TARGET="${_LDFLAGS_FOR_TARGET}" \

this finally allows the bootstrap to have aslr and nxcompat availiable except for the plugin compiler which only gets nxcompat.
Hope it helps.

[revelator]

Or rather all dll's have aslr and nxcompat enabled but the excutables do not ... O_o this is rather odd as the above flags should propagate to all build stages and as it turns out it does but only for the dll's. Does the bootstrap unset these flags for executables ?.

[jeremyd2019]

My understanding is that the 'normal' CFLAGS/LDFLAGS apply to stage1, stage 2 and 3 use the BOOT_*FLAGS, and generally "dll's" (specifically code that would end up linked with compiler output) would use the *FLAGS_FOR_TARGET. The BOOT_LDFLAGS are set in the pkgbuild with the --with-boot-ldflags configure parameter. I'm not sure if the build system might override the environment variables.

[revelator]

seems so as i also set large adress aware and even this flag gets unset for executables in a bootstrap build.
Hmm bootstrapping is only really nessesary if some changes might break something so maybe we should skip bootstrapping ?
That way the executables atleast seem to keep the flags as well.

[revelator]

hmm anyone having trouble building qt5 with hardening ? mine fails in the 32 bit build with a segfault unless i turn it of.

[revelator]

non bootstrapped build indeed has aslr and dep set on both the executables and dll's, maybe a small workaround would be to disable bootstrapping if hardening is enabled in PKGBUILD ?. So far it seems to work just honky dory though some packages should probably have dynamicbase off as i noticed that even though they build they will segfault to no end if dynamicbase is enabled -> (most glib dependant tools and libraries wxwidgets and qt5) especially gobject introspection must not have dynamicbase on as it will break building pretty much anything relying on it. These do however still accept nxcompat or DEP.

[jeremyd2019]

non bootstrapped build indeed has aslr and dep set on both the executables and dll's, maybe a small workaround would be to disable bootstrapping if hardening is enabled in PKGBUILD ?.

I went through the build output files in #6907 and saw that the flags were applied as intended to (most) binaries. Note that aslr was intentionally disabled from the 'executables' due to it breaking pre-compiled headers.

So far it seems to work just honky dory though some packages should probably have dynamicbase off as i noticed that even though they build they will segfault to no end if dynamicbase is enabled -> (most glib dependant tools and libraries wxwidgets and qt5) especially gobject introspection must not have dynamicbase on as it will break building pretty much anything relying on it. These do however still accept nxcompat or DEP.

I know qt5 packages have been rebuilt since these changes, and I believe glib2 and gobject-introspection have as well. I have not seen any reports from people using these binary packages that they are suddenly segfaulting.

[revelator]

I spent the last days rebuilding every package and here most of the glib dependant packages segfault when dynamicbase is on ?!? O_o qt also seems to have some problem with it though only the 32 bit build, the static qt build does not seem to be affected. Not having any problem with pch here with dynamicbase on though so hmm...

Im using the official msys2 compiler so it should be the same as yours, or might other compilers interfere with it ? i have msvc 2017 installed and i noticed cmake had a tendency of picking it up atleast when building ogre which had the unpleasant effect that i had to move the windows kit directory or else it would try and build ogre with msvc's api using g++ (which though cool does not work).

[revelator]

Seems to be a problem with older gcc (i use gcc-9.3.0) previously with TDM's patches for linking by default to the static runtimes but after it turned out that it could not handle aslr when patched with TDM's patches i decided to remove those and do a full rebuild. It works with most packages but a select few as mentioned are not inclined to behave correctly so im biting the bullet and upgrading to gcc-10.0.2. Hopefully things will go smoother from there.

[revelator]

Well this is somewhat weird, gcc-10.2.0 produces working aslr and dep compatible executables gcc-9.3.0 does not allways.
Did something change in gcc ? since the 9.3.0 version is not that old i find it a bit odd that it should be unable to handle this.
Or is this why you disabled plugin support ? as i noticed some projects where actually using the plugin compiler as a linker.
Well no matter it works fine now.

[jeremyd2019]

Glad to hear it's working for you.

I don't know what plugin support you are referring to that would be disabled. The GCC lto plugin is built and I have seen it work (when building the mingw-w64-python package).

[revelator]

from gcc-9 it was possible to build compiler plugins like on linux with this flag --enable-plugin, it is disabled in gcc-10 though, so i wondered if this was the source of my problems.

[revelator]

Hmm no it seems the compiler plugins where disabled because they no longer build...
export ordinals are to large which mean that the list of symbols has become to long for the linker to properly link the plugins.
This worked with gcc-9 but it seems the introduction of some extras has finally broken the camels back atleast on windows as the plugin compiler reilies on having all the symbols linked in whereas on unix we can get away with weak links.

[MehdiChinoune]

All MinGW-packages are now built with ASLR