Bug 1149128 - clang++: fatal error: 'new' file not found
clang++: fatal error: 'new' file not found
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Aaron Puchert
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-02 17:09 UTC by Martin Liška
Modified: 2019-09-11 22:58 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liška 2019-09-02 17:09:28 UTC
It's probably a recent regression:

$ cat /tmp/x.cc
#include <new>

$ clang++ -c /tmp/x.cc
/tmp/x.cc:1:10: fatal error: 'new' file not found
#include <new>
         ^~~~~
1 error generated.
Comment 1 Richard Biener 2019-09-05 09:05:38 UTC
But why should it be my problem?!  Do you have gcc-c++ installed?  Did you
try stracing where clang tries to find said file?
Comment 2 Richard Biener 2019-09-05 09:07:43 UTC
btw, it works for me with clang8-8.0.1-2.1.x86_64 and libstdc++6-devel-gcc9-9.2.1+r274709-1.1.x86_64
Comment 3 Richard Biener 2019-09-05 09:10:51 UTC
btw, the 'clang' package still has no Requires to libstdc++-devel (I've once filed a bug about this)...
Comment 4 Martin Liška 2019-09-05 10:08:52 UTC
I have both packages installed:

$ sudo zypper in gcc-c++ libstdc++6-devel-gcc9
Loading repository data...
Reading installed packages...
'gcc-c++' is already installed.
No update candidate for 'gcc-c++-9-1.5.x86_64'. The highest available version is already installed.
'libstdc++6-devel-gcc9' is already installed.
No update candidate for 'libstdc++6-devel-gcc9-9.2.1+r274709-1.1.x86_64'. The highest available version is already installed.
Resolving package dependencies...

Nothing to do.

$ strace -f -s512 clang++ x.cc 2>&1 | grep openat.*new
[pid  1853] openat(AT_FDCWD, "/usr/bin/../lib64/gcc/x86_64-suse-linux/10/../../../../include/c++/new", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  1853] openat(AT_FDCWD, "/usr/local/include/new", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  1853] openat(AT_FDCWD, "/usr/lib64/clang/8.0.1/include/new", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  1853] openat(AT_FDCWD, "/usr/include/new", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid  1853] openat(AT_FDCWD, "./new", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

$ strace -f -s512 g++ x.cc 2>&1 | grep openat.*new
[pid  1874] openat(AT_FDCWD, "/usr/include/c++/9/new", O_RDONLY|O_NOCTTY) = 4
[pid  1874] openat(AT_FDCWD, "/usr/include/c++/9/new", O_RDONLY|O_NOCTTY) = 4
Comment 5 Martin Liška 2019-09-05 10:09:52 UTC
$ clang++ -v
clang version 8.0.1 (tags/RELEASE_801/final 366581)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/10
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/7
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/8
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/9
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/10
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/8
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/9
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/10
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
Comment 6 Martin Liška 2019-09-05 10:11:57 UTC
> Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/10

Ah, my bad: I had gcc10 installed.
Comment 7 Richard Biener 2019-09-05 10:36:08 UTC
Yeah, IIRC I also asked for clang to be configured to use the "system" compiler, not some randomly found one.
Comment 8 Aaron Puchert 2019-09-05 22:54:59 UTC
(In reply to Richard Biener from comment #3)
> btw, the 'clang' package still has no Requires to libstdc++-devel (I've once
> filed a bug about this)...

Yes, I removed that because clang can also be used with libc++ only. I'm working with libstdc++ myself, but it's entirely possible that someone only wants to install libc++-devel.

Perhaps we're demanding too much if we want users to recognize that a C++ compiler doesn't necessarily come with a standard library, and we could argue that libstdc++-devel is the preferred standard library for C++ on openSUSE.

Perhaps I should have used "Recommends" instead of "Suggests".

(In reply to Richard Biener from comment #7)
> Yeah, IIRC I also asked for clang to be configured to use the "system"
> compiler, not some randomly found one.

Hmm, that might not always be what users want. I work on SLE in my day job, and especially the colleagues that are still on SLE12 have much newer compilers installed than the default (GCC 4.8) and newer versions of libstdc++.

Since Clang is not tied to specific versions of libstdc++ in the same way as GCC, I think it's actually doing the right thing here.

Or let me rephrase that: I don't see a reason why the default compiler's libstdc++ necessarily works better with Clang than a newer version.
Comment 9 Aaron Puchert 2019-09-05 22:59:34 UTC
Another solution could be to create some name that is provided by both libstdc++ and libc++ and that is recommended or even required by Clang. I'm not sure if that has the intended effect, but it sounds like it could work.
Comment 10 Richard Biener 2019-09-06 08:08:26 UTC
(In reply to Aaron Puchert from comment #9)
> Another solution could be to create some name that is provided by both
> libstdc++ and libc++ and that is recommended or even required by Clang. I'm
> not sure if that has the intended effect, but it sounds like it could work.

That sounds like a good idea.  Maybe clang can simply require
(libstdc++-devel or libc++-devel)?  Will clang automatically pick libc++
if libstdc++ isn't installed?

Note my suggestion to use a "fixed" libstdc++ version is about predictability.
With GCC 10 around the corner I wonder which one it would pick given
/usr/include/c++/9/... and /usr/include/c++/10/... and on SLE12
/usr/include/c++/4.8/...?

Also compatibility with clang isn't something GCC cares much about so
you might end up with a non-working setup for clang by installing an
additional GCC compiler.

I don't have a very good suggestion here but eventually the package should
default to a build-time chosen variant, make sure that variant is installed
via a Requires but offer some way to "configure" an alternate version at
use-time (via alternatives maybe?).  IIRC upstream doesn't have a
--with-libstdc++=/path/to/fixed/libstdc++/version
Comment 11 Aaron Puchert 2019-09-11 22:58:02 UTC
(In reply to Richard Biener from comment #10)
> (In reply to Aaron Puchert from comment #9)
> > Another solution could be to create some name that is provided by both
> > libstdc++ and libc++ and that is recommended or even required by Clang. I'm
> > not sure if that has the intended effect, but it sounds like it could work.
> 
> That sounds like a good idea.  Maybe clang can simply require
> (libstdc++-devel or libc++-devel)?  Will clang automatically pick libc++
> if libstdc++ isn't installed?

I think I'll just recommend libstdc++-devel, as it's also the default standard library under Linux [1]. I don't want to require it (because then Clang would not be installable without it and it's not required for C developers). Something like my idea or the 'or' approach probably makes things less predictable and might lead to weird inconsistencies.

Then most users will get libstdc++-devel, and those that don't want it can still remove (and possibly replace) it.

> Also compatibility with clang isn't something GCC cares much about so
> you might end up with a non-working setup for clang by installing an
> additional GCC compiler.

I think you're right that there could be issues, but I'd like to postpone changes until we hit them. The libstdc++ version is derived from a detected GCC instance [2], and if there are issues we could just patch the detection to reject newer versions. [3]

It's some time since I've last read libstdc++ source code, but my impression was that everything that requires new language features is carefully #ifdef'd and so are more recent compiler builtins.

> I don't have a very good suggestion here but eventually the package should
> default to a build-time chosen variant, make sure that variant is installed
> via a Requires but offer some way to "configure" an alternate version at
> use-time (via alternatives maybe?).  IIRC upstream doesn't have a
> --with-libstdc++=/path/to/fixed/libstdc++/version

I'm not aware of any such option either, one would have to pass the headers and linker options manually to the compiler.

[1] https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc4/clang/lib/Driver/ToolChains/Linux.cpp#L457-L461
[2] https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc4/clang/lib/Driver/ToolChains/Linux.cpp#L904-L957
[3] https://github.com/llvm/llvm-project/blob/llvmorg-9.0.0-rc4/clang/lib/Driver/ToolChains/Gnu.cpp#L2377-L2410