diff options
Diffstat (limited to 'user')
| -rw-r--r-- | user/jkoenig/java.mdwn | 187 | ||||
| -rw-r--r-- | user/jkoenig/java/java-access-bridge.mdwn | 14 |
2 files changed, 197 insertions, 4 deletions
diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn index 4ba7bace..e5d288cc 100644 --- a/user/jkoenig/java.mdwn +++ b/user/jkoenig/java.mdwn @@ -30,10 +30,6 @@ Feeling slightly behind schedule; but project is very ambitious, which has been known from the beginning, and there is great progress, so there is no problem. --[[tschwinge]], 2011-06-29. -[[tschwinge]] will be on vacations in China starting July 26th, will have -Internet access intermittently, but not regularely. We'll have to figure out -some scheme. - ### Apt repository @@ -83,6 +79,20 @@ conformance. Patches posted on 2011-05-25, but there's a more recent one in the modified hurd package (adds `_hurd_sigstate_delete` and removes the weak symbols). +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> the glibc patches are pending review and inclusion in Debian (I + think youpi wants to check my latest additions before we go ahead with + that) + < jkoenig> when it's in Debian and the sky does not fall, I intend to + resubmit a full series to libc-alpha for inclusion upstream. + +IRC, freenode, #hurd, 2011-08-24: + + < youpi> jkoenig: I'll probably commit your siginfo/globalsig patches soon + < youpi> I'm building the ant package atm, seems to proceed great + < jkoenig> youpi, great! + Another issue which came up with OpenJDK is the expansion by the dynamic linker of `$ORIGIN` in the `RPATH` header, see below. @@ -158,6 +168,23 @@ for broader testing. `si_pid_not_implemented`, to ensure compilation failures for programs which use them. Or perhaps a linker warning is possible. + IRC, freenode, #hurd, 2011-08-20: + + < youpi> jkoenig: I was considering renaming the fields of siginfo + < youpi> to catch applications which need those which we haven't + yet + < jkoenig> youpi, makes sense AFAICT + < youpi> one issue we'll get is some application which previously + built without SA_SIGINFO, and will now want some information + we're not yet able to provide + < youpi> but at least we'll know + < jkoenig> youpi, yes it would still be better than having them + crash at runtime because of it + + IRC, freenode, #hurd, 2011-08-21: + + < youpi> jkoenig: actually we need the fields for waitid + * The FPU state is not included in the `ucontext_t` passed to the signal handler. On the other hand, `ucontext_t` is actually being somewhat deprecated: the functions to restore it are no longer in POSIX. @@ -198,6 +225,111 @@ This can be worked around by defining the `LD_ORIGIN_PATH` environment variable. (which have I used to build and test OpenJDK so far.) +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> if you have the latest hurd/libc in my repository, you should be + able to run /usr/lib/jvm/java-7-openjdk/bin/java without defining + LD_ORIGIN_PATH manually + < braunr> java: error while loading shared libraries: libjli.so: cannot + open shared object file: No such file or directory + < jkoenig> braunr, this one is expected, it's the symlink problem. + < braunr> oh ok + < jkoenig> (ie. thus far, if java is accessed as /usr/bin/java, the ld + origin ends up as /usr/bin) + + < jkoenig> *sigh*... it seems I'm going to have to reimplement realpath() + in elf/dl-origin.c. + < braunr> why ? + < jkoenig> using it from there results in duplicate symbols when linking + elf/librtld.map.o + < braunr> from where ? + < braunr> dl-origin ? + < jkoenig> apparently this part of the code uses a different allocator + (elf/dl-minimal.c) + < braunr> oh + < braunr> depndency issues ? + < braunr> or bootstrapping ones ? + < jkoenig> http://paste.debian.net/124310/ + < jkoenig> dl-origin is what provides the $ORIGIN value for RPATH (now + sysdeps/mach/hurd/dl-origin.c, in our case) + < braunr> but what's the problem ? + < braunr> what prevents you from using the existing implementation ? + < jkoenig> you mean copy-and-paste the code ? Well I'll end up doing that I + guess... not that it feels right. + < braunr> not really + < braunr> link against what provides it + < braunr> i'm really not familiar with glibc :/ + < jkoenig> also I'd like to understand what's happening precisely before I + resort to such blasphemy :-) + < braunr> :) + < jkoenig> maybe I could make {file,exec,_hurd}_exec_file_name() + canonicalize it instead. + < jkoenig> for some reason it does not feel right, though. + < braunr> why ? + < jkoenig> I'm not sure, loss of information maybe? + < jkoenig> (that I ran /usr/bin/java as opposed to /usr/lib/jvm/...) + < braunr> i guess you should explain the issue more clearly, i feel like + there is something i'm really missing :/ + < braunr> but it can wait + < jkoenig> that ld.so actually needs the canonical file name to substitute + $ORIGIN is its own problem, not that of exec or _hurd_exec_file_name.. + < jkoenig> Ok, so.. Initially the shell (indirectly) runs + _hurd_exec_file_name(..., "/usr/bin/java", ...), which then calls + file_exec_file_name() on the file in question, passing it its own + filename + < jkoenig> which is transmitted to exec_exec_file_name() + < jkoenig> (until now it's all pochu's patch) + < jkoenig> which then makes it available to the newly created process + through exec_startup_get_info_2() (my own addition) + < braunr> oh + < braunr> wasn't it available before oO ? + < jkoenig> no, exec only has access to a port to the executable file. + < braunr> how was argv[0] handled then ? + < jkoenig> argv[0] is handled like any other argument + < braunr> ok, so the file path is duplicated ? + < jkoenig> the shell (or whomever calls _hurd_exec) provide whatever they + want. + < braunr> ok + < jkoenig> well argv[0] is not necessarily the file path (at least not the + full path) + < braunr> right + < jkoenig> so exec() does some guesswork with $PATH but obviously that's + limited. + < braunr> so what you changed is that get_info_2 now receives a canonical + path ? + < jkoenig> right + < jkoenig> (or whatever was specified to _hurd_exec_file_name(), for this + reason and others we shouldn't use it for setuid programs.) + < jkoenig> well, not a canonical path. A path. (hence the problem) + < braunr> ok + < jkoenig> now both the filesystem and exec might run under another root so + they're not an option for canonicalization + < jkoenig> _hurd_exec_file_name (in libc) might be a better spot. + < braunr> resolution from the client, yes + +IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> so my RPATH patches are polished and built, and I'll post them + soon, is the good news + +IRC, freenode, #hurd, 2011-08-17: + + < jkoenig> also fixed a fakeroot-induced deadlock in my dl-origin patches + (namely, under fakeroot, realpath() uses a socket (through stat), so we + need to use it when _hurd_dtable_lock is not held) + < jkoenig> also I'll post my dl-origin patches shortly + < youpi> dl-origin is about the environment variable that java needs, + right? + < jkoenig> about the environment variable it shouldn't need, yes :-) + < youpi> ah :) + < youpi> but ok, I vaguely remember what that refers to + < jkoenig> $LD_ORIGIN_PATH is used as an override (much like + LD_LIBRARY_PATH), but ideally ld.so uses whatever directory the loaded + binary is from. + < youpi> ok + < jkoenig> (as a substitution for $ORIGIN in RPATH) + + #### Plans I intend to fix the RPATH issue @@ -219,6 +351,27 @@ have so far prevented me from testing it. > > --[[jkoenig]] 2011-06-29 +IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> and I'm battleing to update my OpenJDK patches to b147, and + merge the with the kFreeBSD ones. + < braunr> b147 ? + < jkoenig> but that thing is seriously huge and touches about everything, + so it's taking more time than I'd have hoped + < jkoenig> braunr, the latest release of IcedTea / OpenJDK 7 and the + current Debian version (in experimental of course) + < braunr> ok + < jkoenig> I'm trying to make this clean so that hopefully we can get them + integrated at some level of upstream (probably IcedTea, at least at + first) + +IRC, freenode, #hurd, 2011-08-10: + + < jkoenig> well actually I've finished merging my patches with the freebsd + ones, and updating them to the new openjdk-7, + < jkoenig> but now a new version of both is out :-P + + ##### Upstream Submission On 2011-07-15, *gnu_andrew* talked to us in the #hurd channel (freenode IRC), @@ -239,6 +392,19 @@ than some huge patchset). Send patches to <distro-pkg-dev@openjdk.java.net>. * [[java-access-bridge]] (not critical; JVM appears to work without) + * IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> there's a bug with java.nio when running javadoc, you might + run into it. + + * [[`SCM_CREDENTIALS`|open_issues/sendmsg/scm_creds]] + + IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> wrt. peer credentials, openjdk also uses file modes for + security, and my guess is that it's sufficient, at least on Hurd, so + I've reduced my priority for this at least in the meantime + * They seem to have a rather heavy-weight process for such projects: confer <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>, for example. Do we need this, too? @@ -275,6 +441,19 @@ The code is at <http://github.com/jeremie-koenig/hurd-java>. Doxygen-generated documentation is available at <http://jk.fr.eu.org/hurd-java/doc/html/>; or run `make doc` yourself. +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> I need to be able to read/write individual data items from + messages, in order to implement deallocation correctly, so I'm working on + that when I'm waiting for things to build, but it's not my primary focus + right now. + +IRC, freenode, #hurd, 2011-08-17: + + < jkoenig> so, weekly status report: I have made some progress on the java + bindings, I hope to have a safe version mach_msg soon, after which I can + begin experimenting with mig. + #### Plans diff --git a/user/jkoenig/java/java-access-bridge.mdwn b/user/jkoenig/java/java-access-bridge.mdwn index 6f860709..57c87068 100644 --- a/user/jkoenig/java/java-access-bridge.mdwn +++ b/user/jkoenig/java/java-access-bridge.mdwn @@ -76,3 +76,17 @@ Trying to build it: make[1]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2' make: *** [debian/stamp-makefile-build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 + + +IRC, freenode, #hurd, 2011-08-10: + + < jkoenig> and with my latest fix (hardwire os.name as "Linux"), + java-access-bridge actually built \o/ + < youpi> I wouldn't call it a "fix" :) + < jkoenig> true, but pretty much everything assumes we're either solaris, + linux or windows :-/ + < jkoenig> also we're actually using the Linux code which it is used to + select throughout the JDK + < jkoenig> if it's any consolation, os.version stays "GNU-Mach + 1.3.99/Hurd-0.3" :-) + < youpi> ideally it should simply be changed to "GNU" |