I've found that a small C++ project, with no dependencies, won't compile under Cygwin with either GCC or Clang. Under Ubuntu there are no problems; and I've been working with this code for a couple of years. I'll introduce a MWE.
The problem arises when including a header in a subdirectory, which itself includes another header, found in that same subdirectory, but specified with the subdirectory in the path provided to the include directive. Executing the following commands can replicate the error:
mkdir foo
echo \#include \"foo/includes.hpp\" > inc.hpp
echo \#include \"foo/bar.hpp\" > foo/includes.hpp
touch foo/bar.hpp
g++ -c inc.hpp
On 64-bit Ubuntu 18.10, the final GCC (or Clang) invocation will produce no errors. On 64-bit Cygwin under Windows 10, the following error message is displayed.
In file included from inc.hpp:1:0:
foo/includes.hpp:1:10: fatal error: foo/bar.hpp: No such file or directory
#include "foo/bar.hpp"
^~~~~~~~~~~~~
compilation terminated.
Can anyone shed some light on the issue? (By the way, I myself do well understand how to properly include header files - this is about the difference between Cygwin and Ubuntu.)
foo/includes.hppshould have local includes if you use "".
That would be:
#include "bar.hpp"
The specification for what paths are used for searching headers is custom for all compilers, although includes with "" should be considered as local for the file where you have the include, not the one that you are compiling.
Basically, it's:
look in the current folder of the current header being processed for a file with that name
use the same paths as <>after
Of course, as I've said, this could change for a new compiler one day. But it is quite safe to assume that this is the behavior for all compilers (What is the difference between #include <filename> and #include "filename"?).
Related
I am following the course "Introduction to Deep Learning with Xilinx SoCs Technical Training Course" for the Ultra96v2 board and reached Lab No. 5.
I am able to follow along until I am supposed to build the project in the SDK.
It fails and tells me errors like these:
15:49:06 **** Incremental Build of configuration Debug for project mnist_file_io ****
make all
Building file: ../src/mnist_file_io.cc
Invoking: ARM v8 Linux g++ compiler
aarch64-linux-gnu-g++ -Wall -O0 -g3 -I/media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/training/AvnetTTC/DPU/U96AI_student_20200115/U96AI/2018_3/work/lab5/workspace/ExtraIncludes -I/usr/include -c -fmessage-length=0 -MT"src/mnist_file_io.o" --sysroot=YSROOT -MMD -MP -MF"src/mnist_file_io.d" -MT"src/mnist_file_io.o" -o "src/mnist_file_io.o" "../src/mnist_file_io.cc"
In file included from ../src/mnist_file_io.cc:9:0:
/tools/Xilinx/SDK/2018.3/gnu/aarch64/lin/aarch64-linux/aarch64-linux-gnu/include/c++/7.3.1/cmath:45:15: fatal error: math.h: No such file or directory
#include_next <math.h>
^~~~~~~~
compilation terminated.
src/subdir.mk:21: recipe for target 'src/mnist_file_io.o' failed
make: *** [src/mnist_file_io.o] Error 1
It doesnt find the header file, although it is included in the paths which were provided by the tutorial as well as by me. Actually, two additional files haven't been found:
#include <opencv2/opencv.hpp>
#include <dnndk/dnndk.h>
I was able to include them by picking them by hand from the directories where they were in and adding them to an extra directory in which the Xilinx SDK should search for headers.
But this brings up the question: Why aren't they found in the first place? After correct installation and following the instructions in the above mentioned tutorial, shouldn't I be all set up to just build it?
Actually, by using the installer on the Xilinx Download website (Xilinx_SDK_2018.3_1207_2324_Lin64.bin), the SDK didn't start because there were some files missing for the SDK program (eclipse and some other stuff). So it just started once I copied those files from the other installation (Vivado, etc.). Isn't this also supposed to work just out of the box? Reinstalling, etc. didn't work unfortunately.
So I guess one question that crystallizes here is: Is there a possibility to give Eclipse/Xilinx SDK a path to a directory for all required standard header files and it searches in them? Because in some standard headers, they include other headers, which in turn aren't found by the Xilinx SDK. And will that fix my issues?
Funnily enough, when I use the Ctrl+Click action to jump from header to header, all headers are found and it's no problem. It's only in the build process where embedded further headers aren't found anymore. Also, when I change the #include_next to #include, the whole thing starts working again. The same with changing #include <header> to #include "header.h". Then it works. But that can't be the solution, changing every header that throws an error, since it was generated like this for a reason, right?
This is really annoying and disrupts any workflow.
Is there someone who had this problem as well and may help me?
I am using Ubuntu 16.04 and the Ultra96v2 board.
Update
What I've investigated so far with no avail:
https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/993711/cc3235sf-why-is-ccs-eclipse-unable-to-see-the-c-standard-header-files
Eclipse can't find header file, even though include paths are set
Where are the headers of the C++ standard library
https://www.eclipse.org/forums/index.php/t/1088833/
I have included the path for my C++ gcc standard library as a path in which Eclipse/the Xilinx IDE is supposed to search for headers, but the headers inside the files aren't being found.
Update 2
Here you can see where the problem starts. It's really weird, since everything is auto-generated and thus should just work, especially since those are predefined headers and sources, which haven't been altered by me.
Here, you can see that I included the usual standard header location in the inclusion paths, so the files in question should be found.
I am unable to compile a C project that uses a library called "FFmpeg" with a compiler called "GCC", and I believe it might be either because I don't quite understand how #include works or because I am using the wrong compilation process.
In a folder called Test, I have a file Test/test.c with the following contents:
#include <stdio.h>
#include <stdlib.h>
#include "FFmpeg/libavcodec/avcodec.h"
The folder FFmpeg is located at Test/FFmpeg. When I try to compile this with GCC, I receive the following error:
fatal error: libavutil/samplefmt.h: No such file or directory
The file Test/FFmpeg/libavcodec/avcodec.h has the following code in it:
#include "libavutil/samplefmt.h"
#include "libavutil/attributes.h"
#include "libavutil/avutil.h"
... //many more #include statements
Is the issue here that I need to add "FFmpeg/" to all of these include statements?
If so, is there a way to automatically do this? This library is enormous and probably has hundreds of these statements.
If not, what should I be doing instead? Should I attempt to compile the library by itself? If so, how do I then include this compiled version of the library in my program?
Notes:
The command I am using to compile is gcc -c test.c.
I have GCC installed via MinGW.
I ultimately need to be able to compile this program to both a .dll and an .so.
I apologize if any of the terminology I use here is incorrect or if my explanations are poor. I know almost nothing about compilation. Please let me know if I need to fill in more information.
When #include is used with quotation marks (e.g. #include "file path here"), it will read that file path as a relative file path.
In the case of compiling a C program using GCC, file paths are relative to the current directory. The "current directory" is the one into which you have placed your command prompt using the cd command.
In my case, I cd'd into C:/Users/User/Documents/Test, meaning that all relative file paths are relative to C:/Users/User/Documents/Test. So when my compiler read
#include "libavutil/samplefmt.h"
it basically tried to do this:
#include C:/Users/User/Documents/Test/libavutil/samplefmt.h
when I instead needed the compiler to look at …/Test/FFmpeg/libavutil/samplefmt.h.
It turns out that the solution to this is to give the compiler additional locations to which relative paths might be relative. This is done with the -I[file path here] argument when you compile.
In my case, the way I needed to use this idea was to add C:/Users/User/Documents/Test/FFmpeg as a location to which paths might be relative. Thus, I could have taken my compile command:
gcc -c test.c
And inserted this:
gcc -IC:\Users\User\Documents\Test\FFmpeg -c test.c
However, this is actually an extremely clunky solution. There is a much easier way: it turns out that these file paths you provide with the -I argument can be relative to your current directory themselves. In my case, because my current directory in the command prompt was alreadyC:/Users/User/Documents/Test, I could simply remove this portion from the above command, shortening it to this:
gcc -IFFmpeg -c test.c
And this solved my problem.
I am trying to cross-compile OpenImageIO for 64-bit Windows on Fedora 26 using MinGW. After using yum to retrieve the mingw versions of the dependencies, I ran mingw64-cmake followed by make. However, right away I receive a compile error about stdlib.h not being found.
[ 0%] Built target CopyFiles
[ 0%] Building CXX object src/libutil/CMakeFiles/OpenImageIO_Util.dir/argparse.cpp.obj
In file included from .../oiio/src/libutil/argparse.cpp:36:0:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^~~~~~~~~~
compilation terminated.
I have confirmed that stdlib.h is found at least in /usr/include/ and in /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ where the file giving the compiler error also is located.
Why do I still receive the error stdlib.h: No such file or directory?
Update:
I did additional research and learned the following: The preprocessor directive #include_next behaves like the #include directive, except that it specifically excludes the directory of the including file from the paths to be searched for the named file.
This would explain why cstdlib does not find stdlib.h from the same folder. But cstdlib is part of MinGW and not any part of the code I am trying to compile. So I still have no idea what is wrong here or how to fix this error.
Edit: Here is the compiler version info in case it is of any use: https://pastebin.com/PZiXS2fg. This is a fresh install so there shouldn't be anything unusual there, though.
I solved it, i can compile again.
The solution (for me) is add to path the variable CPLUS_INCLUDE_PATH and set it to the MinGW c++ include directory, for me: C:\MinGW\lib\gcc\mingw32\6.3.0\include\c++.
I hope it works for you too.
The use of #include_next appears to cause lots of issues based on my Googling. Try directly including stdlib.h using the following syntax:
-isystem /usr/x86_64-w64-ming32/sys-root/mingw/include/c++
This syntax was added in gcc 6.0 to solve issues with third-party libraries. See here for the approach and reasoning.
Edit: Changed answer to reflect new information about gcc wrapper_headers and #include_next
I'm trying to understand how to compile C++ programs from the command line using g++ and (eventually) Clang on Ubuntu.
I found a webpage which explains MakeFiles and I am following their directions. http://mrbook.org/tutorials/make/
I downloaded the four example files into their own directory.
main.cpp
hello.cpp
factorial.cpp
functions.h
I then went ahead and ran their example of how to manually compile without a MakeFile.
g++ main.cpp hello.cpp factorial.cpp -o hello
When I ran the command from above, I received the following error from g++:
main.cpp:1:22: fatal error: iostream.h: No such file or directory
compilation terminated.
hello.cpp:1:22: fatal error: iostream.h: No such file or directory
compilation terminated.
My only experience with writing c++ is using an IDE such as VS C++ Express or CodeBlocks. Isn't the compiler supposed to know what iostream.h is and where to find it?
How do I get rid of this error so the program willl compile?
Thanks for any help.
Before the C++ language was standardized by the ISO, the header file was named <iostream.h>, but when the C++98 standard was released, it was renamed to just <iostream> (without the .h). Change the code to use #include <iostream> instead and it should compile.
You'll also need to add a using namespace std; statement to each source file (or prefix each reference to an iostream function/object with a std:: specifier), since namespaces did not exist in the pre-standardized C++. C++98 put the standard library functions and objects inside the std namespace.
<iostream.h> has never been a standard C++ header, because it did not make it into the C++ standard.
Instead we got <iostream>, in 1998.
Steer well clear of teaching material using non-standard stuff such as <iostream.h> or void main.
However, as a practical solution for your current pre-standard code, you may try to replace
#include <iostream.h>
with
#include <iostream>
using namespace std;
It’s not guaranteed to work, but chances are that it will work.
Another related issue that wasn't mentioned here, so I will include it for anyone's future reference, is from the command line the compiler needs the environment path variable updated to find the location of the c++ header files. In windows you can just update the path environment using the 'advanced system properties' GUI and add the location of the c++ include files. This will update the PATH environment variable in Windows cmd & Cygwin automatically upon restarting the shell.
To update your PATH from Linux or the Cygwin shell type...
PATH=$PATH:/your_path_here
Example:PATH=$PATH:/cygdrive/c/cygwin/lib/gcc/i686-pc-mingw32/4.7.3/include/c++
Also a good idea to add just the include directory as well:
PATH=$PATH:/cygdrive/c/cygwin/lib/gcc/i686-pc-mingw32/4.7.3/include/
...or check the proper directories for the location of your installation's include files, I recommend installing mingw for use with Cygwin, which is envoked with g++.
To install additional needed packages in Cygwin re-run the Cygwin install utility & check install from Internet to add packages from web repositories and add mingw-gcc-g++ & mingw-binutils.
To compile: g++ hello.cpp -o hello
If using the gcc utility instead compile with the command:
gcc hello.cpp -o hello -lstdc++
... to get your executable.
As long as you have either gcc or mingw installed and the path to the c++ include files is in your path environment variable, the commands will work.
I'm experiencing an extremely weird problem in a fresh OSX 10.4.11 + Xcode 2.5 installation. I've reduced it to a minimal test case. Here's test.cpp:
#include "macros.h"
int main (void)
{
return 1;
}
And here's macros.h:
#ifndef __JUST_TESTING__
#define __JUST_TESTING__
template<typename T> void swap (T& pT1, T& pT2)
{
T pTmp = pT1;
pT1 = pT2;
pT2 = pTmp;
}
#endif //__JUST_TESTING__
This compiles and works just fine if both files are in the same directory. HOWEVER, if I put macros.h in /usr/include/gfc2 (it's part of a custom library I use) and change the #include in test.cpp, compilation fails with this error :
/usr/include/gfc2/macros.h:4: error: template with C linkage
I researched that error and most of the comments point to a "dangling extern C", which doesn't seem to be the case at all.
I'm at a complete loss here. Is g++ for some reason assuming everything in /usr/include/gfc2 is C even though it's included from a .cpp file that doesn't say extern "C" anywhere?
Any ideas?
EDIT : It does compile if I use the full path in the #include, ie #include "/usr/include/gfc2/macros.h"
EDIT2 : It's not including the wrong header. I've verified this using cpp, g++ -E, and renaming macros.h to foobarmacros.h
G++ may well indeed be assuming that everything in /usr/include is C. Try compiling your code with -E and studying the line markers in the preprocessor output:
g++ -E test.cpp | grep '^#'
You'll likely see things like
# 1 "/usr/include/gfc2/macros.h" 1 3 4
The 4 is the preprocessor hinting to G++ that it should wrap everything in extern "C", on the supposition that your platform's ancient header files in /usr/include predate C++. See Preprocessor Output in the CPP manual.
These days G++ mostly ignores this hint, because most platforms' C headers are no longer ancient. See the NO_IMPLICIT_EXTERN_C target macro in the GCC Internals manual. But it may be that this old version of Xcode has GCC configured without NO_IMPLICIT_EXTERN_C and thus is listening to the preprocessor's hint. (This is set when GCC itself is built -- I don't think there's a command-line switch to override it.)
You may be able to work around this by wrapping the contents of your header file in extern "C++".
This is a shot in the dark, but is there another file named macros.h somewhere under /usr/include or in your GCC installation? GCC has a facility for wrapping headers, called #include_next, which might be the cause of your problem.
One thing you can do to disambiguate your macros.h from any other macros.h in the include path is to include it as gfc2/macros.h. This way, the compiler will search every directory in the include path for a subdirectory named gfc2 containing a file named macros.h, reducing the chance of a collision. It also prevents you from having to add /usr/include/gfc2 to the include path.
BTW, #include "file.h" searches the current directory first. To skip that and go straight to the include path, use #include <file.h>:
#include <stdio.h>
#include <gfc2/macros.h>
Another approach is to choose a filename that is more likely to be unique, like gfc2macros.h.
Well, it really looks weird...
How does XCode calls g++?
I don't think g++ spontaneously decides that an include file has C linkage just because it's in a different directory. Did you try to compile your project by hand?
Try "g++ main.cpp -I/usr/include/gfc2/". If this solves your problem than it's not g++. Maybe does XCode precompile headers?
Have you tried not changing the test.cpp file at all, but instead when you compile also say:
-I/usr/include/gfc2/
You can see where g++ is looking for includes with the verbose flag:
g++ -v -o test test.cpp
And this will just run the preprocessor and show what is actually included in the file and compiled:
g++ -E test.cpp | less
If the wrong files are getting included (or your header is getting wrapped in another, as bk1e suggests) you'll be able to find out with that output.
I just ran into this issue as well when compiling a C++ project that we normally build on 10.5 and 10.6 (Xcode 3.0+) on a 10.4 PPC machine with Xcode 2.5 installed. It looks as if the preprocessor treats anything added to the gcc include path with '-isystem' as if it should be "extern C". Changing '-isystem' to '-I' resolved the issue.