[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] tool stack tool chain dependencies (again)
On Thu, Jan 05, 2017 at 04:57:12AM -0700, Jan Beulich wrote: > >>> On 05.01.17 at 12:47, <wei.liu2@xxxxxxxxxx> wrote: > > On Fri, Dec 16, 2016 at 05:52:29AM -0700, Jan Beulich wrote: > >> Hello, > >> > >> especially some of the changes late in the 4.8 cycle have caused me > >> to spend a good part of the morning trying to figure out how to build > >> the tool stack on an older system. Among other things I've run into > >> - ipxe all of the sudden not working with make 3.80 anymore (despite > >> apparent attempts to do so in their Makefile) > >> - ipxe not working with gas prior to 2.18 anymore (requiring the > >> .reloc directive) > >> - rombios causing ld to segfault when building with debug=y (later > >> findings suggest this may be because overriding CC in ./.config > >> works, but doing so for e.g. AS and LD doesn't affect namely > >> the tools/firmware/ subtrees) > >> - -O0 causing fallout with an admittedly questionable sys/stat.h > >> None of this was a problem with an early October build. > >> > >> I think we really need two things here: One is that I think we should > >> bump our minimal required tool chain component versions, or > > > > +1. > > > >> alternatively have tools/configure properly disable sub-components > >> (taking into account overrides from ./.config) - I certainly could live > > > > If I'm not mistaken this requires we track tool chain requirements for > > all dependencies and their dependencies. This is going to be > > unmanageable. > > Well, that (I think) depends on whether those other projects > document their requirements. If things are properly spelled out, > it shouldn't be that hard. And if they aren't properly spelled out, > perhaps it would be worth a try asking them to do so. > Yes, we can try that. Which external components that you find break easily? We can start with those. > >> with qemu-trad being disabled on such old systems, but otoh > >> upstream qemu in the past has proven to not be much better, and > >> it would be of questionable use if both got disabled. The other is > >> that I think we should actually make sure things build with those > >> versions. > > > > Doug's work should help. > > Which parts are you thinking of? I'm not aware of anything that > has been done to test with specific tool chain component versions. > The Docker based CI part -- see his reply to your email. It would be easy to add different configurations there. That would help we catch regressions early and fix things properly. Wei. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |