gh-156703: Set LD_LIBRARY_PATH in SystemTap trace commands

[stratakis]

Prefix commands passed to stap -c with LD_LIBRARY_PATH via env, when probes reside in libpython. This allows the interpreter to find libpython when staprun does not preserve the loader path.

• Issue: test_dtrace fails on aarch64 Fedora Stable 3.15: "libpython3.15d.so.1.0: cannot open shared object file" #156703

[stratakis]

cc @encukou this should be fixing the buildbots dtrace issues, however if you can add the label to test with buildbots.

[stratakis]

If that works, it also requires the backport to 3.15 label.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @StanFromIreland for commit 96277bb 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F156424%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[encukou]

Unfortunately PPC64LE still fails:

dtrace(1) failed: /usr/bin/dtrace invalid option -q

[encukou]

Is there a reason to go through /usr/bin/env, rather than give the environment directly to subprocess.Popen (i.e. create_process_group)?

[vstinner]

Is this change a fix for #156703 issue?

I see multiple failures on PPC64LE buildbots. Example on "buildbot/PPC64LE Fedora Stable PR":

Warning -- test_dtrace leaked temporary files (4): GMfifo3365795, GMfifo3366470, stapjjRj5t, stapt2e6lv

Oh, that's issue #156701.

[stratakis]

Unfortunately PPC64LE still fails:

dtrace(1) failed: /usr/bin/dtrace invalid option -q

Us that a failure? That is expected as the dtrace path is not exercised on Linux, Systemtap doesn't have the -q option.

[stratakis]

Is there a reason to go through /usr/bin/env, rather than give the environment directly to subprocess.Popen (i.e. create_process_group)?

staprun removes LD_LIBRARY_PATH before starting Python so passing it to Popen is not enough, it must be added to the command that starts Python.

[stratakis]

Rebased to change the commit message to reference the proper issue, no code changes.