> On Oct 19, 2015, at 13:37, Jack Howarth <[email protected]> wrote: > > On Mon, Oct 19, 2015 at 3:41 PM, MacPorts <[email protected]> wrote: >> #49227: gcc5 @5.2.0: fix gcj >> ------------------------------------+---------------------- >> Reporter: howarth.at.macports@… | Owner: mww@… >> Type: defect | Status: new >> Priority: Normal | Milestone: >> Component: ports | Version: 2.3.4 >> Resolution: | Keywords: haspatch >> Port: gcc5 | >> ------------------------------------+---------------------- >> >> Comment (by jeremyhu@…): >> >> Replying to [comment:11 graziosi.angelo@…]: >>> Replying to [comment:10 jeremyhu@…]: >>>> graziosi.angelo, you don't understand potential fallout to compiler >> changes. >>>> >>>> At worst, the compiler produces bad code and anything that it compiled >> needs to be recompiled. We don't have a mechanism for triggering that, so >> we need to be extra careful taking toolchain changes. >>> >>> Exactly what happens at (almost) every new compiler release. Recently, >> MSYS2/MINGW64, for having adopted GCC-5.2, had to recompile *all* its >> packages, and a few didn't rebuilt any more and are out of distribution.. >> On OSX and friends, things are no better.. >> >> No, that's certainly not true. Some people may *choose* to recompile with >> newer compilers because they want to. That doesn't mean that the older >> compiled code was wrong. >> >> We are careful here because we don't want to release compilers that >> produce incorrect binaries. >> > > You do realize that the boehm-gc code is entirely limited to gcj > and its associated libraries.
Yes. > It is built as a convenience library > linked into those and isn't distributed independently as a library in > FSF gcc. Yes. > Also, we don't even really have a functional gcj currently > on darwin14 and early because gcj isn't being properly built and > doesn't create the ecj1 required for java source files. Yes. > Your current > gcj only works for precompiled classes which is pretty much useless. Yes. > It is rather unfortunate that FSF gcc never added java file > compilation tests to their libjava testsuite to capture that but > libjava development is pretty moribund. > Also this change is pretty much pre-authorized in the comment of.... > > * ALIGNMENT is the largest N, such that > * all pointer are guaranteed to be aligned on N byte boundaries. > * defining it to be 1 will always work, but perform poorly. > > in boehm-gc/include/private/gcconfig.h. You could set the alignment to > 1 if you wanted to be extra careful, but the fact that an alignment of > 2 produces a boehm-gc and gcj which produce no regression in their > testuites on both darwin13 and darwin15 is a pretty damn good > confirmation that the change is safe. I'd feel better just skipping the compilation of gcj and not shipping a broken compiler which upstream has stopped caring about to our users. > >> -- >> Ticket URL: <https://trac.macports.org/ticket/49227#comment:16> >> MacPorts <https://www.macports.org/> >> Ports system for OS X
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
