gcc6: restore gcj

[barracuda156]

Description

@catap This may be useful for our work on JDK :)

P. S. I have added this patch, looks like it is relevant: e9f48ba

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 10.6
Xcode 3.2

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?
• checked your Portfile with port lint --nitpick?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[barracuda156]

It was thrown away from Macports gcc6 prematurely at some early version for no good reason (ppc version did not build, on x86 something did not work, and instead of fixing it was simply removed).
6.5.0 builds on PPC as-is, and gcj6 appears to be fully functional (example).

[kencu]

Oh, there was a very good reason it was dumped back then.

There were all kinds of assembler errors that were not resolved for months in the java subdirectory of gcc, which was preventing us from updating to gcc6.

And as java support was dumped from gcc in gcc7 anyway, we just disabled it seven long long years ago to get things moving along.

https://trac.macports.org/ticket/51388

gcc5 supplied gcj that was good enough to build pdftk, the only port we had that needed gcj anyway.

But if years and years have gone by, and someone finally fixed these assembler errors, and gcj now builds on all systems Tiger PPC -> wherever, then sure, no big deal to allow it again.

[barracuda156]

But if years and years have gone by, and someone finally fixed these assembler errors, and gcj now builds on all systems Tiger PPC -> wherever, then sure, no big deal to allow it again.

Well, that was 6.2.0. But anyway, point is we need gcj6 for IcedTea, which in turn can enable building OpenJDK 8, which is otherwise broken (builds with some extra fixes up to AWT libs and then crashes).

[barracuda156]

@kencu Maybe you could try the build on Intel? That would be helpful. (If you get time, of course, I remember you were busy recently.)

[catap]

An alternative road to have bootstrap JDK might be https://github.com/ikvmnet/ikvm which runs on mono and which seems declare PowerPC as supported architecture: https://www.mono-project.com/docs/about-mono/supported-platforms/powerpc/

@barracuda156 any chance that you have tried to run mono?

[barracuda156]

An alternative road to have bootstrap JDK might be https://github.com/ikvmnet/ikvm which runs on mono and which seems declare PowerPC as supported architecture: https://www.mono-project.com/docs/about-mono/supported-platforms/powerpc/

@barracuda156 any chance that you have tried to run mono?

@catap Do we have a port for mono? If yes, I can build and run tests.

P. S. If you have a suitable machine, could you try gcj6 on Intel?

[catap]

An alternative road to have bootstrap JDK might be https://github.com/ikvmnet/ikvm which runs on mono and which seems declare PowerPC as supported architecture: https://www.mono-project.com/docs/about-mono/supported-platforms/powerpc/
@barracuda156 any chance that you have tried to run mono?

@catap Do we have a port for mono? If yes, I can build and run tests.

https://ports.macports.org/port/mono/details/

P. S. If you have a suitable machine, could you try gcj6 on Intel?

Ok, I'll try to build it.

[barracuda156]

An alternative road to have bootstrap JDK might be https://github.com/ikvmnet/ikvm which runs on mono and which seems declare PowerPC as supported architecture: https://www.mono-project.com/docs/about-mono/supported-platforms/powerpc/
@barracuda156 any chance that you have tried to run mono?

@catap Do we have a port for mono? If yes, I can build and run tests.

https://ports.macports.org/port/mono/details/

P. S. If you have a suitable machine, could you try gcj6 on Intel?

Ok, I'll try to build it.

@catap It is broken: https://trac.macports.org/ticket/61151
mono/mono#21649

[barracuda156]

@mascguy @kencu Should I make this into a variant instead? At least that should be uncontroversial.

[mascguy]

Rebased against master, as the CI logs have aged out. It will only build on macOS 10.10 and earlier anyway, but just to ensure all is well...

[mascguy]

Currently attempting to build port for Intel, on 10.5, 10.6, and 10.7.

[barracuda156]

@mascguy Thank you!

[mascguy]

For 10.5, libgcc6 failed with a fatal link error. But I'm building via a 64-bit 10.5 installation, so is that a supported config?

:info:build ld: illegal text-relocation to '___cpu_indicator_init' in cpuinfo_s.o from 'anon' in cpuinfo_s.o for architecture i386
:info:build collect2: error: ld returned 1 exit status
:info:build make[3]: *** [libgcc_s.dylib] Error 1

The 10.6 build for libgcc6 failed with a bootstrap verification error. But since we routinely disable that anyway, I'm not sure that's legitimate? @kencu?

:info:build Comparing stages 2 and 3
:info:build warning: gcc/cc1-checksum.o differs
:info:build warning: gcc/cc1plus-checksum.o differs
:info:build Bootstrap comparison failure!
:info:build gcc/alias.o differs
:info:build gcc/alloc-pool.o differs
[...]
:info:build libiberty/xatexit.o differs
:info:build libiberty/xmalloc.o differs
:info:build make[2]: *** [compare] Error 1

10.7 successfully built libgcc6, and is now onto gcc6. More encouraging to be sure, but I'll also need to sanity-test the various binaries too (assuming success).

Full build logs:

• 10.5 - libgcc6-10.5.log.gz
• 10.6 - libgcc6-10.6.log.gz

[mascguy]

10.7 successfully built libgcc6, and is now onto gcc6. More encouraging to be sure, but I'll also need to sanity-test the various binaries too (assuming success).

gcc6 also built successfully for 10.7. But still need to run some binary - and compilation - sanity checks, when I can carve out more time. Stay Tuned...

[barracuda156]

@mascguy

But I'm building via a 64-bit 10.5 installation, so is that a supported config?

I am not really sure. 64-bit is x86_64 here? Maybe @catap knows, I never ran Leopard on Intel at all.

The 10.6 build for libgcc6 failed with a bootstrap verification error. But since we routinely disable that anyway, I'm not sure that's legitimate?

I recall that is/was a very typical error with some gcc versions, and it was disabled in portfiles, at least for some systems. Not sure which exactly were those. Perhaps disable it for this port, either unconditionally or for < 10.7?

[mascguy]

Update: Builds were successful for 10.9 and 10.10 too.

Next up is 10.8, plus another try on 10.6 with bootstrap comparison disabled.

So far, so good...

[mascguy]

For 10.6, I disabled bootstrap comparison via the following logic:

# Need to disable bootstrap comparisons here as well
if { ${os.platform} eq "darwin" && ${os.major} < 11 } {
    configure.args-replace \
                    --with-build-config=bootstrap-debug \
                    --without-build-config
}

With that in place, libgcc6 and gcc6 built successfully for 10.6.

@kencu and @catap, can you folks confirm whether my solution is correct/complete?

[catap]

@mascguy as far as I recall you simple skip bootstrapping comparison.

[mascguy]

The 10.8 builds for libgcc6/gcc6 were successful, too. So that covers 10.6 through 10.10.

Also, the change to disable bootstrap comparison for 10.6 and earlier, was added via a separate commit.

Now that all of that is done, I need to sanity-test the binaries. Will try to tackle that over the next few days.

[mascguy]

Now that all of that is done, I need to sanity-test the binaries. Will try to tackle that over the next few days.

Testing of gcj on 10.6 and 10.10, results in the following.

First off, the Java test class. As simple as can be:

public class TestApp {
  public static void main(String[] args) {
    System.out.println("Hello");
  }
}

Verifying that all is well with that class, and that it runs as expected:

$ javac -source 1.5 -target 1.5 TestApp.java
$ java TestApp
Hello

Now the gcj compilation test:

$ gcj-mp-6 --main=TestApp TestApp.java
gcj-mp-6: error trying to exec 'ecj1': execvp: No such file or directory

And the gij run test, which should utilize the compiled .class file created earlier via javac:

$ gij-mp-6 TestApp
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: ___cxa_throw_bad_array_new_length
  Referenced from: /opt/local/lib/gcc6/libgcj.17.dylib
  Expected in: flat namespace
 in /opt/local/lib/gcc6/libgcj.17.dylib
Trace/BPT trap

Haven't dug into it more than that, though.

Are there some required environment variables that need to be set, before using these tools? Or do we simply have more work to do on this port?

[barracuda156]

@catap Could you take a look? Can be checked on Intel, there is nothing PPC-specific here. To make IcedTea jdk build we need this to work to begin with.

@iains Iain, gcj in the latest gcc6 was supposed to be working, at least on the basic level, right?

[iains]

@catap Could you take a look? Can be checked on Intel, there is nothing PPC-specific here. To make IcedTea jdk build we need this to work to begin with.

@iains Iain, gcj in the latest gcc6 was supposed to be working, at least on the basic level, right?

• For 32b hosts I believe so but ..
  -- in order to get proper operation on darwin9/10 you would need to back port the unwinder fix.
• Darwin10 libjava (AFAIK) needed to the __darwin10_Unwind_FindEnclosingFunction which is still supplied as a CRT for versions that need it on newer darwin. That fix to libjava should be restricted to Darwin10 (hopefully the patch that does this is already in macports).
• 64b Darwin was never working completely convincingly (TBH it is better on GCC-5 than 6) - there was some bug in the GC code that means a hack to the GC was needed (which looks like it is altering alignment, but actually ends up disabling some of the GC functionality).
  -- (a couple of years ago) I made an attempt to see if I could fix that bug and / or use a separate / newer gc version; but I did not get to the bottom of the problem.

Note that there is someone with an objective to re-integrate Java with GCC - but that is a slowly moving (maybe stalled) project too.

TBH, if the use-case is bootstrapping a couple of Java tools - you might well find much less work by sticking with GCC-5 (of course, it would be nice to make everything work - but ENOMORETIME).

[cooljeanius]

Note that there is someone with an objective to re-integrate Java with GCC - but that is a slowly moving (maybe stalled) project too.

I think that was @Zopolis4? See: https://github.com/Zopolis4/gcj

[barracuda156]

@cooljeanius Yes, exactly. I am not sure of the current state of things there though. (It would certainly be nice to have it reintegrated and drop ugly openjdk dependencies.)

[catap]

drop ugly openjdk dependencies

I doubt that it's going to happen one day. It is something like JDK 1.4 or 1.5 which quite outdated with comparing with JDK 21.

It requires a lot of work to support JDK 1.8 with all changes inside javalib, and they can't use Apache Harmony because it isn't under GPL.

For example scala.js and scala-native uses Apache Harmony as base line and used a lot of undergraduates (phd?) in EPFL to migrate tons of .java to .scala by reading the base line.

So, they should stay with OpenJDK :)

And to support modern OpenJDK's javalib someone should implement things starting from generic and goes to stream, lambda and tons of different things.

Really tons of.

[barracuda156]

@catap We should either fix building openjdk8 then with openjdk7 or find some alternative: pretty much everything needs at least openjdk8, and what we got on PowerPC (not sure about i386) is openjdk7…

[iains]

drop ugly openjdk dependencies

I doubt that it's going to happen one day. It is something like JDK 1.4 or 1.5 which quite outdated with comparing with JDK 21.

Agreed - the GCC Java implementation (as it is) is a possible mechanism to bootstrap a more modern one - probably via an intermediate step on Darwin9.

It requires a lot of work to support JDK 1.8 with all changes inside javalib, and they can't use Apache Harmony because it isn't under GPL.

There are library imports in GCC that are not under GPL, so long as the license is compatible and the steering committee agrees to the import. So this is not necessarily a "never can do".

And to support modern OpenJDK's javalib someone should implement things starting from generic and goes to stream, lambda and tons of different things.

Really tons of.

Yeah, unless a miracle occurs and we suddenly gain 10 full-time compiler engineers who want to work on legacy support, the best we can hope for is a bootstrap implementation of something in the region of 1.4..1.6.

[Zopolis4]

Note that there is someone with an objective to re-integrate Java with GCC - but that is a slowly moving (maybe stalled) project too.

I think that was @Zopolis4? See: https://github.com/Zopolis4/gcj

That's me!

That project is on hold at the moment, but I do intend to return to it at some point in the future.

[barracuda156]

@Zopolis4 Could you sum up for us what is its state at the moment? (Iain may be aware, others are likely not.)
Like, what is supposed to work at the moment (even if untested) and what are the major issues that require fix-up, in your opinion.

[Zopolis4]

Right now, it's ~8 months out of sync with the gcc tree.

It builds successfully, at least the main compiler executable does, but none of the compiled java programs work. It seems like there's only a couple relatively minor issues preventing it from compiling basic executables successfully.

Once all of that is resolved, it'll still be in the same shape it was when it was removed: partial support up to Java 1.6 with a incomplete JDK implementation.

[iains]

I made some hacks (on that 8 month old version) that got further with building and starting - but the VM still does not start so we do not get too far. It's (as with all this) a question of time and priorities....

[Zopolis4]

Honestly, I think it might be better just to start from scratch.

[cooljeanius]

Honestly, I think it might be better just to start from scratch.

From scratch, as in, from current GCC, or from the last commit to GCC that still contained Java? The latter was r7-3447-g37b204de605563, for reference: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=37b204de605563e7932e26099d28ea8c86cb1935
(although it took several further commits made after that to fully delete it)

Edit: might as well list all (or at least some) of the relevant commits here:

• r7-3448-geae993948bae8b: libjava removal, part 1
• r7-3449-g07b78716af6a9d: libjava removal, part 2
• r7-3450-gaf2d4873785d26: Maintainers step down, part 1
• r7-3452-gd1a79a95af9580: Maintainers step down, part 2
• r7-3459-g012447ea171dfb: Cleanup of libgcj bits from configury, part 1
• r7-4555-g84c1b9d3d4d1ea: Cleanup of libgcj bits from configury, part 2
• r7-4561-g8e4d2ca469ec10: Cleanup of libgcj bits from Makefiles
• r9-5555-gad81a900fba082: Removal of gcj bits from zlib subdirectory
• r7-2633-gf5ea1d3878b0fb: last commit to mention libjava before its removal

[Zopolis4]

As in, to implement a new Java compiler from the ground up in current GCC, rather than trying to make the old one work and then improving it.

[cooljeanius]

As in, to implement a new Java compiler from the ground up in current GCC, rather than trying to make the old one work and then improving it.

Hm. Well, I'd kind of prefer the latter myself, personally, but if someone wants to try the former instead, well, I guess that's fine, too...

[iains]

As in, to implement a new Java compiler from the ground up in current GCC, rather than trying to make the old one work and then improving it.

As an expert in having almost-unattainable goals .. I'd say that is quite an undertaking.

The old one was never a Java (Front End) compiler - it was a Java byte-code compiler and, more importantly, a VM that could be built with that byte-code compiler. The actual Java FE compiler was then the "ecj.tar" that could be hosted on the VM built from the .class files ....

A more modern byte-code compiler capable of building a more modern VM which, in turn, could host a more modern Java Front end would be the equivalent (although a pure Java Source FE would be cool , we'd still need to be able to generate byte code - and there are existing FEs out there, it's a question of effort, of course).

it would be cleaner possibly, but considerably more work.

reworking the old compiler does have the merit that we know it used to work ....

[Zopolis4]

I'm talking about implementing a new Java frontend compiler, rather than the previous setup of a bytecode compiler, VM and JDK implementation.

[iains]

I'm talking about implementing a new Java frontend compiler, rather than the previous setup of a bytecode compiler, VM and JDK implementation.

So the idea there would be to be able to compile a suitable VM / JDK directly from Java source (and not expecting to use the GNU class path)?

(although it remains that the byte-code intermediate would still be a required output, so that starting by reimplementing the byte-code compiler could still be a good first step).

[catap]

So the idea there would be to be able to compile a suitable VM / JDK directly from Java source (and not expecting to use the GNU class path)?

I think the similar idea is testing right now by GraalVM project and it team has dozen (or two?) full-time employe who are working on it for last couple of years.

And they haven't archived their goal (yet?) for 5 year of work.

[cooljeanius]

aw man... :-(

[barracuda156]

@cooljeanius I will keep the branch, you could borrow the code if there is interest to work on this.

[iains]

I have working 8.5, 10.5 and 11.4 branches based partially on @Zopolis4 's work, partially upon a revised forward-port and partially upon reworked in-tree use of bdwgc (I need to complete the testing for the merge with the Darwin back ports). Hopefully those branches will be available in a week or two. More work is need to bring them forward to trunk and currently they do not work on Sonoma at least (there seems to be some issue with the libffi Java integration there).

[iains]

I also fixed a handful of bugs on the 6.5 branch and that can be made to work on 64b Darwin with the in-tree use of an updated bdwgc.

https://github.com/iains/gcc-6-branch/tree/gcc-6-5-0-java

https://github.com/iains/bdwgc (needs to be checked out at the top source level for gcc).

https://github.com/iains/gcc-6-branch (experimental cobination - )

[catap]

https://github.com/iains/bdwgc (needs to be checked out at the top source level for gcc).

FYI:

• gctest fail: KERN_PROTECTION_FAILURE while world is stopped (OSX) ivmai/bdwgc#178
• Crash on building ECL on macOS 10.5 i386 with modern Clang ivmai/bdwgc#569 (comment)

Both related to Darwin and maybe you have some ideas / advice?