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

[Yale Zhang <yzhang1985@gmail.com>]

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.

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


So, what changes did you want to make to GCJ?


On Sun, Dec 24, 2017 at 7:33 PM, R0b0t1 <r030t1@gmail.com> wrote:
> On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang <yzhang1985@gmail.com> 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