My situation. uname -a gives Linux computer2 4.4.0-62-generic #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I am trying to install HDF5 1.8.18 with GNU make 3.81 invoking gcc 6.3.0. I have successfully installed this gcc 6.3.0 alongside the version 4.8.4 that is shipped with the Ubuntu distribution.
My gcc 6.3.0 lives in /opt/gcc/6_3_0/. I use the following script to configure and pass on the commands, libraries and headers in non-standard directories:
export FC='/opt/gcc/6_3_0/bin/gfortran-6.3.0' # probably unnecessary
export CC='/opt/gcc/6_3_0/bin/gcc-6.3.0'
export CXX='/opt/gcc/6_3_0/bin/g++-6.3.0'
export CPP='/opt/gcc/6_3_0/bin/cpp-6.3.0'
export LDFLAGS='-L/opt/gcc/6_3_0/lib -L/opt/gcc/6_3_0/lib64'
export CPPFLAGS='-I/opt/gcc/6_3_0/include -I/opt/gcc/6_3_0/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include'
./configure
--prefix=${insdir}
--with-zlib=${zlibdir}/include,${zlibdir}/lib
--enable-fortran
--enable-cxx
where ${insdir} is an installation directory, ${zlibdir} is where zlib lives and the other switches are standards as per the installation guidelines
The configure step goes well. The make step fails with the error:
make[2]: Entering directory `<the source directory>/hdf5-1.8.18/c++/src'
CXX H5Exception.lo
H5Exception.cpp:16:18: fatal error: string: No such file or directory
#include <string>
^
compilation terminated
If I understand it correctly, some header file is missing, and of a basic nature.
- Where should I get it from?
- Is there any flaw in the names and values of the environment variables?
StackExchange contains a host of posts on this error, but they seem to be mostly related to coding exercises. My aim is not to edit codes, rather to compile source codes successfully with my vanilla gcc 6.3.0.
Updated question
In the light of the helpful comments and Thomas Dickey’s answer below, it appears that a promising avenue is to install matching versions of libstdc++ and gcc. I have searched around in the GCC website and it appears that one can configure gcc with the following switch
—enable-version-specific-runtime-libs
Specify that runtime libraries should be installed in the compiler specific subdirectory (libdir/gcc) rather than the usual places. In addition, libstdc++’s include files will be installed into libdir unless you overruled it by using —with-gxx-include-dir=dirname. Using this option is particularly useful if you intend to use several versions of GCC in parallel. This is currently supported by ‘libgfortran’, ‘libstdc++’, and ‘libobjc’.
- Is this pointing in the right direction?
- Where would I be supposed to find the libstdc++’s include files that are distributed alongside the source of gcc, if this is switch is not used?
I’m trying to work my way through Linux From Scratch. I am running into the compiler:
error : string.h: No such file or directory
when trying to compile gcc for the target system as per Chapter 5: gcc-4.8.1-pass 1.
More details about the error:
-fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS
/mnt/lfs/sources/gcc-build/./gcc/xgcc -B/mnt/lfs/sources/gcc-build/./gcc/
-B/tools /x86_64-lfs-linux-gnu/bin/ -B/tools/x86_64-lfs-linux-gnu/lib/
-isystem /tools/x86_64- lfs-linux-gnu/include
-isystem /tools/x86_64-lfs-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include
-fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -fpic -mlong-double-80 -I. -I. -I../.././gcc -I../../../gcc-4.8.1/libgcc
-I../../../gcc-4.8.1/libgcc/.
-I../../../gcc-4.8.1/libgcc/../gcc -I../../../gcc-4.8.1/libgcc/../include -I../../../gcc-4.8.1/libgcc/../libdecnumber/no -I../../../gcc-4.8.1/libgcc/../libdecnumber -DHAVE_CC_TLS -DUSE_TLS -o decContext.o
-MT decContext.o -MD -MP -MF decContext.dep -c ../../../gcc-4.8.1/libgcc/../libdecnumber/decContext.c
../../../gcc-4.8.1/libgcc/../libdecnumber/decContext.c:33:43: fatal error: string.h: No such file or directory
#include /* for strcmp /
^
compilation terminated.
make[2]: [decContext.o] Error 1
make[2]: Leaving directory/mnt/lfs/sources/gcc-build/x86_64-lfs-linux-gnu/libgcc'/mnt/lfs/sources/gcc-build’
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory
make: * [all] Error 2
Additional information that might be of use:
- I am running ubuntu linux with gcc 4.8.1
- I have installed the build-essential package and it is the most recent version
- The file string.h is present
Thanks in advance for any help.
This is the code I am running:
../gcc-4.8.1/configure
--target=$LFS_TGT
--prefix=/tools
--with-sysroot=$LFS
--with-newlib
--without-headers
--with-local-prefix=/tools
--with-native-system-header-dir=/tools/include
--disable-nls
--disable-shared
--disable-multilib
--disable-decimal-float
--disable-threads
--disable-libatomic
--disable-libgomp
--disable-libitm
--disable-libmudflap
--disable-libquadmath
--disable-libsanitizer
--disable-libssp
--disable-libstdc++-v3
--enable-languages=c,c++
--with-mpfr-include=$(pwd)/../gcc-4.8.1/mpfr/src
--with-mpfr-lib=$(pwd)/mpfr/src/.libs
then it breaks on make. I am executing this command from $LFS/sources/gcc-build. gcc-4.8.1 is located in $LFS/sources.
Asked
8 years, 2 months ago
Viewed
63k times
I wrote the program kai.c and now am trying to compile it with gcc kai.c -o kai, which returns:
kai.c:5:18: fatal error: string: No such file or directory
#include <string>
^
compilation terminated.
What can I do?
gcc version is: (Ubuntu 4.8.2-19ubuntu1) 4.8.2
αғsнιη
34.6k39 gold badges126 silver badges189 bronze badges
asked Nov 28, 2014 at 17:13
2
#include <string> is a C++ directive.
Rename your file to kai.cpp
And compile it with g++ kai.cpp -o kai
αғsнιη
34.6k39 gold badges126 silver badges189 bronze badges
answered Nov 28, 2014 at 17:15
Oli♦Oli
286k115 gold badges669 silver badges829 bronze badges
3
C
The string library is the file string.h, so:
#include "string.h"
Example:
#include "string.h"
#include "stdio.h"
void main(){
char src[2] = "Hi";
char dest[2];
strcpy(dest, src);
printf("%sn", dest); // Will print Hi
}
answered Nov 28, 2014 at 18:01
LucioLucio
18.4k31 gold badges104 silver badges190 bronze badges
Introduction
In this intermittent series, I’ll be looking at the most common error messages your C++ compiler (and linker) can produce, explaining exactly what they mean, and showing how they can be fixed (or, better still avoided). The article will specifically talk about the errors produced by the GCC command line compiler, but I’ll occasionally provide some coverage of Microsoft C++ as well. The articles are aimed at beginner to intermediate C++ programmers, and will mostly not be OS-specific.
Error Messages 101
Compiler error messages from the GCC g++ compiler generally look like something this:
main.cpp: In function 'int main()': main.cpp:4:12: error: 'bar' was not declared in this scope
which was produced by this code:
int main() {
int foo = bar;
}
The first line of the error says which function the following error(s) is in. The error message itself comes in four main parts; the file the error occurs in, the line number and character offset at which the compiler thinks the error occurs, the fact that it is an error, and not a warning, and the text of the message.
As well as error, the compiler can also produce warnings. These are usually about constructs that, while not being actually illegal in C++, are considered dubious, or constructs that the compiler has extensions to cover. In almost all cases, you don’t want to use such constructs, and you should treat warnings as errors; in other words, your code should always compile with zero warnings. You should also increase the level of warnings from the compiler’s default, which is usually too low. With g++, you should use at least the -Wall and -Wextra compiler options to do this:
g++ -Wall -Wextra myfile.cpp
No such file or directory
The error I’m looking at today most commonly occurs when you are including a header file using the preprocessor #include directive. For example, suppose you have the following code in a file called myfile.cpp:
#include "myheader.h"
and you get the following error message:
myfile.cpp:1:22: fatal error: myheader.h: No such file or directory compilation terminated.
What could be causing it? Well, the basic cause is that the compiler cannot find a file called myheader.h in the directories it searches when processing the #include directive. This could be so for a number of reasons.
The simplest reason is that you want the compiler to look for myheader.h in the same directory as the myfile.cpp source file, but it can’t find it. this may be because you simply haven’t created the header file yet, but the more common reason is that you either misspelled the header file name in the #include directive, or that you made a mistake in naming the header file when you created it with your editor. Look very closely at the names in both the C++ source and in your source code directory listing. You may be tempted to think «I know that file is there!», but if the compiler says it isn’t there, then it isn’t, no matter how sure you are that it is.
This problem is somewhat greater on Unix-like system, such as Linux, as there file names are character case sensitive, so Myheader.h, MyHeader.h, myheader.h and so on would all name different files, and if you get the case wrong, the compiler will not look for something «similar». For this reason, a very good rule of thumb is:
Never use mixed case when naming C++ source and header files. Use only alphanumeric characters and the underscore when naming C+++ files. Never include spaces or other special characters in file names.
Apart from avoiding file not found errors, this will also make life much easier if you are porting your code to other operating systems which may or may not respect character case.
The wrong directory?
Another situation where you may get this error message is if you have split your header files up from your C++ source files into separate directories. This is generally good practice, but can cause problems. Suppose your C++ project is rooted at C:/myprojects/aproject, and that in the aproject directory you have two sub-directorys called src (for the .cpp files) and inc (for the header files), and you put myfile.cpp in the src directory, and myheader.h in the inc directory, so that you have this setup:
myprojects
aproject
inc
myheader.h
src
myfile.cpp
Now if you compile the source myfile.cpp from the src directory, you will get the «No such file or directory» error message. The C++ compiler knows nothing about the directory structures of your project, and won’t look in the inc directory for the header. You need to tell it to look there somehow.
One thing some people try when faced with this problem is to re-write myfile.cpp so it looks like this:
#include "c:/myprojects/aproject/inc/myheader.h"
or the slightly more sophisticated:
#include "../inc/myheader.h"
Both of these are a bad idea, as they tie your C++ code to the project’s directory structure and/or location, both of which you will probably want to change at some point in the future. If the directory structure does change, you will have to edit all your #include directories.The better way to deal with this problem is to tell the compiler directly where to look for header files. You can do that with the compiler’s -I option, which tells the compiler to look in the specified directory, as well as the ones it normally searches:
g++ -Ic:/myprojects/aproject/inc myfile.cpp
Now the original #include directive:
#include "myheader.h"
will work, and if your directory structure changes you need only modify the compiler command line. Of course, writing such command lines is error prone, and you should put such stuff in a makefile, the use of which is unfortunately outside the scope of this article.
Problems with libraries
Somewhat similar issues to those described above can occur when you want to use a third-party library. Suppose you want to use the excellent random number generating facilities of the Boost library. If you are copying example code, you may well end up with something like this in your C++ source file:
#include "boost/random.hpp"
This will in all probability lead to yet another «No such file or directory» message, as once again the compiler does not know where «boost/random.hpp» is supposed to be. In fact, it is one of the subdirectories of the Boost installation, and on my system I can get the #include directive to work using this command line:
g++ -Ic:/prog/boost1461 myfile.cpp
where /prog/boost1461 is the root directory for my specific Boost library installation.
Can’t find C++ Standard Library files?
One last problem that beginners run into is the inability of the compiler to find header files that are part of the C++ Standard Library. One particular favourite is this one:
#include <iostream.h>
where you are learning C++ from a very, very old book. Modern C++ implementations have not contained a file called iostream.h for a very long time indeed, and your compiler is never going to find it. You need to use the correct, standard names for such headers (and to get a better book!):
#include <iostream>
If this still fails, then there is almost certainly something very wrong with your GCC installation. The GCC compiler looks for Standard Library files in a subdirectory of its installation, and locates that directory relative to the directory containing the compiler executable, so if the Standard Library headers are available, the compiler should always find them.
Conclusion
This article looked at the «No such file or directory» message of the GCC C++ compiler. If you get this message you should:
- Remember that the compiler is always right in situations like this.
- Look very closely at the file name to make sure it is correct.
- Avoid naming file using mixed-case or special characters.
- Use the -I compiler option to tell the compiler where to look for files.
- Make sure that GCC is correctly installed on your system.
|
Hello I saw when "main.cpp" is not accessible, the standard ENOENT message "No such file or directory" is used. However, this is not really accurate, as it was open() that was used to open a file. A file was expected, therefore if GCC could output "No such file" the message would be clearer. I objdump has this behaviour already: $ objdump -a main2.exe objdump: 'main2.exe': No such file $ gcc --version gcc (GCC) 4.8.3 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -o main main.cpp gcc: error: main.cpp: No such file or directory gcc: fatal error: no input files compilation terminated.
Can you figure out using GDB where the error comes from? I guess somewhere in gcc.c.
GCC uses strerror (indirectly) for printing error messages, through the use of %m with vfprintf. This is done in many separate locations. binutils has special cases in the form of (if ENOENT then print custom message else print system error).
The GNU Coding Standards (http://www.gnu.org/prep/standards/html_node/Semantics.html) say:
> Include the system error text (from perror, strerror, or equivalent) in every error message resulting from a failing system call, as well as the name of the file if any and the name of the utility.
I do not personally care either way, but GCC's error message is in line with those coding standards, and binutils's error message is not (even if it may be in line with the intent of those coding standards, I make no comment on that). Perhaps either GCC should be left as it is now, or if those coding standards do not correctly reflect the intent, they should be changed first?
"No such file or directory" is a familiar, recognizable error message, and is automatically translated through libc. Is the required complexity for this special case really worth it?
My preference would be a gnulib/glibc/libiberty function that all GNU utilities could use to give more precise error messages (open_strerror(int errnum, int flags)?). Then, perhaps update the Coding Standards to recommend the use of the function. Then, use it in GCC and binutils for consistency (and to avoid translating the same string for each project). The benefit may seem minor to many people (and I guess all existing GCC devs have things to work on that they consider much more crucial). However, somebody went through all the trouble to report a bug, so I would not want to discourage anyone from going ahead and do whatever is needed. Maybe then they will decide to tackle other problems with GCC/binutils (there are plenty to choose from, and help is always welcome). I would like to encourage people to work on GCC, even if, to me, the benefit does not compensate the effort, they may have other priorities. A good example of this is: https://gcc.gnu.org/ml/gcc/2014-10/msg00104.html where someone proposed a controversial change, but a path forward to a solution was offered. That person followed up and a patch is almost ready to be merged: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00845.html
Hi Manu I like your open_strerror() propopsal. Is this how Bintuils has done it? Note: I realise this problem stems from ENOENT being used by both opendir() and open(). I think you only need to provide two wrappers to handle these cases Note: %m is not ideal in my view as it is a C Library extension that I believe is not widely supported. could it be replaced with %s? http://www.gnu.org/software/libc/manual/html_node/Other-Output-Conversions.html Alternatively, could have a check where files are stat() before they are opened, and then report the error then. Likewise for directories.
Two more tests where I try to pass directories to GCC. (1) $ mkdir testdir $ gcc -Wall -Werror -o main testdir testdir: file not recognized: Is a directory collect2: error: ld returned 1 exit status (2) $ mkdir testdir.cpp $ gcc -o main testdir.cpp cc1plus: fatal error: testdir.cpp: No such file or directory compilation terminated. Re (1) output reasonable. Although I don't know why it is getting all the way to LD after the error? Re (2) error handling not quite right, appears to have slipped through, because it had .cpp extension? Perhaps each "filename" could be checked with if (stat(pathname, &sb) == 0 && S_ISDIR(sb.st_mode))
In order to be precise trying to open doesnotexist/foo.c should report "no such directory".
Could add a file_check(const char * path) which checks each component of a path. Would output: error opening doesnotexist/foo.c: doesnotexist: No such directory
(In reply to Jonny Grant from comment #6)
> (2)
> $ mkdir testdir.cpp
>
> $ gcc -o main testdir.cpp
> cc1plus: fatal error: testdir.cpp: No such file or directory
> compilation terminated.
Can files be checked that they are files? a quick stat() on each of them before passing them along?
eg. stat() and then S_ISDIR(statbuf.st_mode) and display strerror(EISDIR), then check if a regular file with S_ISREG(statbuf.st_mode)
|