LD_LIBRARY_PATH to fromsource glibc causes SIGSEGV in child process popen shell #291

Background

mcpp sets LD_LIBRARY_PATH in child process environments, pointing to the
fromsource glibc in its internal registry (~/.mcpp/registry/). Providers
(e.g. d2x-buildtools) inherit this environment and use popen() / system()
to invoke subprocesses.

Describe

The fromsource glibc's libc.so.6 was compiled on a different build machine
and is ABI-incompatible with the system /bin/sh. When a provider calls
popen("mcpp test ..."), the dynamic linker loads the incompatible libc.so.6
from LD_LIBRARY_PATH during shell startup, causing SIGSEGV before any
script command executes. The provider receives empty stdout.
mcpp itself is statically linked and does not need LD_LIBRARY_PATH.

Desktop

• mcpp v0.0.104
• Ubuntu 22.04, x86_64
• mcpp internal registry: ~/.mcpp/registry/

To Reproduce

# 1. mcpp internal registry has fromsource glibc@2.39 installed
# 2. Reproduce the crash directly:
LD_LIBRARY_PATH=~/.mcpp/registry/data/xpkgs/xim-x-glibc/2.39/lib64 \
  /bin/sh -c "echo hello"
# → Segmentation fault (core dumped)

# 3. strace confirms shell crashes on startup, not during script execution:
# execve("/bin/sh", ["sh", "-c", "..."]) → SIGSEGV

# 4. This causes provider failures:
mcpp run -q -p d2x/buildtools -- check hello-mcpp
# → "mcpp test 没有返回 'hello-mcpp' 的记录"
#   (because popen returned empty stdout)

Expected

popen() should execute normally and return subprocess output. Alternatively,
mcpp should not pass the private glibc LD_LIBRARY_PATH to statically-linked
child processes.

Tried Solutions

Modified provider source to unsetenv("LD_LIBRARY_PATH") before popen() and
setenv() to restore it afterwards, as a temporary workaround.

Additional Context

The glibc binary also leaks the build machine path:
file ~/.mcpp/registry/data/xpkgs/xim-x-glibc/2.39/lib64/libc.so.6
→ interpreter /home/xlings/.xlings_data/xim/xpkgs/fromsource-x-glibc/...