Keir, what are the exact issues that required this change? SLES9 being based on gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a requirement. Despite me certainly being able to compile newer gcc-s (I actually have these around all the time), the mere fact to remember to pass a CC= each time I want to build Xen is going to make this cumbersome. Hence I''d like to understand the underlying issue(s), see whether they apply to the 3.3.x versions we have in use (aside of SLES9 I also continue to have one 9.0 system around that I use for regular building and testing). Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/3/07 09:35, "Jan Beulich" <jbeulich@novell.com> wrote:> what are the exact issues that required this change? SLES9 being based on > gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a > requirement. Despite me certainly being able to compile newer gcc-s (I > actually have these around all the time), the mere fact to remember to pass > a CC= each time I want to build Xen is going to make this cumbersome. > > Hence I''d like to understand the underlying issue(s), see whether they apply > to the 3.3.x versions we have in use (aside of SLES9 I also continue to have > one 9.0 system around that I use for regular building and testing).It''s fine to build Xenolinux with older gcc versions. The new constraint is just for the hypervisor itself, plus the toolstack. The issue is that all gcc 3.3.x miscompile alignment attributes hidden inside typedefs, which we were having to work around. It''s not a big issue (the workaround in this case is small), but gcc 3.4.0 has been available now for three years, and I wouldn''t recommend anyone to run a distro as old as SLES9 as their dom0 anyway (I''m thinking particularly of the fact that we rely heavily on hotplug/udev, and I know there were issues with older versions of udev). Also, I like the defensive position of supporting a continually ''sliding-window'' of modern gcc''s to limit our exposure to compiler bugs (which are inevitably present in any gcc version and which complex code like Linux or Xen is bound to trip up on from time to time). I''m happy to consider falling back to support of gcc 3.3 if there''s a good reason. However I don''t think that not being able to build on a pretty old distro really counts. Upgrade. ;-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <keir@xensource.com> 19.03.07 10:51 >>> >On 19/3/07 09:35, "Jan Beulich" <jbeulich@novell.com> wrote: > >> what are the exact issues that required this change? SLES9 being based on >> gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a >> requirement. Despite me certainly being able to compile newer gcc-s (I >> actually have these around all the time), the mere fact to remember to pass >> a CC= each time I want to build Xen is going to make this cumbersome. >> >> Hence I''d like to understand the underlying issue(s), see whether they apply >> to the 3.3.x versions we have in use (aside of SLES9 I also continue to have >> one 9.0 system around that I use for regular building and testing). > >It''s fine to build Xenolinux with older gcc versions. The new constraint is >just for the hypervisor itself, plus the toolstack. The issue is that all >gcc 3.3.x miscompile alignment attributes hidden inside typedefs, which we >were having to work around. It''s not a big issue (the workaround in this >case is small), but gcc 3.4.0 has been available now for three years, and I >wouldn''t recommend anyone to run a distro as old as SLES9 as their dom0 >anyway...I just scanned the tree and couldn''t spot any such instance. Could you point me to one? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Jan Beulich" <jbeulich@novell.com> 19.03.07 13:36 >>> >>>> Keir Fraser <keir@xensource.com> 19.03.07 10:51 >>> >>On 19/3/07 09:35, "Jan Beulich" <jbeulich@novell.com> wrote: >> >>> what are the exact issues that required this change? SLES9 being based on >>> gcc 3.3.3 makes it pretty undesirable for me/us to have this kind of a >>> requirement. Despite me certainly being able to compile newer gcc-s (I >>> actually have these around all the time), the mere fact to remember to pass >>> a CC= each time I want to build Xen is going to make this cumbersome. >>> >>> Hence I''d like to understand the underlying issue(s), see whether they apply >>> to the 3.3.x versions we have in use (aside of SLES9 I also continue to have >>> one 9.0 system around that I use for regular building and testing). >> >>It''s fine to build Xenolinux with older gcc versions. The new constraint is >>just for the hypervisor itself, plus the toolstack. The issue is that all >>gcc 3.3.x miscompile alignment attributes hidden inside typedefs, which we >>were having to work around. It''s not a big issue (the workaround in this >>case is small), but gcc 3.4.0 has been available now for three years, and I >>wouldn''t recommend anyone to run a distro as old as SLES9 as their dom0 >>anyway... > >I just scanned the tree and couldn''t spot any such instance. Could you point >me to one?Okay, sorry, I found one - I had skipped the public headers, as I assumed you wouldn''t change those, forgetting about the few __XEN__/__XEN_TOOLS__ conditionals in there. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/3/07 12:44, "Jan Beulich" <jbeulich@novell.com> wrote:>> I just scanned the tree and couldn''t spot any such instance. Could you point >> me to one? > > Okay, sorry, I found one - I had skipped the public headers, as I assumed you > wouldn''t change those, forgetting about the few __XEN__/__XEN_TOOLS__ > conditionals in there.Like I said, its hardly an insurmountable obstacle to support of gcc 3.3.x. But in general requiring a modern gcc will avoid exposure to bugs specific to older gcc, avoid needing workarounds for bugs in older gcc, and allow us to use new gcc features without requiring consideration of older gcc. That''s my default position unless there''s a good reason to do otherwise. Given how much we depend on subtleties of gcc, I think this is the sane approach. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel