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

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.

> "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.

>
> 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.

>
> On Sun, Dec 24, 2017 at 7:33 PM, R0b0t1 <[email protected]> wrote:
>> On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang <[email protected]> wrote:
>>> Greetings. I have a patch that allows GNU java to target MingW64
>>> (host=GNU/Linux only). Are you guys still taking patches now that Java
>>> has been removed from GCC 7? Or would it be more appropriate to host
>>> it on my own website or instructables.com?
>>>
>>
>> My questions in a similar vein led to the suggestion to use the last
>> version that supported GCJ. Development on this version has stopped.
>>
>> On the other hand, I am interested in your work, and know of at least
>> a few people who would be; hosting it publicly would be a good idea.
>> If GCC could accept the patches I suspect it would be beneficial, but
>> the people to review your contributions may no longer exist.
>>
>>> I also have another patch that cuts all the GUI, cryptography, and non
>>> UTF8/16 charset support from libgcj. This reduces the size of
>>> statically linked EXEs a lot (~27MiB to 4.5 MiB for a hello world
>>> program). This is important for a legacy utility that other developers
>>> use on Windows and who don't want to install a Java runtime.
>>>
>>> Commenting out and deleting code is a crude way to do, I know. Should
>>> use conditional compilation and even explore what's causing GUI code
>>> to be dragged into a hello world program. Maybe dead code removal
>>> isn't working (need to compile with -ffunction-sections and
>>> --gc-sections?)
>>>
>>
>> Do your changes make it impossible to use the functionality you cut
>> out? It is not really my place to say, but to me, that would be
>> unsuitable for inclusion in GCC proper.
>>
>> I shouldn't guess, but it seems to me like the default classpath may
>> just be copied into the executable. Optimization passes may not be run
>> on it.
>>
>> Cheers,
>>      R0b0t1