openjdk/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp has an error on line 38 that stops the build.
Attached with this e-mail is a patch that needs to be applied when building on SPARC platforms.
Created attachment 253605 [details, diff]
The best is to send this to icedtea upstream.
@Andrew: Would like to have this patch incorporated?
Has this progressed any further? I tried to patch this using an adapted icedtea ebuild but discovered the build process actually unpacks the openjdk tarball and patches it with its own patches. I think that this patch needs to go into their set of patches so it can build on SPARC. I can't emerge this package without it failing without this vital patch.
Is there some other way I can patch openjdk without having to go through upstream?
Any difference with dev-java/icedtea-18.104.22.168 ? Then we could finally keyword it.
The correct bootstrap order using should be (to avoid unfortunate circular dependencies):
enable gcj flag for sys-devel/gcc
emerge -1 dev-java/gcj-jdk =virtual/jdk-1.5
emerge --onlydeps icedtea
A few dev-java packages will have to get ~sparc keyword in the process.
Can anyone from sparc team try it?
I'll try it - this was my bug report :)
done dev-java/java-config-2.1.11 (but not -r1 -r2)
i have problems with
dev-java/ecj-gcj-3.5.2-r2 doesn't build
app-admin/eselect-ecj-0.6 (RDEPEND.bad dev-java/ecj-gcj)
(In reply to comment #6)
> dev-java/ecj-gcj-3.5.2-r2 doesn't build
Yeah, the bootstrap generates a lot of warnings, presumably because gcj is thinking it is 1.4 not 1.5/1.6. Have you failed a bug report about it?
I just succeeded in getting ecj-gcj installed. But there appears to be problems with running my test collection of java programs, mostly to do with not being able to find the AWT toolkit. Running simple console only java programs appears to work.
Need to find out why it's not able to find the AWT toolkit, and it should work.
I just figured it out - ecj-gcj is only a subset of the ecj compiler, it's just a bootstrap to allow it to build icedtea. Testing with icedtea-22.214.171.124 now.
Sadly, upstream has still not patched the error:
/var/tmp/portage/dev-java/icedtea-126.96.36.199/work/icedtea6-1.9.2/openjdk-ecj/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp: In function 'bool detect_niagara()':
/var/tmp/portage/dev-java/icedtea-188.8.131.52/work/icedtea6-1.9.2/openjdk-ecj/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp:38: error: format '%100[^
' expects type 'char*', but argument 3 has type 'char (*)'
Of course, if I edit the offending line of code and carry on with the build, it should work as expected, upstream really needs prodding to add the fix.
I've finally sent the one-liner patch to joe.darcy at Oracle to get it into the OpenJDK for the next release. Hopefully that should sort it out.
On first build, had to add the one-line patch, then re-run with FEATURE="keepwork", finally got it installed.
Tested with Vuze and some of my GUI java classes, appears to work well.
I can confirm that using gcj and ecj-jdk will bootstrap this build, really needs the one-liner patch to go in.
(In reply to comment #11)
> Sadly, upstream has still not patched the error:
> Of course, if I edit the offending line of code and carry on with the build, it
> should work as expected, upstream really needs prodding to add the fix.
I just wonder how such error could go unnoticed until now ?
(In reply to comment #13)
> I can confirm that using gcj and ecj-jdk will bootstrap this build, really
> needs the one-liner patch to go in.
To be sure, to build with gcj-jdk, there must be no version of icedtea6 or icedtea6-bin already installed, otherwise those will be used. The build should echo an einfo about what is used before unpacking. To avoid uninstalling icedtea6/bin just to test it, one can use the override variable: JAVA_PKG_FORCE_VM=gcj-jdk emerge ...
Created attachment 255861 [details, diff]
saves as files/icedtea-sparc.patch
Created attachment 255863 [details, diff]
patch the ebuild with this patch
Can you test that this (together with previous) attachment works?
Also mailing oracle people probably won't help as the code that needs to be fixed is added by an icedtea patch. So we need to fix it in icedtea, not openjdk.
Andrew: can you check?
Alex, sorry I've only just seen this issue.
The patch you're patching (patches/icedtea-sparc.patch) hasn't been applied for a long time. It should have been removed. So I don't see why changing it has any affect whatsoever.
Can you post something that's actually against the OpenJDK tree?
That patch I gave needs to be applied against the OpenJDK tree, it can't be patched with our ebuild as the Icedtea framework unpacks OpenJDK sources and does the patching itself. That was why I was hoping to get it fixed upstream.
I'll personally unpack the OpenJDK sources and generate a patch. It's pretty easy to do, so I will get this sorted now.
Created attachment 255873 [details, diff]
OpenJDK 6 patch that fixes compilation error
This patch was generated against the OpenJDK tree itself.
(In reply to comment #18)
> The patch you're patching (patches/icedtea-sparc.patch) hasn't been applied for
> a long time. It should have been removed. So I don't see why changing it has
> any affect whatsoever.
Sorry that was my fault.
Intuitively, this patch seems odd to me as &cpu should be the same as &cpu if my knowledge of C and C++ serves me correctly.
I went to check this:
$ cat test.cpp
printf("%p, %p\n", &cpu, &cpu);
$ g++ -g -Wall -o testapp test.cpp
$ file testapp
testapp: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
$ g++ -g -Wall -o testapp2 test.cpp
$ file testapp2
testapp2: ELF 64-bit MSB executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
So I'm baffled by your patch. What failure occurs without it?
I refer you to comment #11, that shows the error that the patch fixes.
That still doesn't explain why this fixes it to me.
Without this patch, IcedTea6 has been built on sparc for Fedora, Debian and Ubuntu. What is different in your case?
I think it might be down to the stricter QA controls in the ebuild. I think that problem normally results in a warning but this time it got flagged as an error which can stop the build. Misuse of -Werror maybe? It would explain why it builds OK on other distributions, perhaps?
Hmmm... -Werror is present upstream so everyone gets that.
I'm tending towards putting it in, because it won't hurt anything (the two being the same thing). I would like to understand why this is an issue though.
Which gcc are you using? Maybe it is older than on most distros.
Using GCC 4.4.4, this is a stable SPARC gentoo box.
I added the patch to 1.9.3 in the overlay. Let me know if you need it applied to any other versions.
Still not sure about adding it upstream unless I can replicate the issue.
I'm happy to say that the latest icedtea 184.108.40.206 from the java overlay was successfully built on SPARC, using GNU gcj and ecj-gcj 3.5.2-r2. I'd particularly like to see this ebuild go into the portage tree soon for testing and perhaps going unstable. I have tested the JVM with some java programs that I wrote years ago and they seem to work. Does the icedtea ebuild provides a way to run tests on it?
I intend to unmask the netbeans ebuilds and test it with icedtea tomorrow morning.
At some point in the future I would like to get 64bit up and running - I am running a multilibbed profile on SPARC (like AMD64)
I can confirm that NetBeans 6.8-r1 and its ~114 dependencies, once unmasked, ran flawlessly. Testing with my old NetBean projects but all seems well.
The patch was added to main tree. Now the sparc arch team can test and add keywords. Please see the bootstrap instructions in comment 4.
If there is a problem with ecj-gcj (comment 6) we need more info.
First I unmerged and rebuilt icedtea6-1.9.3 from the main tree, seems to build OK and installed correctly. Should be OK for testing.
*** Bug 344221 has been marked as a duplicate of this bug. ***
(In reply to comment #6)
> done dev-java/java-config-wrapper-0.16
> done dev-java/java-config-2.1.11 (but not -r1 -r2)
Why not the latest? This is not sustainable.
> i have problems with
> dev-java/ecj-gcj-3.5.2-r2 doesn't build
Still waiting for some logs/info
This is upstreamed in 1.9.7: http://blog.fuseyism.com/index.php/2011/02/15/security-icedtea6-1710-187-and-197-released/
Confirmed, 220.127.116.11 builds just fine.
I can confirm that icedtea 18.104.22.168 builds just fine with GCC 4.4.5 on my sparc box.
I can't build icedtea 6.1.10* (with and without hs20) with GCC 4.4.5. But I can build icedtea 22.214.171.124 without hs20 (it fails with hs20) with icedtea 126.96.36.199.
I can provide build logs for all the mentioned cases.
It's time to give keywording icedtea:7 for sparc a try. Please test and add dependencies to this bug. Thanks.
Reopen if you're still interested...i'm not interested in java
Marking this bug as FIXED.