Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

On 27 December 2017 at 03:00, R0b0t1 <[email protected]> wrote:
> On Sun, Dec 24, 2017 at 10:58 PM, Yale Zhang <[email protected]> wrote:
>> Hurray, this list is still alive!
>>
>> Here's what I plan to do. If I don't hear from any maintainers in the
>> next 2 weeks, I'll submit the MingW64 patch to the GCC Bugzilla. But
>> not much hope there because I already submitted a few other bugs
>> almost all still remain as "unconfirmed". So then I'll just post it on
>> my Google personal site or maybe write something on instructables.com.
>> Or maybe I already did enough by uploading to this list.
>>
>
> This sounds okay, but instructables is very niche. I would recommend
> putting your code on GitHub somehow. You can probably move faster than
> 2 weeks to submit it to the tracker - this list is very inactive.

I'll second the idea of GitHub.

I'm pretty sure most of the people still "exist" - no-one died as far
as I'm aware -
but they have indeed moved onto other pastures and are unlikely to want to
review patches. The reason GCJ was eventually deleted was because just keeping
it buildable with the rest of GCC was becoming an unnecessary burden.

It's probably worth noting that this isn't just any two weeks. For
many countries, this
is winter holiday season and, even when the project was heavily
active, I doubt you'd
have got a response on Christmas Eve / Christmas Day.

>
>> "Do your changes make it impossible to use the functionality you cut out?"
>>
>> Correct, I would not propose adding this to libjava as is. Most of the
>> bloat can't be removed by the compiler because it might be used or
>> even if it's never used, the compiler doesn't know any better.
>>
>> an example would be
>> UI:
>>
>> System()
>> {
>>    if (showVMConsole)
>>    {
>>       // show VM console GUI
>>    }
>> }
>> I haven't proven this but that's my guess how a simple hello world
>> program drags Swing into the EXE.
>>
>> As you suspected, there could be unused dead code that the linker
>> should remove. I haven't confirmed any cases. For dead code removal to
>> happen, I think it's necessary to compile with -ffunction-sections and
>> -fdata-sections and link with --gc-sections. I can check if they're on
>> and if not, how much additional space is saved by enabling them.
>>
>
> This is a question I think you should ask about on the general GCC
> list, as it receives more traffic. At least one past GCJ maintainer
> still comments.
>
> I think it is possible that libjava never sees optimization. I do not
> know enough about the internals of GCC to know for certain, but I can
> think of two reasons:
> 1) As a separate library, it is not possible to do dead code removal
> as it is not being compiled.
> 2) GCJ always includes the entire library.
>
> If it is #2, I think it is due to reasons like you outlined - the
> entire default classpath may be extremely interdependent. GCJ is still
> fairly incomplete.
>

I don't know much about the GCJ internals either, but I am still (technically)
the GNU Classpath maintainer, which is/was upstream of GCJ. There are
quite a number of options already that allow the scope of the library to be
limited. Are you making use of these?

>>
>> So, what changes did you want to make to GCJ?
>>
>
> I was hoping to keep GCJ up to date to use it for OpenJDK
> bootstrapping. It would keep the trusted codebase for FOSS systems
> smaller than it currently is.
>

This is pretty much my continued interest in it, but I'm tending
towards alternate
solutions than trying to maintain GCJ. See:

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2813
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222