On 2015-08-18 04:01:36, Ard Biesheuvel wrote: > On 17 August 2015 at 21:16, David Woodhouse <dw...@infradead.org> wrote: > >> On 2015-08-17 11:25:41, David Woodhouse wrote: > >>> On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote: > >>> > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? > >>> > >>> Not for testing LLP64, no. > >> > >> How/who is this helping? > > > > It was massively useful for testing the OpenSSL stuff I've been working on > > recently. It showed up a number of issues which would otherwise only occur > > a Windows build. > > Indeed. I don't use Windows or have access to any MS toolchains, so > this is basically the only way to make sure my code is LLP64 clean.
Maybe instead of tools_def.deprecated, we could add a tools_def.unsupported. Then we could put both deprecated, and unsupported toolchains in there. This might allow us to have less review/testing for changes to these toolchains. > >>> > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be > >>> > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part > >>> > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if > >>> > you count the comment in tools_def :) This is why I'd rather deprecate > >>> > it as a toolchain, and use the GCC4X toolchains instead. > >>> > >>> Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage > >>> is lost. > >> > >> Maybe MINGW49. But, please not before we figure out how to actually > >> deprecate toolchains. :) > > Why *must* we have the version encoded into the name? For GCC4x, the > differences are so minor that it is just maintenance overhead imo. I Adding GCC49 with some new switches is a lot easier than going back and verifying that the new switch doesn't break on GCC 4.4. Although it might have looked pretty gross in tools_def, I don't think there was much maintainance overhead. > used CLANG35 instead of CLANG per your request, but I am definitely > not going to add CLANG36 CLANG37 etc unless there is a real need. Regarding GCC44-GCC49, I think we only added them as someone discovered a new switch was required. (Coupled with trying to avoid modifying the old toolchain.) Your 'unify' series definitely throws out the strategy of trying to not modify old toolchains. You appear to have done the extra work to show that it should be fine... -Jordan _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
