Recently, I met a very annoying problem. I need to compile some old C++ codes which was compiled with a very old g++ version 4.1.2.
I couldn't find g++ version that old now, so I used g++ 4.4.7 to compile it, but there were many errors like error: ‘snprintf’ was not declared in this scope.
After some work, I found g++ 4.1.2 do NOT distinguish <string> from <string.h>, also <stdio> from <stdio.h>, etc.. But g++ 4.4.7 DOES. So these errors happened.
For some reasons, I couldn't modify the old source code. Is there a way that can make the newer g++ ignore the difference between <string> and <string.h>?
Create a directory in your project (let's call it foo);
Create foo/string and foo/string.h as symlinks to whichever header works;
Add -Ifoo to GCC's compilation flags.
Both symlinks will now be used when you include <string> or <string.h>, and will redirect to the actual system header.
I have seen string and string.h usually implemented as just files (the first string filename is without an extension).
To not include the standard include paths you need to specify: -nostdinc
Related
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"?).
It's been a while since I've dealt with C/C++, so forgive me if this is a ridiculously easy to answer question - I just don't quite know how to "Google" it.
I have a file, "MyFile.h" that includes file "includedFile.h". However, the compiler cannot find the file. Please see below picture:
What I'm doing is moving the project from an old Solaris box to a Linux box. The weird thing is that it worked on the Solaris box as-is but Linux is a little confused.
The makefile that I use for the project hasn't changed either which makes me think that it may be a compiler option...
So how do I tell the compiler on Linux where that include file is, or how do I specify it in "MyFile.h?"
With gcc and clang, you specify the include path using -I:
g++ -o myprogram main.cc extra.cc -I/usr/include/boost -I/my/extra/include/files
You can specify full paths in your files, as in #include "/path/to/my/includedfile.h", but I strongly discourage this as it forces everyone who wants to compile your code to comply with that directory layout.
Also relevant: Read the following link for the difference between #include <file> and #include "file" in gcc: http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
Assuming you are using g++, you pass a path with the -I flag.
g++ ..... -I<a path to your includes> -I<another path to includes>
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.
Are tr1 headers available for g++ v3.4.6? If so, how can I locate them at compile time.
The following is failing to compile:
#include <tr1/memory>
With the following error:
myModule.h:20:24: tr1/memory: No such file or directory
Do I need to move to a later compiler or do I have the headers somewhere?
As an alternative, Boost provides a TR1 implementation too.
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.