[llvm] Fix ExecuteAndWait with empty environment on Windows (PR #158719)

[Paul Osmialowski via llvm-commits]

pawosm-arm wrote:

Somehow this managed to cause a regression on Linux! In our LLVM builds we are using libc++ as a standard C++ library. I assume this is still somewhat unusual thing to do, but so far all test cases were passing. Except the one introduced by this commit:
```
-- Testing: 98831 tests, 256 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80..
FAIL: LLVM-Unit :: Support/./SupportTests/151/406 (89601 of 98831)
******************** TEST 'LLVM-Unit :: Support/./SupportTests/151/406' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:unittests/Support/./SupportTests-LLVM-Unit-3565525-151-406.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=406 GTEST_SHARD_INDEX=151 unittests/Support/./SupportTests
--

Script:
--
unittests/Support/./SupportTests --gtest_filter=ProgramEnvTest.TestExecuteEmptyEnvironment
--
unittests/Support/SupportTests: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory
llvm/unittests/Support/ProgramTest.cpp:698: Failure
Expected equality of these values:
  0
  RetCode
    Which is: -1


llvm/unittests/Support/ProgramTest.cpp:698
Expected equality of these values:
  0
  RetCode
    Which is: -1



********************
```
Note that `LD_LIBRARY_PATH` is set to the place where `libc++.so.1` exists when executing tests, but apparently it isn't sufficient here. Forcing the `rpath` to be set (e.g. by providing a compiler config file) does help with this test case, but break the others.


https://github.com/llvm/llvm-project/pull/158719