| Summary: | eclipse-sdk-3.0.0-r3 runs correctly with ibm-jdk but not with sun-j2sdk | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Curtis Campbell <curtisjamescampbell> |
| Component: | [OLD] Development | Assignee: | Karl Trygve Kalleberg (RETIRED) <karltk> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | blocker | CC: | axxo, s4t4n |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
the error log referenced by the error
Test program exhibiting the bug |
||
|
Description
Curtis Campbell
2004-08-23 03:46:17 UTC
Created attachment 38013 [details]
the error log referenced by the error
The sun j2sdk is extremely flakey, and due to licensing restrictions, I am not allowed to install it on my own machine to test. Handing this over to Thomas for closer inspection. Googling around I found out that there are other Gentoo users with this issue. Apparently, it is related to the fact that, when building the sun-j2sdk-1.4.2 from source, the ebuild appends a "-gentoo" to the java apps version (see 'java -version'), and eclipse doesn't like that. As a workaround, you can start eclipse anyway by following its own suggestion, i.e. disabling file locking. start it with "eclipse -vmargs -Dosgi.locking=none"... Note: this is also true is you run the precompiled version of eclipse (not the ebuild-generated one). Ah, I only tried the gtk flavour... can you provide links to that information? i do not believe that is the problem i have it working fine with locking using eclipse-3 -vmargs -Dosgi.locking=java.io using nio fails eclipse-3 -vmargs -Dosgi.locking=java.nio and using "none" works too offcourse Uh, you are right, passing '-vmargs -Dosgi.locking=java.io' works (and java.nio fails)... Given the questionable status of j2sdk in general, and its strange licensing restrictions, I don't see the value of spending our resources solving this particular problem when a semi-suitable workaround has been found. If you want to use the Sun JDK, try dev-java/sun-jdk. If you strongly disagree, reopen the bug with a good reason, and I'll certainly reconsider. The bug is not specific to Eclipse, but makes the FileChannel.tryLock method fail in general. The problem is that in the file FileChannelImpl.c (in the source archive j2sdk-1_4_2-src-scsl.zip), the fcntl Operation F_SETLK64 is called with an Argument of type struct flock. On x86 Linux, however (at least under my kernel version 2.6.8.1), the file /usr/include/asm/fcntl.h states that F_SETLK64 must be called with an argument of type struct flock64. Presumably the three #ifdef __linux__ blocks in the file apply only to older Linux kernel versions. Unfortunately I can not currently tell whether that means kernels before 2.4 or kernels before 2.6. (I suggest reopening this bug, because it does not apply just to Eclipse, and fixing it should no longer require much "spending our resources"). Created attachment 41015 [details]
Test program exhibiting the bug
I have successfully patched the bug and now realise that I cannot publish the
patch due to Sun's "community" source license. I suppose it is pointless then
to continue to work with the source code.
Well, if you cannot publish the patch directly, maybe you can send it upstream for inclusion... > Well, if you cannot publish the patch directly, maybe you can send it upstream for inclusion... I am trying to, but the best I have found so far is http://java.sun.com/developer/products/java2cs/ from where the relevant links all first ask one to accept the SCSL, then lead to a server error. Argh, you are right! I always suspected that the whole java infrastructure was badly broken anyway ;-P Well, I suggest we wait a few days and try again, then bug someone at java.sun.blabla to fix their bug reporting system so that we can bug them about the bug ;-) BTW, anybody tried the new j2se 5.0 to see wether is still has the issue? i bet there sources are for 1.4.2.0 (no new releases, as far as i can tell) and there binary is allready at 1.4.2.04 > BTW, anybody tried the new j2se 5.0 to see wether is still has the issue?
The *binaries* provided by Sun do not have the problem. Only the *sources* fail when compiled on a Linux system with headers that distinguish F_SETLK and F_SETLK64 (I have linux26-headers installed). Presumably the Sun binaries are compiled on a Linux system where F_SETLK64 is still aliased to F_SETLK, hence they call F_SETLK consistently and the bug does not occur.
So the most interesting release will be the J2SE 5.0 *sources*: first, to see whether they still have the bug, and second, to see whether Sun provides them under a less constricing license that offers a way to do something constructive with patches like mine. And the derelict state of Sun's "Community Source Developers Area" (latest "news" is from Feb. 2001) shows that a necessary condition is unrestricted communication about bugs and patches.
|
