FWIW, I have committed the last 4 or 5 patches with gcc v4.0.2-14.EL4. I did not have to install the compiler. It was part of redhat package. It was under /usr/bin/gccv4. All that was required was to hack on some softlinks.
On 11/3/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Basically, I want to uplift my own platform to 4.x, and then work the kinks out of that patch. I just want to know what X is. If no one says anything, I'll figure it out and declare it :) geir Gregory Shimansky wrote: > Egor Pasko wrote: >> On the 0x216 day of Apache Harmony Gregory Shimansky wrote: >>> Geir Magnusson Jr. wrote: >>>> did we ever bottom out on what range of GCC we'll support? >>>> I have a patch I want to commit that is known to not compile under >>>> 4.1.1... >>> Hmm no I don't remember such agreement. I think GCC is mostly >>> backwards compatible, and anything that compiles on 4.1.1 should >>> compile on previous versions. So it is better to support the latest >>> stable. >>> >>> Not many people would like to install such GCC version, but someone >>> like me could at least give warnings that the most recent version of >>> GCC doesn't compile some code. >> >> yes, and comment JIRA accordingly (with suggested fix). This way we >> can support a very wide renge of GCCs constantly. I doubt I can use >> the latest GCC soon, so I cannot check patches constantly. > > I think you could use 4.1.0 in Fedora Core 5. Since patch level > shouldn't really affect the C++ compilation restrictions, the same patch > should break on 4.1.0 as well. > >> Does it make sense to use something CruiseControl-ish that walks >> around JIRA patches and reports statistics which of them build OK? I >> thought of such a tool recently.. Not a task I would dream to >> implement though. > > It could be an overkill to check on all possible gcc versions on all > possible distributions and all possible platforms... When someone who > has some problematic platform/distribution/gcc lets us know that > something doesn't compile, it is probably enough. >
-- Weldon Washburn Intel Enterprise Solutions Software Division
