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

[Jeremy Huddleston Sequoia]

> On Oct 19, 2015, at 13:37, Jack Howarth <howarth.at.macports at gmail.com> wrote:
> 
> 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20151019/e1b1bedb/attachment.p7s>