Ошибка iostream file not found

I wrote the following simple C++ program:

#include <iostream>

using namespace std;

int main() {
    cout << "Hello, World" << endl;
    return 0;
}

When I compile this with g++, it works perfectly. When I try to compile with Clang++, I get the following error:

main.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated.

Running with the -v parameter, I see the following:

ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/backward"
ignoring nonexistent directory "/include"
ignoring duplicate directory "/usr/include/clang/6.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++
 /usr/include/clang/6.0.0/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

Looking into these folders individually, I found that in /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++ (or, more concisely, in /usr/include/c++) I have the following directories:

drwxr-xr-x   5 root root 4.0K Feb  4 09:38 .
drwxr-xr-x 101 root root  20K Feb  4 12:22 ..
drwxr-xr-x  12 root root  12K May 24  2018 5
drwxr-xr-x  12 root root  12K Oct  9 14:53 7
drwxr-xr-x   5 root root 4.0K Feb  4 09:38 v1
lrwxrwxrwx   1 root root    1 Apr 11  2018 5.5.0 -> 5
lrwxrwxrwx   1 root root    1 Apr 15  2018 7.3.0 -> 7

Within each of the 5, 7, and v1 directories there exists a file called iostream

Also in /usr/include/x86_64-linux-gnu there exists a c++ directory which looks exactly like this one (with 5, 7, 5.5.0, and 7.3.0 directories).

Also in /usr/include there exists a c++ directory which looks exactly like the two above

I’m not sure how my dev environment became such a mess, but at this point I would just like to know how to fix it so that Clang++ will successfully find one of these 9 instances of iostream instead of throwing an error that it doesn’t exist. Do I need to add an environment variable to tell Clang where to look? Do I need to pass a command-line parameter to tell Clang to search recursively?

Update (1)

When I try building with libc++ I get the following error:

$> clang++ -stdlib=libc++ main.cpp
/usr/bin/ld: cannot find -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)

When I try building with the include path manually overridden, I get the following error:

$> clang++ -isystem /usr/include/c++/7 -isystem /usr/include/x86_64-linux-gnu/c++/7 main.cpp
/usr/bin/ld: cannot find -lstdc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)

When I try both, I get the following (incredibly large) error:

$> clang++ -isystem /usr/include/c++/7 -isystem /usr/include/x86_64-linux-gnu/c++/7 -stdlib=libc++ main.cpp
In file included from main.cpp:1:
In file included from /usr/include/c++/7/iostream:39:
In file included from /usr/include/c++/7/ostream:38:
In file included from /usr/include/c++/7/ios:42:
In file included from /usr/include/c++/7/bits/ios_base.h:41:
In file included from /usr/include/c++/7/bits/locale_classes.h:40:
In file included from /usr/include/c++/7/string:52:
In file included from /usr/include/c++/7/bits/basic_string.h:6352:
In file included from /usr/include/c++/7/ext/string_conversions.h:41:
In file included from /usr/include/c++/7/cstdlib:77:
/usr/include/c++/7/bits/std_abs.h:56:3: error: declaration conflicts with target of using declaration already in scope
  abs(long __i) { return __builtin_labs(__i); }
  ^
/usr/include/c++/v1/stdlib.h:111:44: note: target of using declaration
inline _LIBCPP_INLINE_VISIBILITY long      abs(     long __x) _NOEXCEPT {return  labs(__x);}
                                           ^
/usr/include/c++/7/bits/std_abs.h:52:11: note: using declaration
  using ::abs;
          ^
/usr/include/c++/7/bits/std_abs.h:61:3: error: declaration conflicts with target of using declaration already in scope
  abs(long long __x) { return __builtin_llabs (__x); }
  ^
/usr/include/c++/v1/stdlib.h:113:44: note: target of using declaration
inline _LIBCPP_INLINE_VISIBILITY long long abs(long long __x) _NOEXCEPT {return llabs(__x);}
                                           ^
/usr/include/c++/7/bits/std_abs.h:52:11: note: using declaration
  using ::abs;
          ^
In file included from main.cpp:1:
In file included from /usr/include/c++/7/iostream:39:
In file included from /usr/include/c++/7/ostream:38:
In file included from /usr/include/c++/7/ios:42:
In file included from /usr/include/c++/7/bits/ios_base.h:41:
In file included from /usr/include/c++/7/bits/locale_classes.h:40:
In file included from /usr/include/c++/7/string:52:
In file included from /usr/include/c++/7/bits/basic_string.h:6352:
In file included from /usr/include/c++/7/ext/string_conversions.h:41:
/usr/include/c++/7/cstdlib:177:3: error: declaration conflicts with target of using declaration already in scope
  div(long __i, long __j) { return ldiv(__i, __j); }
  ^
/usr/include/c++/v1/stdlib.h:116:42: note: target of using declaration
inline _LIBCPP_INLINE_VISIBILITY  ldiv_t div(     long __x,      long __y) _NOEXCEPT {return  ldiv(__x, __y);}
                                         ^
/usr/include/c++/7/cstdlib:145:11: note: using declaration
  using ::div;
          ^

As a reminder, I’m literally just trying to compile Hello, World

I also tried uninstalling and re-installing Clang with the following command:

$> sudo apt-get purge --auto-remove clang
$> sudo apt-get update
$> sudo apt-get install clang

This had no effect. I’m running Ubuntu 18.04 and I have no idea what’s wrong or where to start with fixing it. My build environment is in shambles.

If possible I would like to get Clang working instead of falling back to using G++, because my IDE seems to be automatically detecting Clang and using it for syntax checking. This means that every C++ program I’ve written has one fatal error on line one («iostream not found») and the rest of the file goes unchecked because that first one is a fatal error.

Update (2)

I’ve tried installing a few more packages from the Ubuntu apt repository with no luck:

$> sudo apt-get install libc++1 libc++1-9 libc++abi1 libc++abi1-9 llvm-9 llvm-9-dev
$> clang++ -isystem /usr/include/c++/7 -isystem /usr/include/x86_64-linux-gnu/c++/7 -stdlib=libc++ main.cpp
/usr/bin/ld: cannot find -lc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I also tried sudo apt-get install lc++1 only to find this is an entirely unrelated package.

Update (3)

I spent several more hours trying to resolve this, installing multiple packages both from apt and from source, trying different versions of various tools, manually copying in libraries from other sources, and even hopped onto the Clang IRC and spoke to several very knowledgeable developers directly.

No one was able to figure out what’s wrong with my laptop, and nothing I did ever got it working.

Unfortunately I won’t still have this laptop in another two weeks, so I’ll likely need to close this issue as «cannot reproduce» — because once the laptop is gone I will have no way of replicating the broken development environment.

You’re dealing with a pre-standard C++ library, and you’ve seen it won’t compile with a standard compiler. You can always try the quick work-around by creating, say, iostream.h with the two lines #include <iostream> and using namespace std;, and that may work. It isn’t reliable, and may cause hard-to-find bugs that will appear at an inconvenient time.

If this is a library from somewhere else, you could see if it’s been updated.

The thing to realize is that the code isn’t correct anymore. It may have been correct for some implementation at some time, but it isn’t now. (Are you sure it was originally for gcc 3.0? Pre-standard compilers were, well, not standard, and had a lot of oddities. Avoiding that is what standards are for.) If you do install the original system, you may be unable to interface with the library properly, and new code isn’t going to work. A library that doesn’t interface with modern code is of limited use.

Otherwise, you’re going to have to abandon the attitude that you can’t change the library, and convert it to standard C++. There will likely be quite a few bugs that are fairly easy to fix (like the scope in for (int i = 0;...)), and may be some subtler problems. The code may have been correct for a certain compiler, but it isn’t now.