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

[MacPorts]

#49227: gcc5 @5.2.0: fix gcj
------------------------------------+------------------------
  Reporter:  howarth.at.macports@…  |      Owner:  ryandesign
      Type:  defect                 |     Status:  accepted
  Priority:  Normal                 |  Milestone:
 Component:  ports                  |    Version:  2.3.4
Resolution:                         |   Keywords:  haspatch
      Port:  gcc5                   |
------------------------------------+------------------------
Changes (by ryandesign):

 * cc: ryandesign (removed)
 * owner:  macports-tickets@… => ryandesign
 * status:  assigned => accepted


Comment:

 Replying to [comment:18 ryandesign]:
 > To explain why we have not committed this yet: MacPorts does not want to
 be in the business of forever maintaining patches to other people's
 software. Therefore, what we usually want is for patches to be submitted
 to the developers of the software. If they accept it, then we can update
 the MacPorts port to the fixed version, or apply the patch until they
 release a fixed version. If they do not accept the patch, then we would
 want to understand why they rejected it, and consider whether that is
 grounds for rejecting it in MacPorts as well.
 >
 > If the developers no longer exist or do not care about the software
 enough to comment on the proposed changes, then that leaves us with having
 to evaluate the patches ourselves and making a decision. I am not an
 expert on the inner workings of the GCC package and am not sure I'm
 qualified to evaluate the correctness of your changes.

 I think we should commit this after all. I would like to have a working
 pdftk in MacPorts on current macOS. The developer of pdftk has not
 responded to my inquiries into a way to build pdftk without gcj, so for
 now, gcj is required.

 I still don't know much about the internals of gcc, but I feel OK about
 committing this small change, since it only changes alignment, and from
 what I understand about alignment, such a change should only affect
 performance, not correctness. So this will be a bit slower than ideal, but
 it should work, as opposed to the current situation, where the only gcj we
 have available (in gcc45/gcc47) does not work on El Capitan or later. If
 we restrict the patch only to where it's needed—on El Capitan and later,
 as the current proposal does—that will ensure that Yosemite and older
 still get full performance.

 I had also been concerned that this change might affect, either in
 correctness or performance, aspects of gcc outside of gcj. But it seems
 the file being patched here, part of boehmgc, is only used for gcj, so it
 won't affect other parts of gcc. When gcj was removed from gcc in gcc7,
 the bundled copy of boehmgc was removed as well, so the patch is not
 something we'll have to maintain for new versions of gcc.

 I had also wondered if this was still a bug in current boehmgc, since we
 have a standalone port for that. There's an
 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 upstream gcc bug
 report] with much more discussion from Jack and others. It seems boehmgc
 fixed the problem a different way in an alpha version of boehmgc 7.2. (The
 version bundled with gcc5 is much older.) But the
 [https://github.com/ivmai/bdwgc/commit/faef04e7cb3741163dfdf65900ef5d2a0530be0f
 boehmgc commit] Jack identified as possibly fixing the problem the "right"
 way is much larger, touching hundreds of lines, which I don't think I
 would dare to try to backport to the bundled copy in gcc, since the
 developers of gcc, who would be much more competent to do so, apparently
 didn't feel up to attempting that or updating to a newer boehmgc. But this
 answers my concern about whether we need a similar patch in the boehmgc
 port: we don't.

 I still acknowledge [comment:10 Jeremy's concern] that if the patch ends
 making a compiler that produces incorrect code, we have to rebuild
 everything that might have used the incorrect compiler. Even if that ends
 up being the case, it shouldn't be a problem to revbump affected ports,
 since the number of ports that use gcj can probably be counted on one
 hand.

 The patch here doesn't add gcj support in the [comment:18 same way] that
 is already present in the gcc47 and gcc45 ports. (For example,
 master_sites tags for the gcc source are missing.) I'll correct this
 before committing.

 After committing this, hopefully we can do the same for gcc6, and maybe
 gcc49 and earlier as well. I tried backporting the patch to gcc47, but so
 far I get a build failure. We can look into that later if we feel like it.
 Or we could just turn off gcj on gcc49 and earlier on El Capitan and
 later, since gcc5 and gcc6 will be available.

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