Re: Clang c++ include path
I've sent a quick fix for this to guix-patches (sorry if I haven't followed the right process for this!) I'd like to think more about how to write a make-clang-toolchain procedure properly so you can pick libstdc++/libc++ versions etc, as my current implementation is pretty lacking. My patch should fix clang if all you want is to use the default gcc from guix though. David Truby On Mon, 2019-11-11 at 15:12 +, David Truby wrote: > Hi, > > This patch doesn't work for me as it seems to have a similar issue > finding the libc++ headers. > > > I do have a fix for the libstdc++ header issue though, I'm just > trying > to clean up the patch and then will send it to paches-guix. It > involves > patching the source, so will trigger a rebuild of anything depending > on > clang (however it doesn't touch llvm). I haven't yet worked out a way > of fixing libc++ but it should be fixable in a similar way. > > > I actually have two ways of fixing it though and am unsure which is > more appropriate. The non-controversial one is to just get the > libstdc++ header directory for the default gcc and patch clang to > look > there. However, as an end user of the clang package I would rather > have > a make-clang-toolchain procedure that takes a gcc-toolchain version > and > gets the standard library from that. I've got implementations of both > of these, does anyone have an opinion which one would be preferred? > > David Truby > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you.
Re: Clang c++ include path
Hello David, > I actually have two ways of fixing it though and am unsure which is > more appropriate. The non-controversial one is to just get the > libstdc++ header directory for the default gcc and patch clang to look > there. However, as an end user of the clang package I would rather have > a make-clang-toolchain procedure that takes a gcc-toolchain version and > gets the standard library from that. I've got implementations of both > of these, does anyone have an opinion which one would be preferred? At first glace, the second option seems better but don't hesitate to post both versions and we'll discuss them :) Thanks, Mathieu
Re: Clang c++ include path
Hi, This patch doesn't work for me as it seems to have a similar issue finding the libc++ headers. I do have a fix for the libstdc++ header issue though, I'm just trying to clean up the patch and then will send it to paches-guix. It involves patching the source, so will trigger a rebuild of anything depending on clang (however it doesn't touch llvm). I haven't yet worked out a way of fixing libc++ but it should be fixable in a similar way. I actually have two ways of fixing it though and am unsure which is more appropriate. The non-controversial one is to just get the libstdc++ header directory for the default gcc and patch clang to look there. However, as an end user of the clang package I would rather have a make-clang-toolchain procedure that takes a gcc-toolchain version and gets the standard library from that. I've got implementations of both of these, does anyone have an opinion which one would be preferred? David Truby IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: Clang c++ include path
Hi Danny, Danny Milosavljevic wrote: > Hi Mark, > >> variable name. The reason is that IceCat depends on Rust which depends >> on Clang, and there is a chain of *18* Rust compilers that must be built >> before IceCat can be built. On my system, compiling all of those Rust >> compilers requires approximately *90 hours* of continuous compiling. > > Are you sure that Rust depends on clang? gnu/packages/rust.scm doesn't have > any > direct reference to "clang" except to remove it. Ah, you're right, Rust depends on LLVM, but not Clang. I guess it's probably fine to fix the Clang C++ include path without introducing new variable bindings. Sorry for the mistake. In a later message, Danny wrote: > mrustc 0.9 supports bootstrapping Rust 1.29.0. That's great news :) Thank you! Mark
Re: Clang c++ include path
> On Nov 7, 2019, at 11:29 AM, Danny Milosavljevic > wrote: > > Are you sure that Rust depends on clang? gnu/packages/rust.scm doesn't have > any > direct reference to "clang" except to remove it. Rust doesn’t depend on clang, it does, however, depend on llvm
Re: Clang c++ include path
> I think that the situation with Rust in that we need to build 18 compilers > is regrettable--I hope that thepowersgang's mrustc can eventually be used > to leapfrog that (it's still active--AND v0.9 has been released) mrustc 0.9 supports bootstrapping Rust 1.29.0. pgpLIAPJtJBi8.pgp Description: OpenPGP digital signature
Re: Clang c++ include path
Hi Mark, > variable name. The reason is that IceCat depends on Rust which depends > on Clang, and there is a chain of *18* Rust compilers that must be built > before IceCat can be built. On my system, compiling all of those Rust > compilers requires approximately *90 hours* of continuous compiling. Are you sure that Rust depends on clang? gnu/packages/rust.scm doesn't have any direct reference to "clang" except to remove it. I think that the situation with Rust in that we need to build 18 compilers is regrettable--I hope that thepowersgang's mrustc can eventually be used to leapfrog that (it's still active--AND v0.9 has been released) and just have a small chain mrustc -> rust-1.37 eventually. pgpIo7qHsNBq2.pgp Description: OpenPGP digital signature
Re: Clang c++ include path
So here’s my naive suggestion:
We should have a MAKE-CLANG-TOOLCHAIN procedure that, given a clang package, a
libc package, and a libc++ package (either libc++ or libstdc++), returns a
fully-working clang toolchain.
I did encounter some problems while attempting this as you can see here:
https://lists.gnu.org/archive/html/bug-guix/2019-11/msg00042.html
As Mathieu pointed out in that thread, the problem is probably that clang
cannot find libstdc++ headers.
My first instinct is to use C{,PLUS}_INCLUDE_PATH and friends to solve this,
but I remember trying this and it not working… Perhaps this needs to be a flag
at compile/configure time for clang?
By the way, getting clang to work is the last piece I need to get Bitcoin Core
release builds fully working on Guix, so I’ll be focusing on this and would
appreciate any help I can get from you wizards!
Cheers,
Carl Dong
Re: Clang c++ include path
Hi, Mark H Weaver skribis: > Ricardo Wurmus writes: > >>> When running clang on a c++ program, it cannot find c++ std libraries. >>> That's because, those libraries path are hardcoded inside g++ compiler >>> and clang cannot find them. >> >> Does this patch help? > > I'd like to request that fixes to LLVM/Clang be done on another branch > for now, or at least that the fixed versions are given a different > variable name. The reason is that IceCat depends on Rust which depends > on Clang, and there is a chain of *18* Rust compilers that must be built > before IceCat can be built. How hard would it be to define ‘clang/fixed’ and ‘llvm/fixed’, which would be variants that are known to be rarely updated? We would ensure Rust depends on these while still making it possible for other packages to depend on the latest versions. Thanks, Ludo’.
Re: Clang c++ include path
Hello Ricardo, > Does this patch help? > > --8<---cut here---start->8--- > diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm > index 9efb4a4841..3c59e8d26d 100644 > --- a/gnu/packages/llvm.scm > +++ b/gnu/packages/llvm.scm Thanks for your patch. It seems that it forces clang to use llvm libc++ library. Is this really what we want? Wouldn't we prefer to force clang to use GNU's libstdc++? For comparison sake, nix has a default clang that uses GNU's libstdc++ and as a "clang-cxx" that uses libcxx. I think it is important to fix this issue because all external tools (such as lsp servers) that rely on clang are currently broken in Guix. Thanks, Mathieu
Re: Clang c++ include path
Mark H Weaver writes: > Hi Ricardo and Mathieu, > > Ricardo Wurmus writes: > >>> When running clang on a c++ program, it cannot find c++ std libraries. >>> That's because, those libraries path are hardcoded inside g++ compiler >>> and clang cannot find them. >> >> Does this patch help? > > I'd like to request that fixes to LLVM/Clang be done on another branch > for now, or at least that the fixed versions are given a different > variable name. The reason is that IceCat depends on Rust which depends > on Clang, and there is a chain of *18* Rust compilers that must be built > before IceCat can be built. On my system, compiling all of those Rust > compilers requires approximately *90 hours* of continuous compiling. > > For the sake of Guix users like myself who do not want to trust the > build farm, it would be good for it to remain reasonably viable to build > everything locally. I agree. The CI system also spends days bootstrapping the Rust compiler chain. Any user who tries to install IceCat during that time will have a terrible experience. I've been keeping "libgit2" updates in 'staging' for that reason, even though it is below the ~300 rebuild limit. signature.asc Description: PGP signature
Re: Clang c++ include path
Hi Ricardo and Mathieu, Ricardo Wurmus writes: >> When running clang on a c++ program, it cannot find c++ std libraries. >> That's because, those libraries path are hardcoded inside g++ compiler >> and clang cannot find them. > > Does this patch help? I'd like to request that fixes to LLVM/Clang be done on another branch for now, or at least that the fixed versions are given a different variable name. The reason is that IceCat depends on Rust which depends on Clang, and there is a chain of *18* Rust compilers that must be built before IceCat can be built. On my system, compiling all of those Rust compilers requires approximately *90 hours* of continuous compiling. For the sake of Guix users like myself who do not want to trust the build farm, it would be good for it to remain reasonably viable to build everything locally. What do you think? Mark
Re: Clang c++ include path
Hi Mathieu,
> When running clang on a c++ program, it cannot find c++ std libraries.
> That's because, those libraries path are hardcoded inside g++ compiler
> and clang cannot find them.
Does this patch help?
--8<---cut here---start->8---
diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
index 9efb4a4841..3c59e8d26d 100644
--- a/gnu/packages/llvm.scm
+++ b/gnu/packages/llvm.scm
@@ -204,7 +204,7 @@ compiler. In LLVM this library is called \"compiler-rt\".")
(compiler-rt (assoc-ref inputs "clang-runtime")))
(case (string->number ,(version-major
(package-version
clang-runtime)))
- ((or 6 7)
+ ((or 6 7 8)
;; Link to libclang_rt files from clang-runtime.
(substitute* "lib/Driver/ToolChain.cpp"
(("getDriver\\(\\)\\.ResourceDir")
@@ -363,16 +363,15 @@ requirements according to version 1.1 of the OpenCL
specification.")
"1mf9cpgvix34xlpv0inkgl3qmdvgvp96f7sksqizri0n5xfp1cgp"))
(file-name (string-append "libomp-" version ".tar.xz"
(build-system cmake-build-system)
-;; XXX: Note this gets built with GCC because building with Clang itself
-;; fails (missing , even when libcxx is added as an input.)
(arguments
'(#:configure-flags '("-DLIBOMP_USE_HWLOC=ON"
- "-DOPENMP_TEST_C_COMPILER=clang"
- "-DOPENMP_TEST_CXX_COMPILER=clang++")
+ "-DCMAKE_C_COMPILER=clang"
+ "-DCMAKE_CXX_COMPILER=clang++")
#:test-target "check-libomptarget"))
(native-inputs
`(("clang" ,clang)
("llvm" ,llvm)
+ ("libcxx" ,libcxx)
("perl" ,perl)
("pkg-config" ,pkg-config)))
(inputs
--8<---cut here---end--->8---
--
Ricardo
Clang c++ include path
Hello,
When running clang on a c++ program, it cannot find c++ std libraries.
That's because, those libraries path are hardcoded inside g++ compiler
and clang cannot find them.
This has already been discussed here:
https://issues.guix.info/issue/32773, without reaching a solution.
Running this program,
--8<---cut here---start->8---
#include
int main()
{
return 0;
}
--8<---cut here---end--->8---
I have this error:
--8<---cut here---start->8---
mathieu@meru:~/tmp$ ~/.guix-profile/bin/clang t.cpp
#include
^~~~
t.cpp:1:10: fatal error: 'string' file not found
1 error generated.
--8<---cut here---end--->8---
that's because:
--8<---cut here---start->8---
mathieu@meru:~/tmp$ ~/.guix-profile/bin/clang -v t.cpp
...
#include "..." search starts here:
#include <...> search starts here:
/gnu/store/933ijsm5wwjkvlh963lc3pxc7i3dfxcp-profile/include
/gnu/store/i2vzqb02gxcm5c2zix92lq3ay73kbl9s-clang-8.0.0/lib/clang/8.0.0/include
/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include
End of search list.
#include
^~~~
t.cpp:1:10: fatal error: 'string' file not found
1 error generated.
--8<---cut here---end--->8---
whereas,
--8<---cut here---start->8---
mathieu@meru:~/tmp$ ~/.guix-profile/bin/g++ -v t.cpp
...
#include "..." search starts here:
#include <...> search starts here:
/gnu/store/933ijsm5wwjkvlh963lc3pxc7i3dfxcp-profile/include
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++ [1]
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++/x86_64-unknown-linux-gnu
[2]
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++/backward [3]
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed
/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include
...
--8<---cut here---end--->8---
Hardcoding the paths [1], [2] and [3] into clang would solve the
issue, but it might not be the better way to proceed. WDYT?
Mathieu
Clang c++ include path
Message-ID: <87r22xxoy6@gmail.com>
User-agent: mu4e 1.2.0; emacs 26.3
https://issues.guix.info/issue/32773,
mathieu@meru:~/tmp$ ~/.guix-profile/bin/clang t.cpp
t.cpp:1:10: fatal error: 'string' file not found
mathieu@meru:~/tmp$ ~/.guix-profile/bin/clang -v t.cpp
t.cpp:1:10: fatal error: 'string' file not found
mathieu@meru:~/tmp$ ~/.guix-profile/bin/g++ -v t.cpp
Hello,
When running clang on a c++ program, it cannot find c++ std libraries.
That's because, those libraries path are hardcoded inside g++ compiler
and clang cannot find them.
This has already been discussed here:
without reaching a solution.
Running this program,
--8<---cut here---start->8---
#include
int main()
{
return 0;
}
--8<---cut here---end--->8---
I have this error:
--8<---cut here---start->8---
#include
^~~~
1 error generated.
--8<---cut here---end--->8---
that's because:
--8<---cut here---start->8---
...
#include "..." search starts here:
#include <...> search starts here:
/gnu/store/933ijsm5wwjkvlh963lc3pxc7i3dfxcp-profile/include
/gnu/store/i2vzqb02gxcm5c2zix92lq3ay73kbl9s-clang-8.0.0/lib/clang/8.0.0/include
/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include
End of search list.
#include
^~~~
1 error generated.
--8<---cut here---end--->8---
whereas,
--8<---cut here---start->8---
...
#include "..." search starts here:
#include <...> search starts here:
/gnu/store/933ijsm5wwjkvlh963lc3pxc7i3dfxcp-profile/include
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++ [1]
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++/x86_64-unknown-linux-gnu
[2]
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/include/c++/backward [3]
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include
/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed
/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include
...
--8<---cut here---end--->8---
Hardcoding the paths [1], [2] and [3] into clang would solve the
issue, but it might not be the better way to proceed. WDYT?
Mathieu
