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

Tue Jan 2 09:58:00 GMT 2018

On 01/01/18 21:03, Yale Zhang wrote:
> Alright, I've submitted my request & patch to bugzilla:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647
>> "Having said that, I'm quite happy to accept mingw patches if there is a
> live branch to apply them to."
> Under the target version, I saw a tentative 6.4.1, so there still could be
> hope this can make it into GCC 6.
>>> I also did the experiment of compiling libgcj with -ffunction-sections
> -fdata-sections and then use --gc-sections when linking to see if that
> helps remove dead code. Somehow, that instead increased the size of a
> simple test program (with multithreading & sockets) from 4.54 to 4.72 MiB.

I'm not surprised. All Java code is reachable from everywhere because
of reflection and class loaders. You can't simply use --gc-sections
because code called reflectively would fail at runtime.
> "I was hoping to keep GCJ up to date to use it for OpenJDK bootstrapping"
> That paranoid? Why not use the minimal Eclipse Java compiler which
> Classpath uses for bootstrapping? It sounds like ECJ can't be trusted if it
> was compiled with an untrusted/unknown compiler.

Indeed. If Programming Language X is written in X, you're going to
need the previous version of X to build it. It's so for C and for
Java. We have a string of versions of OpenJDK going back to Version
6, and that was compiled with GCJ. So, there's nothing to stop
someone from digging out OpenJDK 6, building that with an old GCJ, and
spooling forward to today.
-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671