This arg is undocumented but from looking at the code + experiment, it's used to add additional DYLD_ENVIRONMENT load commands to the output.
This looks involved enough that it could go into a parse...() helper in DriverUtils.
Do we have to save() this? We don't change it, do we?
ld64 doesn't seem to check for this (?)
no need for the if, the loop does 0 iterations if dyldEnvs is empty
why does this need shell?
check that this errors when making dylibs
Should something be validated here? Is it limited to a list of known possible values that could be enumerated or is it valid to have DYLD_FOO_PATH=foo embedded in the binary?
I believe shell is needed to run the symlinks. Alternatively, we could make this test not be supported on windows.
Yes - added support for that. Thanks!
relaxed the validations (per thakis's comment below), so I guess we don't even need to check for this
Yes - it was needed because of ln, but I guess we dont really need it in this tests. (ie., the paths don't need to exist...)
no, it was platform-dependence because of the test path (which is part of the DYLD_FRAMEWORK_PATH value. I've changed the tests to use relative paths instead.
total nit but I think it's clearer this way. I don't actually know off the top of my head what strchr returns in error cases (though I can certainly infer based on how it's used here)
grammar nit: malformed -dyld_env value or -dyld_env's argument is malformed
if we construct envPair as a StringRef then I don't think we'll need the Twine() here
can we place this along with the rest of the grp_rare options? No need for the leading/trailing newlines too