cstdlib shipped with gcc 6, 7, and 8 fail to find stdlib.h in standalone spawn strategy which causes build failures #8444
Comments
oquenchil
added
P3
|
As an addendum, I found that this issue triggers if I have an external dependency like the following (this is a file called system.BUILD):
and the WORKSPACE contains:
I was unable to reproduce this issue without these being in the project. |
|
We are hitting this exact issue when build with --spawn_strategy=standalone. Any workaround to unblock this? |
|
Thank you for the detailed description. I'm not sure we can do anything about it. The Why are you creating a local repository out of /usr/? Could you create a symlink to /usr/ and see if that makes it work? |
|
Any progress on this? |
oquenchil
added
help wanted
|
No updates. If someone comes up with a solution I'd be happy to discuss. |
|
I also run into this issue. Any solution? |
Description of the problem / feature request:
It seems that due to a change made in cstdlib starting with gcc 6, the use of -isystem command line options causes the system include order to change and thus c++ code which uses cstdlib will fail to build if the spawn strategy does not use the sandbox. See the bottom of the report for the full description of what is going on. The issue in question is documented here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936
Feature requests: what underlying problem are you trying to solve with this feature?
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Setup a simple C++ project with a single file and have cstdlib included either directly or indirectly. Perform a bazel build with --spawn_strategy=standalone and the error should appear.
What operating system are you running Bazel on?
Observed with gcc 6, 7, and 8 on ubuntu 16.04, ubuntu 19.04, Linux Mint 19.1, and Gentoo Linux.
What's the output of
bazel info release?Linux Mint 19.1: release 0.24.1
Gentoo Linux: release 0.24.1- (@non-git) [Built via
emerge]Ubuntu 16.04: release 0.25.2, release 0.22.0, and release 0.21.0
Ubuntu 19.04: release 0.25.2
What's the output of
git remote get-url origin ; git rev-parse master ; git rev-parse HEAD?Unsure how to answer this, which repo? Some of it is proprietary
Have you found anything relevant by searching the web?
The only thing relevant is the bugzilla link (which was found by a coworker) I pasted above, here it is again for completeness: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936
Any other information, logs, or outputs that you want to share?
So for brevity, I will do a brain dump from this point forward. This is a copy (cleaned up to strip anything proprietary) from our internal JIRA tracker. We have encountered this issue with a customer. Before I describe the issue and background, please don't hesitate to ask questions or request clarification.
So to start with, we encountered the error originally trying to manually run a compile command line generated by bazel. Here is an example of the error we saw:
This error stems from the above bugzilla link where GCC replaced
#include <stdlib.h>with#include_next <stdlib.h>in GCC 6 and above in the filecstdlib. This error baffled us for a while because it does not manifest when building with bazel itself. At first we thought there may be a bazel specific hack taking place but as you'll see the actual issue is far simpler.When I run our example project through bazel on my Gentoo Linux machine with sandbox debugging I see the following information:
In this case we are running with the sandbox enabled and the working directory points to sandbox directory as it should. This is correct, everything looks fine, and we are successful in building. Here is where the issue actual arises, I have added -v to the command lines so I can see what gcc is doing. Here is the snipped log for that:
The
-isystemoptions added by bazel are not used during the build and gcc is free to put /usr/include at the end of the list. Thus the#include_next <stdlib.h>directive incstdlibworks because/usr/includecomes last in the search order. Here is that portion of the above log in detail:When I disable the sandbox I am able to trigger the compilation failure shown previously:
You'll notice that the search list has changed because the working directory has changed to
/home/jscoggins/.cache/bazel/_bazel_jscoggins/43973faf65a1791ca71ea4969beeaceb/execroot/__main__from the sandbox directory. The-isystemcommand line options are now used and change the search order when dealing with includes. Here is that portion of the above log:Since
external/system_project/includerefers to/usr/includegcc determines that/usr/includeis a duplicate and does not add it to the end of the list. Whencstdlib's#include_next <stdlib.h>directive is evaluated, the#include_nextcausesexternal/system_project/includeto be ignored in the lookup list. This is what causes the lookup failure to occur and thus the compilation error as well. This locks bazel out of doing standalone builds with gcc 6 and up when compiling C++ code which need cstdlib.To solve this problem we are eliminating the option
-isystem external/system_project/includemanually before performing analysis with our external analysis tools.The text was updated successfully, but these errors were encountered: