summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--user/jkoenig/java.mdwn30
1 files changed, 25 insertions, 5 deletions
diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn
index fcd316b7..af2b908e 100644
--- a/user/jkoenig/java.mdwn
+++ b/user/jkoenig/java.mdwn
@@ -60,6 +60,12 @@ I have modified libc0.3 to include a `deb-symbols(5)` file
so that we get an accurate libc dependency in `hurd` and other packages
when the symbols in question are pulled in.
+[[hurd/libthreads]] (cthreads library) will not be changed. There's no reason
+why its behavior should change, whereas for [[libpthread]] it's needed for
+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).
+
Another issue which came up with OpenJDK is the expansion
by the dynamic linker of `$ORIGIN` in the `RPATH` header,
see below.
@@ -77,8 +83,8 @@ and new ones will be added on top of it.
* Test patches: in progress, [[jkoenig]], Svante. More volunteers welcome,
of course.
- * If [[jkoenig]] thinks it's mature enough: should ask Samuel to test this
- (that is, only the refactoring patches for starters?) on the buildds.
+ * If [[jkoenig]] thinks it's mature enough: should ask
+ [[Samuel|samuelthibault]] to test these patches on the buildds.
* Get patches reviewed (Roland?), and integrated into official sources: [!]
[[tschwinge]].
@@ -87,11 +93,12 @@ and new ones will be added on top of it.
moved either into the appropriate glibc or Hurd documentation
files/reference manuals, or to [[glibc/signal]].
- * libthreads (cthreads) integration.
+ * `SA_SIGINFO` patche is based on [[Samuel|samuelthibault]]'s earlier work.
+ Thus, have him review the new patch?
- * [[tschwinge]] suggests to leave them as-is?
+ * Perhaps have a look at `SA_NOCLDWAIT`.
- * [[libpthread]] integration.
+ * Which numeric values to use for `SA_SIGINFO` (and `SA_NOCLDWAIT`)?
### Port OpenJDK
@@ -105,6 +112,11 @@ should not be too hard.
If that fails we can fall back on Shark
(a portable alternative JIT which uses LLVM).
+Complexity of porting HotSpot: probably low. The complex things should be
+arch- rather than OS-specific. Not many Linux-specific interfaces used.
+Garbage collection/memory management, etc. and/or most of other Linux-specific
+interfaces are already dealt with for the zero build.
+
The dynamic linker issue is as follows.
An executable-specific search path can be provided in the ELF RPATH header.
RPATH directories can include the special string `$ORIGIN`,
@@ -127,11 +139,19 @@ by building on [[pochu]]'s `file_exec_file_name()` patches.
I have succeeded in building a Hotspot-enabled `libjvm.so`,
although the current toolchain issues
+(*Hurd OS ABI*)
have so far prevented me from testing it.
##### Open Items
+ * [!] [[tschwinge]] to have a look at [[pochu]]'s `file_exec_file_name()`
+ patches (2010-05), whether it's generally the right idea.
+
+ * Assuming it is, continue with getting `$ORIGIN` working.
+
+ * [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]: *Hurd OS ABI*.
+
* 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?