[MacPorts] #49227: gcc5 @5.2.0: fix gcj

[Jack Howarth]

On Mon, Oct 19, 2015 at 3:41 PM, MacPorts <noreply at macports.org> 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.It is built as a convenience library
linked into those and isn't distributed independently as a library in
FSF gcc.  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. Your current
gcj only works for precompiled classes which is pretty much useless.
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.

> --
> Ticket URL: <https://trac.macports.org/ticket/49227#comment:16>
> MacPorts <https://www.macports.org/>
> Ports system for OS X