On 13 August 2015 at 21:14, David Woodhouse <dw...@infradead.org> wrote: > On Thu, 2015-08-13 at 13:25 -0500, Scott Duplichan wrote: >> A while back I experimented with mingw as a Windows hosted gcc tool >> chain for EDK2. It is usable, but has limitations. From a 2014 email >> to this list: > >> 1) Image is big due to dead library code in final image. >> 2) Default calling convention is different. This makes MINGW code >> generation differ from gcc-linux code generation. >> 3) MINGW sizeof long differs from gnu-linux size of long, resulting >> in more code generation differences. > > These aren't new issues, surely? The GCC builds are still larger than > the MSVC builds, largely due to CFLAGS as recently discussed but also > because we don't yet have LTO for GCC, do we? And we don't use > -ffunction-sections --gc-sections and other tricks so we can only drop > unused things out at the C file granularity. >
Another reason to unify the GCC compiler and linker flags: we do use -ffunction-sections -fdata-sections and --gc-sections, but only for GCC44 - GCC49, and these flags are not inherited by UNIXGCC et al So I suppose the linker output is a PE/COFF application when using MinGW, and the BaseTools/ just skip the ELF conversion in this case? I wonder whether --gc-sections works well here, but I can have a look. Btw I managed to complete the OVMF/X86 build with Mingw without any reported errors regarding the stack protector, which I did not disable afaik. What is the symptom you observed here? > We already have different calling conventions, and different size > 'long', between GCC and MSVC builds. MinGW is consistent with the MSVC > builds for this — why would that be a problem? That was the whole > *point* in wanting to use MinGW, for me — to test a LLP64 build without > the pain of actually having to use Windows+MSVC. > Indeed. The primary motivation for my recent involvement with the toolchain configs is to help ensure that the representative sample of toolchains we may propose for pre-commit compile tests sufficiently covers the architectures and toolchains we care about. And MinGW would be useful for this purpose as well, especially since it is a free toolchain that implements LLP64. -- Ard. > (I wonder if we could get the MSVC build running under wine... now > *that* would be useful) > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
