Clang c++ include path

Clang c++ include path

[Mathieu Othacehe]

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 <string>

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 <string>
         ^~~~~~~~
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 <string>
         ^~~~~~~~
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

Re: Clang c++ include path

[Ricardo Wurmus]

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 <atomic>, 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

Re: Clang c++ include path

[Mark H Weaver]

Hi Ricardo and Mathieu,

Ricardo Wurmus <rekado@elephly.net> 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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Hi Ricardo and Mathieu,
>
> Ricardo Wurmus <rekado@elephly.net> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Clang c++ include path

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Ricardo Wurmus <rekado@elephly.net> 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

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Clang c++ include path

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

> 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Clang c++ include path

[Carl Dong]

> On Nov 7, 2019, at 11:29 AM, Danny Milosavljevic <dannym@scratchpost.org> 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

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> 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

[Mathieu Othacehe]

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

[David Truby]

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

[Mathieu Othacehe]

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

[David Truby]

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 +0000, 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

[Protonmail Bridge]

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

Clang c++ include path

[Mathieu Othacehe]

Message-ID: <87r22xxoy6.fsf@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 <string>

int main()
{
  return 0;
}
--8<---------------cut here---------------end--------------->8---

I have this error:

--8<---------------cut here---------------start------------->8---
#include <string>
         ^~~~~~~~
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 <string>
         ^~~~~~~~
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