I have an iOS project set up like this:
I use XCode 6.1.1
clang -v says LLVM version 6.0
I use the flag -miphoneos-version-min=6.1 (I don't set -std and -stdlib)
Everything's fine.
When I update to -miphoneos-version-min=7.1 I have following errors in code includes the header new.h
Because it is a big project, I have created a new .h file that include new.
The problem is that the new header includes exception that includes type_traits header. 'type_traits' is a c++11 header. Because I am not using C++11, this raises errors.
I don't want to activate c++11 now.
I tried -miphoneos-version-min=7.1 -std=c++98 -stdlib=libc++ but whatever I try, I still have the new header leading to type_traits header leading to errors.
Any idea how can I build with -miphoneos-version-min=7.1? And why when I was with -miphoneos-version-min=6.1 the include new.h was fine (and not including type_traits header)
Related
Completely new project is totally fine, but I found pretty old opensource project and want to compile it. Basically, error appears when including headers like iostream or algorythm.
My environment looks like the following:
MacOS 10.15.4
Clang 11.0.3
Cmake 3.16.5
Tools and headers are installed here /Library/Developer/CommandLineTools/usr/bin
Project uses cotire 1.8.0
IDE - CLion
In general, project consists of 30+ sub-projects some are C some C++. Only those in C can be built.
I've been trying a lot of stuff: setting target version for Cmake, setting paths where to look for headers manually (in Cmake files). Re-installing developer tools does not help as well.
Please, see original error message:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iostream:37:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/ios:214:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iosfwd:95:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/wchar.h:118:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/wchar.h:92:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/_wctype.h:42:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/__wctype.h:62:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/_types/_wctype_t.h:32:9: error: unknown type name '__darwin_wctype_t'
typedef __darwin_wctype_t wctype_t;
UPDATE 1
I've moved a bit forward, and figured out that stdafx.h cannot even include iostream. So I will check all include paths.
There was an issue with includes. Project has its own _types.h, and there is one in system. Project's variant was included first and system's one was ignored. Obviously, this leads to such cryptic messages.
This is a root cause.Clang's documentation says I need to use -isysroot to explicitly set system's headers root and this will prevent matching project's header first, but it doesn't work for me. Temporarily, I changed project's header name(types.h) and it worked well(without underscore it is no longer considered as a system header), in the meantime I will try to fix it properly.
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
I guess I just made a simple mistake but I'm not getting which..
Anyways I'm working on a library, also I'm using cmake to build the Makefiles for the project: https://github.com/immapoint/NaNO3/blob/master/CMakeLists.txt
Everything works just fine when compiling the library; it builds the following Files:
bin/libNaNO3.dll
lib/libNaNO3.dll.a (I don't like that name as well)
To test the whole thing, I got another project set up, also using cmake. https://github.com/immapoint/NaNO3TestApp/blob/master/CMakeLists.txt
The main file to test the library looks like this:
https://github.com/immapoint/NaNO3TestApp/blob/master/src/main.cpp
But when it comes to compiling the main file, I'm getting following errors:
CMakeFiles/NaNO3TestApp.dir/objects.a(main.cpp.obj):main.cpp:(.text+0xbf): undefined reference to `nano::Event<int>::attach(std::function<void(int)> *)`
CMakeFiles/NaNO3TestApp.dir/objects.a(main.cpp.obj):main.cpp:(.text+0xd3): undefined reference to `nano::Event<int>::notify(int)`
[...]ld.exe: CMakeFiles/NaNO3TestApp.dir/objects.a(main.cpp.obj): bad reloc address 0x8 in section `.rdata'
This error occures whether I'm building the project using make/cmake or compiling the source file directly using
g++ -Wall -pedantic -ansi -std=c++0x main.cpp [-L./lib -I./include] -lNaNO3
So the problem seems not to lie in cmake but in ld.
I'm working with CMake version 2.8 and MinGW containing GCC version 4.7.2.
Additional information:
Compiler output with -fPIC:
This has nothing to do with CMake or the linker. You need to include the definitions for the nano::Event member functions in the header, not in a separate source file, since templates are instantiated at compile time. By the time the linker gets there, it's too late.
For a fuller explanation, see Why should the implementation and the declaration of a template class be in the same header file? and http://www.parashift.com/c++-faq-lite/templates-defn-vs-decl.html
I have an Xcode 4.2 project which includes a target that cross-compiles for windows. I use custom build rules for C source files and C++ source files in that target, invoking i386-pc-mingw32-g++ via a custom script. For some reason, Xcode runs the custom script I have specified as being for C source files, even when compiling files with a .cpp extension. Why might this be? How can I get Xcode 4.2 to run the "C++ source files" script for my .cpp files?
I also have .c files in this project, and am hoping to use -std=c++11 flag when compiling c++ files to enable some c++11 features. If I compile the .c files with this flag, I end up with weird scoping issues on constants included from math.h that I have yet to really try and understand - I am hoping I can just get Xcode to run the correct script for my .cpp files.
Any ideas?
Update: I've been able to get Xcode to run the correct scripts. To do this, I had to change the Process drop-down menu selections from "C source files" and "C++ source files" both to "Source files with names matching:" and then manually enter *.c and *.cpp in the provided text field. Now I have to figure out why I'm getting an M_PI was not declared in this scope error message where I wasn't before - maybe a different version of math.h is being used with the -std=c++11 flag which either doesn't include the M_PI constant or provides it under a different namespace?
Update: Continuing to work on this - it appears the M_PI value I was using from math.h is actually a macro which is only #define'd if __STRICT_ANSI__ has not been defined. Apparently switching to c++11 by using the -std=c++11 compiler flag has caused this __STRICT_ANSI__ macro to be defined, and thus the M_PI macro I was previously using isn't there. I suppose it's better to just define my own pi constants than to mess with the declaration of this __STRICT_ANSI__ macro, but I'll probably dig into that a bit just to clarify why it is being declared now that I'm using the c++11 flag.
Update: I found this post How can I make C++0x and __STRICT_ANSI__ get along?, which just suggests undefining the 'STRICT_ANSI' macro right after the '-std=c++11' flag (or rather, the equivalent '-std=c++0x' flag. While this seems sketchy, no one has posted encountering any problems because of it and it appears to work just fine for me as well in this case. Gcc documentation on this macro is located here: http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html, with the following relevant statement:
The macro STRICT_ANSI is predefined when the -ansi option is used. Some header files may notice this macro and refrain from declaring certain functions or defining certain macros that the ISO standard doesn't call for; this is to avoid interfering with any programs that might use these names for other things.
Still not sure why the '-std=c++11' flag causes this to be defined when it isn't by default (which would be '-std=c++98', apparently).
If you want C++11 support without ANSI mode, use -std=gnu++11 instead of std=c++11.
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.