I use MinGW64+msys on Winodws7 64bit
Now I’m trying to build CMAKE but I can’t.
When I typed ./configure soon an error happened. .
---------------------------------------------
CMake 3.2.3, Copyright 2000-2015 Kitware, Inc.
Found GNU toolchain
C compiler on this system is: gcc
---------------------------------------------
Error when bootstrapping CMake:
Cannot find appropriate C++ compiler on this system.
Please specify one using environment variable CXX.
See cmake_bootstrap.log for compilers attempted.
I also find error messages in Bootstrap.cmk/cmake_bootstrap.log like bellow.
[First Message in the log file]
In file included from c:/mingw64/x86_64-w64-mingw32/include/c++/iosfwd:40:0,^M
from c:/mingw64/x86_64-w64-mingw32/include/c++/ios:38,^M
from c:/mingw64/x86_64-w64-mingw32/include/c++/ostream:38,^M
from c:/mingw64/x86_64-w64-mingw32/include/c++/iostream:39,^M
from cmake_bootstrap_4468_test.cxx:3:^M
c:/mingw64/x86_64-w64-mingw32/include/c++/bits/postypes.h:40:35: fatal error: cw
char: No such file or directory^M
compilation terminated.^M
[Second Message in the log file]
cmake_bootstrap_4468_test.cxx:5:23: fatal error: iostream.h: No such file or dir
ectory^M
compilation terminated.^M
Test failed to compile
They said cwchar and iostream.h doesn't exist, although I have them and set their path to environmental variable.
The first massage said my C++ compiler isn’t appropriate. I installed it by mingw-get.exe.
Does anyone know, how can I get appropriate C++ compiler?
You mixed two compilers. I recommend: delete your old one and install msys2+mingw64.
Related
I'm trying to use cuda in ns3, but when I tried to run CXX="nvcc" ./waf configure, it shows the following message on the screen:
Checking for 'g++' (C++ compiler) : not found
Checking for 'clang++' (C++ compiler) : not found
Checking for 'icpc' (C++ compiler) : not found
could not configure a C++ compiler!
(complete log in /home/kelu/workspace/ns-3.24/build/config.log)
I checked the config.log, it says the following:
Checking for 'g++' (C++ compiler)
find program='nvcc' paths=['/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin', '/usr/local/cuda/bin'] var='CXX' -> ['nvcc']
from /home/kelu/workspace/ns-3.24: Could not determine the compiler type
not found
----------------------------------------
Checking for 'clang++' (C++ compiler)
find program='nvcc' paths=['/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin', '/usr/local/cuda/bin'] var='CXX' -> ['nvcc']
from /home/kelu/workspace/ns-3.24: Not clang/clang++
not found
----------------------------------------
Checking for 'icpc' (C++ compiler)
find program='nvcc' paths=['/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin', '/usr/local/cuda/bin'] var='CXX' -> ['nvcc']
from /home/kelu/workspace/ns-3.24: Not icc/icpc
not found
from /home/kelu/workspace/ns-3.24: could not configure a C++ compiler!
nvcc is located in /usr/local/cuda/bin, which is in path. But it seems to me that the building script of ns3 does not resolve nvcc as a compiler.
Could anybody please tell me the right way to make nvcc the CXX compiler in ns3?
Thanks.
Your problem probably was that Waf actually checks the compiler's built-in #defines to check whether a compiler invoked as "gcc" actually is gcc or not. As a concrete example, it will error out if it detects that the compiler is Intel's icc (because it #defined __INTEL_COMPILER) but was invoked with a "gcc" command line!
The code that does the identification is at https://waf.io/apidocs/_modules/waflib/Tools/c_config.html#get_cc_version .
So, if you don't have a compiler which tries hard to look like one of the supported ones, looks like you are supposed to write your own Waf tool.
However, you can try to hack your way through. For example, let's say that your compiler is compatible enough with gcc but still it doesn't get past Waf's absurdly stringent test. A fix is to run "waf configure" using the real gcc, and then edit the file where Waf stores the detection results, so at the build step Waf will actually run your compiler instead of gcc. You can do this by editing build/c4che/_cache.py: change the CC definition to your compiler's full path.
I haven't found a way to use nvcc in ns-3, but I did find a work around for this problem. I'm happy to share my solution here to help others:
Make your cuda code a static library:
ar rcs libcudacode.a a.o b.o c.o (you need to make the *.o files first using g++, nvcc, or anything else you want)
put libcudacode.a in /your/lib/folder/ and put your cuda code in /your/src/folder
Add lib folder and src folder into waf:
CXXFLAGS_EXTRA="-I/your/src/folder -I/your/cuda/dir/include" LINKFLAGS_EXTRA="-L/your/lib/folder -L/your/cuda/dir/lib64 -lcudacode -lcudart" ./waf configure.
./waf
Your code should be compiled now. You can access any public functions in your cuda code by #including "corresponding_header.h"
A little bit explanation:
CXXFLAGS_EXTRA and LINKFLAGS_EXTRA add compilation flags in ns-3's compiling system. You need to add both your cuda code and NVidia's cuda library to use the functions.
If you used any other libraries, also put them in CXXFLAGS_EXTRA and LINKFLAGS_EXTRA
Check the cuda directory name in your system. It's probably not lib64 in your machine.
Whenever I try to compile this code it always ends up with this error:
In file included from /usr/include/wchar.h:6:0,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cwchar:44,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/postypes.h:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iosfwd:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ios:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ostream:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iostream:39,
from test.cpp:1:
/usr/include/sys/reent.h:14:20: fatal error: stddef.h: No such file or directory
#include <stddef.h>
^
compilation terminated.
The code I was trying to compile is:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World! :D";
return 0;
}
The error is because your gcc-core package and gcc-g++ are not of the same version. Either downgrade one of them to solve the problem or update both the libraries. Updating both the libraries is the recommended way.
I had this error on a fresh MinGW install, it had nothing to do with the installed packages mentioned in the current accepted answer by "Prasanth Karri". In my case the issue was caused by -nostdinc in my Makefile. I actually only needed that compiler flag when building for a different target platform (not when using MinGW) so I fixed the issue by removing that flag from MinGW builds.
When I was incorporating a software library written in C into an existing demo project(used a C++ mbed library) I encountered this problem. The demo project would compile just fine, but after I replaced the existing main file by my own, this error occurred.
At this point I hadn't yet thought about the fact that the mbed library that I needed was written in C++. My own main file was a .c file that #include the mbed header file. As a result I used my normal C source as if it was a C++ source. Therefore the compiler that was used to compile my main file was the C compiler.
This C compiler then encountered a #include of a module that actually does not exist (within its scope), as it's not a C++ compiler.
Only after I inspected the output of the build log I realised the various source C and C++ files were compiled by more that 1 compiler(the c++ compiler). The project used used compilers arm-none-eabi-c++ and arm-none-eabi-gcc (for embedded systems) as seen below.
Compile log:
Building file: ../anyfile.cpp
Invoking: MCU C++ Compiler
arm-none-eabi-c++ <A lot of arguments> "../anyfile.cpp"
Finished building: ../anyfile.cpp
Building file: ../main.c
Invoking: MCU C Compiler
arm-none-eabi-gcc <A lot of arguments> "../main.c"
In file included from <Project directory>\mbed/mbed.h:21:0,
from ../main.c:16:
<Project directory>\mbed/platform.h:25:19: fatal error: cstddef: No such file or directory
compilation terminated.
Of course in a C++ environment cstddef exists, but in a C environment cstddef doesn't exist, in stead it's just C's implementation of stddef.
In other words, cstddef does not exist in the C compiler.
I resolved this problem by renaming my main.c file to main.cpp and the rest of the code compiled smoothly too.
TLDR/Conclusion: When building a C++ project, avoid mixing C files with C++ files(sources and headers). If possible rename .c files to .cpp files to use the C++ compiler in stead of the C compiler where required.
In order to update it, follow below.
If you are on Windows, just run these on command prompt or powershell
Update the package list: mingw-get update
After updating the package list, run: mingw-get upgrade
Source: How to update GCC in MinGW on Windows?
This problem was solved for me as I installed codeblocks with mingw compiler then I copied the mingw folder from codeblocks to C drive and added
C\mingw\bin to the environment variables.
If you try to compile and see a message like, "fatal error: stddef.h: No such file or directory", the error is because your gcc-core and gcc-g++ packages are not of the same version. Rerun the Cygwin install and make sure that you select the highest numbered versions of gcc-core and gcc-g++.
After installing the C++ compiler with MinGW I encountered this problem as well. Apparently, you have to also install mingw32-base. Go to C:/MinGW/bin/mingw-get.exe (my path) and check it for installation at the Basic Setup tab.
I'm following the instructions from INSTALL.W32 (various OpenSSL versions), in general it's:
* Configure for building with Borland Builder:
> perl Configure BC-32
* Create the appropriate makefile
> ms\do_nasm
* Build
> make -f ms\bcb.mak
Now, I do get two kind of errors when trying to build:
For OpenSSL < 1.0.0
nasmw -f obj -d__omf__ -ocrypto\md5\asm\m5_win32.obj .\crypto\md5\asm\m5_win32.asm
'nasmw' is not recognized as an internal or external command,
operable program or batch file.
Otherwise
Warning W8017 C:\CBuilder5\Include\sys/stat.h 34: Redefinition of 'S_IFMT' is not identical
Warning W8017 C:\CBuilder5\Include\sys/stat.h 35: Redefinition of 'S_IFDIR' is not identical
Error E2227 .\crypto\rand\randfile.c 226: Extra parameter in call to _open in function RAND_write_file
Warning W8053 .\crypto\rand\randfile.c 262: '_chmod(const signed char *,int,...)' is obsolete in function RAND_write_file
*** 1 errors in Compile ***
Yes, I feel bad for using Borland C++ Builder 5 but I can't do anything about it, and yes, I consider the Shining Light option if everything else fails.
I do not use OpenSSL but from your text some hints:
NASM
is not default assembler for Borland compilers
you need to download and install it first
(it is for free and one of the best compilers I used in the past)
you are missing some #define before including OpenSSL or including in wrong order
that is why you have the first warnings and most likely also the error
some libs need to add configuration #defines (added by some specific IDE's)
to specify what compiler,platform,endianess... is used
before any includes
usually if you include in wrong order then the defines are defined for some instances of a lib file but not for all
so try to reorder the includes
sometimes helps to include before the lib some other thing like conio,stdio,windows,...
to determine which define is missing or wrong open the stat.h
and look for #ifdef #ifndef statements around S_IFMT
The solution for the newest version (1.0.2d) was to:
remove the extra parameter from randfile (which, as comment stated, was unnecessary),
edit ms\bcb.mak, search for -DMD5_ASM -DSHA1_ASM -DRMD160_ASM
and change to -DMD5_NO_ASM -DSHA1_NO_ASM -DRMD160_NO_ASM . (there was an unresolved external error with SHA, MD5 and RMD160, they basically couldn't be compiled in asm).
There were some other steps included as well, but they're just specific to my environment.
I was using flex and bison to build a simple calculator project I cloned from Github.
But after I typed make in terminal, I got the following message:
gcc -o calc calc.tab.c lex.yy.c -lfl
calc.y:48:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main() {
^~~~
1 warning generated.
ld: library not found for -lfl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [calc] Error 1
How could I resolve this problem?
let me guess, trying to use flex on OS/X?
Try -ll instead of -lfl
Using Flex on OS/X
So yea, the flex library name on OS/X is just arbitrarily different for some reason. OS/X is not exactly Linux, but it's pretty close. You have some options here.
You can just simply have a separate build system and source files for OS/X. Certainly Apple might like that with their pushing XCode, objective-C and not much interoperability.
You can build vs Linux and then engage with Mac Ports and Homebrew.
You can create your project using autotools. That's not an awesome link, learning this system is rough going, but it's a standard thing for Linux for sure. This will actually work, I find if you have the patience for it, OS/X is close enough that autotools based builds will work on it.
Lately, I've been turned on to Cocoapods, which I believe to be an attempt to join the open source community and XCode. It's kind of half 1 and 3 sorta with an emphasis on modularizing the external source and getting it compiled into a .app (via Xcode).
warning: type specifier missing, defaults to 'int'
mean that you should declare return type for main function. Place int in function difinition.
ld: library not found for -lfl
flag -l mean that compiller must use libfl.a to build programm. As #waTeim said above, for Mac OS you can use libl.a instead, but this lib can be not exist alse. There is another way is to place
%option noyywrap
at the top of flex *.l file. In this case you can compile without additional libs.
I am trying to compile ncurses-5.7 from source and after running ./configure I get the following error:
configure: error: Your compiler does not appear to recognize prototypes.
You have the following choices:
a. adjust your compiler options
b. get an up-to-date compiler
c. use a wrapper such as unproto
how can I fix this error?
As configure output suggests, you should either install an HPUX version of gcc or use unproto as a wrapper
Commenting the following line in configure file worked.
export CC="cc"
Got the answer from Here.