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.
Related
I am encountering issues when trying to compile fortran code using meson build system on an HPC cluster.
On the cluster, I am using Intel compiler suite. The meson compile command aborts at the linking step with:
ld: /usr/bin/../lib64/crt1.o: in function `_start':
(.text+0x20): undefined reference to `main'
ninja: build stopped: subcommand failed.
The interesting thing is that the link command issued by meson is something like this:
icpc -o main main.p/somefile.o ..., so it is using Intel's C++ compiler to link my fortran code. I tried to use the exact same command line, replacing icpc with ifort and adding -lstdc++. That actually worked.
So, I wonder, is there a way to force Meson to link my code with ifort, instead of icpc? Or, should I do something else?
I am afrad I cannot share the code at this moment. But, I'm open to showing bits and pieces of the meson.build file(s), if needed.
Details
The codebase consists of fortran source and a CMake C++ subproject; Essentially, the C++ subproject is a wrapper for OpenCV image plotting functions. This is why I needed to add -lstdc++ to my successful manual link command above.
Meson version: 0.55.3
Intel Fortran compiler: ifort (IFORT) 19.1.3.304 20200925
Intel C++ compiler: icpc (ICC) 19.1.3.304 20200925
The code is MPI parallelised.
The same code compiles well with GNU compilers v10 on a normal workstation.
Meson is not going to do any hand-holding when it comes to mixing languages. Here is what I found out works for Intel compilers:
fc=meson.get_compiler('fortran')
# cxx=meson.get_compiler('cpp')
...
if (fc.get_id() == 'intel')
#if (cxx.get_id() == 'intel')
...
add_global_link_arguments('-cxxlib',language : 'fortran')
add_global_link_arguments('-nofor_main', language : 'cpp')
endif
...
executable('myprog','myprog.f90', ..., link_language : 'fortran')
#executable('myprog','myprog.f90',...)
I was trying to include the GMP library, which was simply the code below(I did nothing else):
#include <gmpxx.h>
However, when I tried to compile the code, the following error from g++ compiler occured:
myCode.cpp:3:10: fatal error: gmpxx.h: No such file or directory
#include <gmpxx.h>
^~~~~~~~~~~~~~~~~~~~~~
I have tried everything I searched online, putting the GMP lib here and there, adding INFINITE includepaths in c_cpp_properties.json, still, it keeps showing the message, although, I can find the file through "Go to Definition" option.
Is there any known solution to this?
It's not enough to configure VS Code includes, you need to pass those options to the compiler as well.
You don't mention your platform at all, so I'm going to use an example from my personal machine, a Macbook Pro with the fmt library.
When compiling with the fmt library, I have to provide three more options to the compiler.
-I/usr/local/include // Tells the compiler where to look for extra includes
-L/usr/local/lib // Tells the compiler where to look for extra libraries
-lfmt // fmt-specific command to use fmt library
So the full command ends up looking like this:
g++ -Wall -std=c++17 -I/user/local/include -L/usr/local/lib -lfmt main.cpp
I need all three options because fmt is installed in a non-standard location that the compiler doesn't check by default. According to the documentation, you can get away with just -lgmp and -lgmpxx if you installed the library in a standard location (happens by default with *nix and a package manager, I imagine).
If you use build tasks in VS Code, this can be set up and automated for you.
I am trying to work through this tutorial on OpenCL, on a Windows 10 dev system which has integrated Intel HD graphics. I have installed Intel's OpenCL SDK. I have added the include directory from the SDK install into Properties > C/C++ General > Paths and Symbols > Includes. I am using MinGW as my compiler for Eclipse
In response to a number of linker errors that popped up when I first tried to compile the project, I set up the linker in eclipse to point to opencl.lib as outlined in this answer.
That took care of the linker errors, but there's an offending line from the tutorial which makes it impossible for the tutorial boiler-plate to compile:
87 cl_int result = program.build({ device }, "");
Set up as I am, this gives me the following warning and error:
..\src\main.cpp:93:32: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
..\src\main.cpp:93:45: error: no matching function for call to 'cl::Program::build(<brace-enclosed initializer list>, const char [1])'
If I'm reading this correctly (I haven't used C++ since before C++11 was a thing), the compiler is first warning me that it doesn't properly recognize what {device} is supposed to be (a vector of devices which has only one entry in it, initialized earlier in the code). Then, since it doesn't recognize {device}, the compiler errors out because it can't find a signature for cl::Program::build with arguments that match whatever-the-heck it's interpreting {device} to be.
Following the warning's advice, I followed the instructions given in this answer to add the -std=c++11 option for the compiler. However, when I do that the linker errors come back. Trying to compile with these options results in about thirty errors which all basically say they can't find any reference for the CL calls in the library files. For example:
C:/Program Files (x86)/Intel/OpenCL SDK/6.3/include/CL/cl.hpp:1753: undefined reference to `clGetPlatformInfo#20'
How do I make the compiler behave? I think I remember reading somewhere that the order of compiler options in the command line matters withe regards to linking, could that be messing up my compile since I added the -std=c++11 option?
I (sort of) figured out why the compiler was unhappy--the library I was linking was the x64 library for OpenCL installed in [base Intel dir]\OpenCL SDK\6.3\lib\x64, but (I think?) my compiler is not set up to create x64 apps. When I link to the .lib file in OpenCL SDK\6.3\lib\x86 my linker errors disappeared.
I'm trying to get emscripten to work on OS X 10.8, see this post for some related issues there. Apparently the clang++ version shipped with Xcode is too old, so I got a recent clang 3.7.0 using MacPorts. I even told CMake to use that compiler (passing -DCMAKE_CXX_COMPILER=clang++-mp-3.7 on the command line), but it still fails:
[ 33%] Building CXX object CMakeFiles/optimizer.dir/parser.cpp.o
/opt/local/bin/clang++-mp-3.7 -std=c++11 -fno-exceptions -fno-rtti -O3 -DNDEBUG
-o CMakeFiles/optimizer.dir/parser.cpp.o
-c …/emsdk/emscripten/master/tools/optimizer/parser.cpp
In file included from …/emsdk/emscripten/master/tools/optimizer/parser.cpp:2:
In file included from …/emsdk/emscripten/master/tools/optimizer/parser.h:12:
…/emsdk/emscripten/master/tools/optimizer/istring.h:3:10: fatal error:
'unordered_set' file not found
#include <unordered_set>
^
1 error generated.
I can reproduce that issue by launching the compiler from the command line. In parallel build mode, sometimes it's instead complaining about <cstdint> for optimizer.cpp instead. Both these headers exist in /opt/local/libexec/llvm-3.7/include/c++/v1/.
What's the canonical way to use the macports-installed version of clang++ including its headers? Do I have to use -I and work out the full path, or is there something shorter?
Can I safely do so without also switching the runtime library to the one shipped with MacPorts' clang? If not, can I somehow encode the full path of the runtime library into the created binary, either for that single library or using the -rpath argument to ld or some equivalent alternative?
Update: I get unresolved symbols when I try to link stuff after specifying the include directory manually, and I don't know how to solve that. The libcxx package from MacPorts is empty except for a readme file.
I've solved the original problem by adding CXXFLAGS=--stdlib=libc++ to the environment. Then even the system version of clang will do everything I need. That flag works magic for MacPorts' version of clang as well: specifying that I get a successful build, and I can even verify (using the -E compiler switch) that it's using the headers I mentioned before. I'm still not certain whether there is anything to ensure that the headers match the system's version of libc++, though.
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.