You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 1917-java-embed-rust-cli-runtime-remove-before-merge/20260723-prompts.md
+91-2Lines changed: 91 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,8 +38,6 @@ It must be a standalone Java program that produces an executable jar I can invok
38
38
39
39
### 18:22 Prompt
40
40
41
-
42
-
43
41
In this session, we are reducing the ignorance in the `copilot-sdk/1917-java-embed-rust-cli-runtime-remove-before-merge/1917-embed-cli-runtime-ignorance-reduction-plan.md` by working through the items in Section 3 for which we do not yet have a **Resolution:**. For starters, read and understand that whole document.
44
42
45
43
Today we start with ### 3.6 — Platform detection implementation
prints detected platform details by default; on this machine it logs `arch=arm64` and `classifier=darwin-arm64`.
154
+
155
+
### 18:37 Prompt
156
+
157
+
In this session, we are reducing the ignorance in the `copilot-sdk/1917-java-embed-rust-cli-runtime-remove-before-merge/1917-embed-cli-runtime-ignorance-reduction-plan.md` by working through the items in Section 3 for which we do not yet have a **Resolution:**. For starters, read and understand that whole document.
158
+
159
+
Today we start with ### 3.6 — Platform detection implementation
160
+
161
+
> **Question:** What is the exact implementation of platform detection, particularly the ELF PT_INTERP parsing for musl vs. glibc on Linux?
162
+
>
163
+
> ADR-007 specifies reading the first 2 KB of `/proc/self/exe` and parsing the ELF PT_INTERP segment. This is the same approach as the `detect-libc` npm package.
164
+
>
165
+
> **Open questions:**
166
+
>
167
+
> 1. Can we read `/proc/self/exe` from Java? (`/proc/self/exe` is a symlink to the JVM binary — on glibc Linux it will contain the glibc dynamic linker path, on Alpine/musl it will contain the musl path.)
168
+
> 2. Should the detector be in a standalone utility class (reusable) or inline in the loader?
169
+
> 3. Edge case: What about container environments where `/proc` is mounted but the JVM binary is from a different libc than the container's userspace? (This shouldn't happen in practice — the JVM must match the libc.)
170
+
>
171
+
> **Spike needed:** Write a Java snippet that parses ELF PT_INTERP from `/proc/self/exe` on a glibc Linux system and on Alpine. Verify the dynamic linker paths match expectations (`/lib64/ld-linux-x86-64.so.2` vs. `/lib/ld-musl-x86_64.so.1`).
172
+
>
173
+
> **Recommendation:** Standalone `PlatformDetector` class in `com.github.copilot.ffi` with methods `detectOs()`, `detectArch()`, `detectLinuxLibc()`, `detectClassifier()`. Pure Java, no dependencies. Unit-testable with mocked system properties and test ELF binaries.
174
+
175
+
Platform detection needs to work on all supported tuples specified in the Platform dimensions section of `copilot-sdk/java/docs/adr/adr-007-native-bundling-strategy.md`.
Let's start spiking with this one. Create the spike in `copilot-sdk/1917-java-embed-rust-cli-runtime-remove-before-merge/spike-3-6-platform-detection-linux-x64`.
185
+
186
+
It must be a standalone Java program that produces an executable jar I can invoke with `java -jar spike-3-6-platform-detection-linux-x64.jar` and when it runs it shows the detected arch. We need to detect enough information so that we can select the corresponding binary content contained in the classifier jar as shown in section 3.1 of `copilot-sdk/1917-java-embed-rust-cli-runtime-remove-before-merge/1917-embed-cli-runtime-ignorance-reduction-plan.md`. The spike program must use java.util.logging such that the output is printed by default.
187
+
188
+
Note that `copilot-sdk/1917-java-embed-rust-cli-runtime-remove-before-merge/spike-3-6-platform-detection-darwin-arm64` already exists and is the spike for `darwin-arm64`. That was built when running on that hardware.
189
+
190
+
You are now running on linux-x64 hardware.
191
+
192
+
Now, here is where all that ELF and `/proc/self/exe` stuff comes into play. Consider that for inclusion in your spike.
193
+
194
+
### 18:45 Response
195
+
196
+
Good, I have a clear picture of the darwin-arm64 spike. Now I'll create the linux-x64 version. The code is identical (it's the same `PlatformDetector` logic), just packaged for running on linux-x64. I'll create the directory structure, copy the source, build it, and run it.
The spike is working perfectly. All key findings confirmed:
215
+
216
+
Spike 3.6 results on linux-x64:
217
+
218
+
┌───────────────┬─────────────────────────────┐
219
+
│ Detection │ Result │
220
+
├───────────────┼─────────────────────────────┤
221
+
│ os │ linux │
222
+
├───────────────┼─────────────────────────────┤
223
+
│ arch │ x64 │
224
+
├───────────────┼─────────────────────────────┤
225
+
│ linuxLibc │ GLIBC │
226
+
├───────────────┼─────────────────────────────┤
227
+
│ classifier │ linux-x64 │
228
+
├───────────────┼─────────────────────────────┤
229
+
│ ELF PT_INTERP │ /lib64/ld-linux-x86-64.so.2 │
230
+
└───────────────┴─────────────────────────────┘
231
+
232
+
Key answers to the open questions from section 3.6:
233
+
234
+
1. Can we read `/proc/self/exe` from Java? — ✅ Yes. `Files.newInputStream(Path.of("/proc/self/exe"))` works fine. The JVM binary is an ELF64 executable linked against glibc, and `PT_INTERP` is at offset within the first 2 KB.
235
+
2. Does the ELF parsing correctly identify glibc? — ✅ Yes. The dynamic linker path `/lib64/ld-linux-x86-64.so.2` is correctly extracted and matched as glibc.
236
+
3. Classifier maps to correct resource path — `native/linux-x64/runtime.node` matches the expected layout from section 3.1.
0 commit comments