add default shell env

[yliu120]

This pull request simply add default shell envs to par_* rules.

Under a lot of customized environments, the process-wrapper and sandbox of Bazel will not carry the shell envs by default. So very often, par rules will fail for this reason. This PR add the default_shell_env to the rule.

[yliu120]

Or, probably the "use_default_shell_env" could be exposed to kwargs in par_*rules. So that this behavior could be controlled by users directly from BUILD file. Please let me know what you guys think.

[duggelz]

Can you describe a bit more about what errors you're seeing?

[yliu120]

@duggelz

I built a par_binary in my system and got this:

ERROR: /home-4/yliu120@jhu.edu/.cache/bazel/_bazel_yliu120@jhu.edu/74bbb0d5913d46f353bfe0278203605c/external/subpar/compiler/BUILD:40:1: Building par file @subpar//compiler:compiler.par failed (Exit 1)
/home-4/yliu120@jhu.edu/.cache/bazel/_bazel_yliu120@jhu.edu/74bbb0d5913d46f353bfe0278203605c/execroot/fiesta3/_bin/process-wrapper: /usr/lib64/libstdc++.so.6:  subpar.bzl                                                                                                                                         
version `GLIBCXX_3.4.21' not found (required by /home-4/yliu120@jhu.edu/.cache/bazel/_bazel_yliu120@jhu.edu/74bbb0d5913d46f353bfe0278203605c/execroot/fiesta3/_bin/process-wrapper)
Target //spark_vina:spark_vina.par failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 68.078s, Critical Path: 25.57s
FAILED: Build did NOT complete successfully

This is because the process-wrapper doesn't respect the LD_LIBRARY_PATH and other shell envs. So it can't find the c++ dynamic library. This is a very common problem of Bazel's process-wrapper. Please refer to this issue: bazelbuild/bazel#4137

[yliu120]

Inside Google, this is not a problem since all envs are predefined and propagated to Blaze. And all machines are running in a same environment. But in the outside world, a lot of people built stuff in different paths so that Bazel cc utility tools should respect the host's shell envs in order to work properly.

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[yliu120]

I closed this PR since it may not have enough public interests and I think it is essentially a Bazel problem. I attached the C extension fixes PR #55 to my local master branch. I think google/subpar should support C extensions or the use-case will be too limited.