`libgdiplus`, on Linux hosts only. ServUO targets net48, so on Linux it runs
under Mono, and Mono's `System.Drawing` is a thin layer over that library -- which
sits in the DECODE path, not merely the encode: `Ultima.Frame` writes ARGB1555
through a LockBits pointer, so without it the shard cannot read one sprite out of
the operator's UO client.
docs/link/v8.md §17.2 took all three answers to this rather than one -- the
prerequisite in SHARD_PREREQS.md, a named NO_IMAGING status instead of an error,
and a `doctor` check. The first two shipped in phase 1. This is the third, and
SHARD_PREREQS.md has been claiming it existed since then.
Three things about the row are deliberate:
- **Linux only, and absent elsewhere.** A Windows host ships System.Drawing with
.NET Framework and has nothing to check, so there is no row rather than a row
saying "not applicable" on three quarters of the hosts that run this.
- **A warning, never a failure.** Names and the shard's own spawn files have no
pixels in them, so a host without this library still runs a useful bridge, and
`doctor`'s exit code -- which monitoring reads -- must not go red over one
absent feature.
- **`ldconfig -p` first, paths second.** The loader's own cache is the same
question Mono asks at runtime, so a distro that puts the file somewhere unusual
answers correctly; the path probe is the fallback for a slim container with no
ldconfig, and a missing ldconfig degrades to it rather than taking doctor down.
The verdict is split from the detection so the mark and the wording are testable
on a host that has the library and one that does not; all three tests are
Linux-gated, which is where CI runs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
