From: R0b0t1 <r030t1@gmail.com>
To: Yale Zhang <yzhang1985@gmail.com>
Cc: java@gcc.gnu.org
Subject: Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj
Date: Mon, 25 Dec 2017 00:33:00 -0000 [thread overview]
Message-ID: <CAAD4mYiQ5Rs+Xw6LtrnzrLWeESaCRCCAbYpyFVsJRiGLHXFZYw@mail.gmail.com> (raw)
In-Reply-To: <CALQF7ZxMGdFEYLfknXJRavDYEKWDxuYwcrX51EjAS7NooJvvRg@mail.gmail.com>
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
next prev parent reply other threads:[~2017-12-25 0:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-24 19:44 Yale Zhang
2017-12-25 0:33 ` R0b0t1 [this message]
2017-12-25 4:58 ` Yale Zhang
2017-12-27 3:00 ` R0b0t1
2018-01-01 3:42 ` Andrew Hughes
2018-01-01 9:00 ` Andrew Haley
2018-01-01 10:38 ` Brian Jones
2018-01-01 21:03 ` Yale Zhang
2018-01-02 9:58 ` Andrew Haley
2018-01-02 10:00 ` Andrew Haley
2018-01-02 10:04 ` Ricardo Wurmus
2017-12-24 19:46 Yale Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAD4mYiQ5Rs+Xw6LtrnzrLWeESaCRCCAbYpyFVsJRiGLHXFZYw@mail.gmail.com \
--to=r030t1@gmail.com \
--cc=java@gcc.gnu.org \
--cc=yzhang1985@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).