Cannot Compile Formulae using c++ with gcc-8 (probably gcc >= 6) #724
Comments
|
@kalaxy Thanks for the bug report, Kalon. Linuxbrew modified the default GCC I wasn't able to reproduce this issue using… Are you able to reproduce this issue in a Docker image? |
|
Hi @sjackman, thanks for starting to look at this. In order to see the failure you need to install a formula that uses the c++ std library. It looks like Yeah, adding |
|
Ah, my mistake. Thanks for clearing that up, Kalon. I tried installing Are you able to reproduce this issue in a Docker image? |
|
Gotcha, sorry about that. I'm not that familiar with Docker so was avoiding it. (Yeah I know I'm behind on the times.) No, as you found, I am not able to replicate it from a the linuxbrew/linuxbrew docker container. I am, however, able to get this to reproduce with a CentOS docker container. That is what matches my system. Does that help? Debugging a bit, It appears that the packages installed are a little different. For instance on the CentOS container I after installing gcc@8 I have But in the linuxbrew docker container I only have So something about the env is changing how things are installed. Maybe it is also affecting the |
|
I just noticed that you already have a Dockerfile for CentOS7 which includes some of the setup that I did above. It also reproduces the problem. |
|
@kalaxy It's installing docker run -it --rm linuxbrew/linuxbrew:1.6.8
brew install glibc
brew install gcc@8
brew install berkeley-db --cc=gcc-8
…
checking whether the C++ compiler supports templates for STL... configure: error: no |
|
Removing the docker run -it --rm linuxbrew/linuxbrew:1.6.8
brew install glibc
brew install gcc@8
rm /home/linuxbrew/.linuxbrew/Cellar/gcc@8/8.1.0/lib/gcc/8/gcc/x86_64-pc-linux-gnu/8.1.0/specs
brew install berkeley-db --cc=gcc-8
…
🍺 /home/linuxbrew/.linuxbrew/Cellar/berkeley-db/6.2.32: 5,632 files, 126.4MB, built in 8 minutes 18 seconds |
|
I am still in the travelling. @sjackman Could you help to test whether it can be workaround using std env instead of super env? I suspect that this is caused by passing After the
I think this is because without the spec file, gcc will search glibc header file in As for solutions, one way is to add |
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html Sounds like using |
|
When I change Brew's
|
|
Success! diff --git a/Library/Homebrew/shims/super/cc b/Library/Homebrew/shims/super/cc
index d6085a3..55e9e27 100755
--- a/Library/Homebrew/shims/super/cc
+++ b/Library/Homebrew/shims/super/cc
@@ -270,7 +270,7 @@ class Cmd
end
def cppflags
- path_flags("-isystem", isystem_paths) + path_flags("-I", include_paths)
+ path_flags("-idirafter", isystem_paths) + path_flags("-I", include_paths)
end
def ldflags_mac(args) |
|
Here's a PR to hopefully address this issue: #733 |
|
@sjackman Personally, I would prefer to fix this in gcc@6 gcc@7 and gcc@8 formula. Further, I suspect the root issue is a bug from gcc >= 6 rather than Linuxbrew. For example in Ubuntu Bionic docker image, I can reproduce this bug as following: Another reason to fix it in formula is that this bug can be trigger by users who use gcc formula as shown in the above. |
|
@xu-cheng, fyi see gcc bug 70129. It appears that they have decided it is working as designed. It sounds like their suggestion is to just not add the -isystem path when it is already included in other ways, for example, via the specs file. Though others, such as comment 5, on that thread seem to have good reasons it should be allowed. So it may be worth pressing the gcc team again. |
|
I commented on the closed GCC bug to mention that it affects Linuxbrew as well. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129#c7 |
For gcc >= 6, passing -isystem flag will result to the include path search order change. This causes issues for brew superenv, which passes -isystem HOMEBREW_PREFIX/include to the compiler. For more detail, please refer to issue Linuxbrew/brew#724 Related upstream issue can be found at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 This workarounds this issue by passing brew glibc include path to the end of search path.
|
https://github.com/Linuxbrew/homebrew-core/pull/8108 is another solution. |
|
This fix PR https://github.com/Linuxbrew/homebrew-core/pull/8108 looks good to me. Thanks again, @xu-cheng! Shall I close this PR in favour of PR https://github.com/Linuxbrew/homebrew-core/pull/8108 ? |
|
I can confirm that the changes you made work for me. Thanks so much for your help diagnosing and coming to a solution! Closing, as the desired workflow works now. |
|
Thanks for following up, Kalon. Thanks again, @xu-cheng ! |
I'm trying to compile formulae using the gcc@8 package. When I try to compile formulae which use the c++ stdlib, I get build failures. Steps to reproduce:
This fails for me:
After digging in the config.log I found this failure:
I tracked this down to a behavior change in gcc's
-isystemhandling. See gcc bug 70129. It appears that since gcc 6, but I haven't tried 6 or 7. Essentially, adding an include path which is already part of the default include paths causes issues when resolving c++ stdlib includes.brew appears to automatically add
-isystem=$(brew --prefix)/includeeven though it is already encoded as a default search path for gcc.Note the default search paths in gcc-8 already include
$(brew --prefix)/include.I tried reproducing this on homebrew for mac and couldn't. That said, I was using the default install location rather than a custom location, and it looks like there might be hooks in place detecting the default location and acting differently in that case.
Anyway, I believe to make this work brew needs to forgo adding
-isystem$(brew --prefix)/includefor gcc 6 and later when it is already in the include path. But I'm not sure how to do that. Is this something easily fixable?For info:
Unrelated, but since the output was asked for...
The text was updated successfully, but these errors were encountered: