Bundled native libraries collide with same-named libs from a MIKE engine installation on LD_LIBRARY_PATH — import mikeio segfaults (proposal: auditwheel-style isolation)
@JesperGr ci sta già lavorando.
Dal 6/7/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Summary
import mikeio (and therefore mikecore) segfaults in any Python process that has a MIKE installation's bin directory on LD_LIBRARY_PATH (e.g. after sourcing mikevars.sh). This makes it impossible to use mikeio in the same environment — or the same process — as an installed MIKE engine.
The root cause is in how the mikecore Linux wheel bundles its native libraries, and it is fixable entirely inside the wheel build with standard tooling (auditwheel / patchelf). We have verified a fix experimentally: with a patched mikecore, mikeio and a running MIKE engine coexist happily in a single process.
The problem, at a high level
The mikecore wheel ships its own copies of DHI and Intel native libraries (libeum.so, libufs.so, libpfs2004.so, libMzCart.so, libimf.so, libiomp5.so, libsvml.so, libirng.so, libintlc.so.5, …), built around 2015. A MIKE engine installation ships newer libraries with exactly the same names (2025 builds in current releases).
Because the two library sets share names, the dynamic linker mixes them, in two independent ways:
LD_LIBRARY_PATHhijack. mikecore's bundled libs carryRUNPATH=$ORIGIN. On Linux,RUNPATHis searched afterLD_LIBRARY_PATH— so once a MIKEbindir is onLD_LIBRARY_PATH, mikecore's 2015libeum.sogets its dependencies (libimf,libiomp5,libpfs2004, …) resolved to the engine's 2025 copies. Result:import mikeio→ SIGSEGV, even if no engine library was ever loaded by Python.- soname dedup. Even with (1) fixed, glibc loads at most one library per soname. Whichever
libimf.so/libiomp5.so/ … loads first is silently reused by the other party. With the engine loaded first, mikecore aborts withfree(): invalid size; with mikecore first, the engine fails with e.g.libpetsc.so.3.22: undefined symbol: __svml_ldexp2.
Nothing about this is specific to one MIKE release — any MIKE version that ships same-named libraries will collide with mikecore's bundle. Conversely, once the bundle is properly isolated, mikecore is compatible with every MIKE version, past and future, because its libraries no longer share names with anything outside the wheel.
What mikecore needs, concretely
Make the bundled native libraries fully self-contained and collision-free — exactly what auditwheel repair does for every manylinux wheel on PyPI:
RPATHinstead ofRUNPATH. SetDT_RPATH=$ORIGINon every bundled.so(patchelf --force-rpath --set-rpath '$ORIGIN').RPATHis searched beforeLD_LIBRARY_PATH, so the bundle always resolves to itself regardless of the caller's environment.- Unique sonames. Give every bundled library a name that cannot collide with a MIKE installation — e.g. a version/hash suffix (
libeum-mc2015.so, or auditwheel'slibeum-a1b2c3d4.sostyle): rename the files,patchelf --set-sonameaccordingly, andpatchelf --replace-needed old newin every bundled lib that depends on them. The three libraries mikecore's Python code dlopens by absolute path (libeum.so,libufs.so,libMzCart.so) can keep their filenames — only their sonames and NEEDED entries need the treatment.
The simplest implementation is to run auditwheel repair as part of the Linux wheel build — it performs both steps (and the manylinux compliance check) automatically. If the bundle layout makes auditwheel awkward, the equivalent manual patchelf recipe is ~20 lines; we have a working script and can share it.
Windows likely deserves an audit too (DLL search order / same-basename shadowing when a MIKE bin is on PATH), but we have only verified the Linux side; the Windows failure mode — if any — may differ.
Evidence
All experiments on Linux (WSL2, Ubuntu), mikecore from PyPI, a current MIKE engine installation, mikevars.sh + oneAPI setvars.sh sourced:
| Scenario | Stock mikecore | Patched mikecore (RPATH + unique sonames) |
|---|---|---|
import mikeio + read dfsu |
SIGSEGV (exit 139) | ✅ works |
| mikeio first, then load an engine library | SIGSEGV | ✅ works |
| engine library first, then mikeio | abort, free(): invalid size |
⚠️ still fails¹ |
| engine simulation + mikeio reading its output mid-run, one process | impossible | ✅ works — mikeio values match the engine's in-memory state on all wet elements |
¹ This residual ordering constraint is on the caller's side, not mikecore's: loading an engine library with RTLD_GLOBAL puts its symbols in the global scope where they override anything loaded later. Importing mikeio before the engine avoids it.
Ask
Could the mikecore Linux wheel be built (or post-processed) with auditwheel-style isolation as described above? Happy to share the patchelf script, the test matrix, and a live demo, or to help test a candidate wheel against MIKE engine installations.
🤖 Drafted with Claude Code
- Lingua principale
- Python
- Stelle
- 5
- Fork
- 1
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di DHI/mikecore-python
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
DHI/mikecore-python#49 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
DHI/mikecore-python#54 · 2 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
DHI/mikecore-python#52 ·
-
Remaining TODOs in production code: platform notes, licensing questions, and one likely-stale marker Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
DHI/mikecore-python#51 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
DHI/mikecore-python#50 ·
Tutte le issue di DHI/mikecore-python
Issue simili
-
bug confirmed issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
open-webui/open-webui#30750 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
good first issue
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100