I have installed the cds library with command ./build.sh -b 64 -z '-std=c++0x' -l '-L /usr/lib/x86_64-linux-gnu' --with-boost /usr/include/boost --amd64-use-128bit at build folder.
After I tried to compile the example init.cpp of src folder, I typed this in terminal: g++ init.cpp -o init, and terminal showed: fatal error: cds/init.h: No such file or directory.
What should I do for compilation command in this case?
Thanks.
For general troubleshooting in cases like this, i would recommend finding where on the system the file got installed (if your build.sh actually installed the file). You would be able to find the missing header file using
find / -path '*/cds/init.h' 2>/dev/null
Then you need to supply two parameters to g++:
First one gets the compiler to know about the include files from the install directory
-I path_to_folder_one_step_above_cds_folder
Second one gets the linker to know about the librarys location. If the library file is called libcds.so, you can find it by running
find / -name libcds.so 2>/dev/null
So for linking, you supply the flag
-L path_to_folder_one_step_above_libcds.so
In your case you might not need the -L flag, since most of your library supposedly is header only.
UPDATE: the build.sh script is printing out important information at the top, starting with "Building with the following options:". The important bits will be "Compile options:" and "Link options:". Those should be enough to solve your specific option.
UPDATE2: build.sh also exports some flags which might include more options. You can print them out directly after running build.sh by running
echo LDFLAGS=$LDFLAGS
echo CFLAGS=$CFLAGS
echo CXXFLAGS=$CXXFLAGS
you are likely to need to pass all these options to g++ when compiling and linking against that library. LDFLAGS are specific to the linker only. Both the other ones are needed for compiling c++ files.
Related
When I try to train my yolov4 on my vm with command
./darknet detector train build/darknet/x64/data/obj.data cfg/yolov4-my_gray.cfg backup/yolov4-my_gray_1200.weights -gpus 0,1,2,3 -dont_show
I received
-bash: ./darknet: No such file or directory
Of course I do this in darknet directory. When I try to make i received
When i check open cv
pkg-config --cflags opencv
I received
"-I/usr/include/opencv"
Maybe somebody can help.
Seems compiler is not able to find the file in the includes path you mentioned.
First check if cuda_runtime.h file is available on your machine and get that location. If the file is available then just give the path of the file to the compiler using -I option.
If the file is available at the path /usr/include/opencv, then you would need to provide it with -I option to the compiler
g++ -std=c++11 -I/usr/local/cuda/include ...
I was trying to build zlib with CMake 3.9.0, output set to MinGW Makefiles, and noticed upon trying to call mingw32-make in the output dir that there was a weird error message which very much looks like a quoting error to me.
D:\zlib-1.2-11> mingw32-make
[ 2%] Generating zlib1rc.obj
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files\mingw-w64\x86_64-7.1.0-win32-seh-rt_v5-rev0\mingw64\bin\windres.exe: preprocessing failed.
CMakeFiles\zlib.dir\build.make:60: recipe for target 'zlib1rc.obj' failed
mingw32-make[2]: *** [zlib1rc.obj] Error 1
CMakeFiles\Makefile2:103: recipe for target 'CMakeFiles/zlib.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/zlib.dir/all] Error 2
Makefile:139: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
What could be the cause of this error and how can I fix it? If it were only zlib, I could scrape the net for pre-built binaries, but this has happened with some other builds, too.
This appears to be a bug in MinGW's version of windres.exe, although I'm also going to heap some blame onto CMake for it's appalling method of invoking windres, which is what is causing this to fail.
The Problem
CMake understands that Windows Resource .rc files are a thing, and that they are compiled with the Windows Resource Compiler (aka windres.exe), which it wraps in the default variable CMAKE_RC_COMPILER.
The problem is, that rather than just invoking windres like a normal person, CMake thinks it's being clever by invoking it like so...
cmd.exe /C "cd /D C:\Users\username\zlib-1.2.11\build && "C:\Program Files\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev0\mingw64\bin\windres.exe" -D GCC_WINDRES -I C:/Users/username/zlib-1.2.11 -I C:/Users/username/zlib-1.2.11/build -o C:/Users/username/zlib-1.2.11/build/zlib1rc.obj -i C:/Users/username/zlib-1.2.11/win32/zlib1.rc"
Evidently it doesn't understand the notion of the current working directory, or the system path variable (which it used to find windres in the first place). If we were to simplify the command, it would look like this...
windres -D GCC_WINDRES -I.. -I. -ozlib1rc.obj -i ../win32/zlib1.rc
Those two commands carry the exact same meaning, except the second one actually works.
The Solution
We have to step in and stop CMake from trying to be clever.
cmake .. -DCMAKE_RC_COMPILER=windres
I have MSVC 2017 installed, and CMake assumes that I want to use that by default, despite none of its environment variables being set and it not being in the path (in normal usage, one must invoke the vcvars64.bat file before using MSVC, this behaviour predates CMake). So I have to use -G "MinGW Makefiles", except that I also have sh.exe in my path (because Git), and that just blows CMake's mind, so I need the command...
cmake .. -G"MSYS Makefiles" -DCMAKE_RC_COMPILER=windres
The CMake file author should have quoted strings containing unknown filesystem paths, i.e. variables and the VERBATIM option also avoids headaches:
if(MINGW)
# This gets us DLL resource information when compiling on MinGW.
if(NOT CMAKE_RC_COMPILER)
set(CMAKE_RC_COMPILER windres.exe)
endif()
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
COMMAND "${CMAKE_RC_COMPILER}"
-D GCC_WINDRES
-I "${CMAKE_CURRENT_SOURCE_DIR}"
-I "${CMAKE_CURRENT_BINARY_DIR}"
-o "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
-i "${CMAKE_CURRENT_SOURCE_DIR}/win32/zlib1.rc"
VERBATIM)
set(ZLIB_DLL_SRCS "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj")
endif(MINGW)
I have a couple of libraries built by the NDK for which I am trying to view the exported symbols, the available function names to be precise. One is a .so file and the other a .a file. I was helped in this question (How to obtain readelf and objdump binaries for OS X?) to find the utilities that I think I need. They are specific to the NDK installation. I am on OS X fyi.
In my NDK installation I found nm and objdump in prebuilt/darwin-x86_64/arm-linux-androideabi/bin. Their file type is "Alias". When I ran nm -g libMylib.so nothing happened -- at all. When I ran objdump -TC libMylib.so I got: "objdump: command not found". Then I found the arm-linux-androideabi-nm and arm-linux-androideabi-objdump files (file type listed as "Unix Executable File" in Finder) in the prebuilt/darwin-x86_64/bin dir. The attempt to use both of them resulted in "command not found". In all these attempts I placed libMylib.so right in the very folder with the utility I'm trying to run.
I think this is basically a general issue about how to call binaries in unix; even if you are in the same directory when you run nm -g libMylib.so, since . normally isn't part of your $PATH. To run the right one, do ./nm -g libMylib.so, or without using cd to enter this directory first, just do path/to/your/NDK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-nm -g libMylib.so, or add this directory to your path first:
export PATH=path/to/your/NDK/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin:$PATH
arm-linux-androideabi-nm -g libMylib.so
(It's preferrable to add this directory to the path instead of the arm-linux-androideabi directory, since it is clear which tool you want to invoke when you call when you do arm-linux-androideabi-nm, while if you add the other directory and call nm, it is up to the order of the directories in $PATH.)
See e.g. Why do you need ./ (dot-slash) before script name to run it in bash? for more explanations about $PATH.
I can run compile in OSX terminal using g++ -Wall -c pa1.cpp -o pa1. Which creates pa1, so I know my compilation works in terminal but I am having issues with execution. I have tried ./pa1 , ./a.out, pa1 and few others. I believe the issue is with Xcode, yet the fact that my code will compile in terminal and creates an executable makes me unsure. Thought, I would ask here for suggestions before reinstalling Xcode.
Use g++ pa1.cpp -o pa1 and then you'll be able to run your new executable as ./pa1. This require that your whole program is in pa1.cpp. If it is spread in multiple files, you'll have to list all of them on the command-line.
As said in the comments, the -c option means compile, ie. Create an object file that can be passed to the linker to build an executable. If you don't use this option, g++ will first compile any source file, then invoke the linker on all the object files to create an executable named a.out by default (name comes from historical reason).
You can see that the output of your command was not an executable binary but an intermediate object file by using the file util.
i am using ubuntu 10.10
i am trying to compile simple helloworld file using
gcc -c option
the output file is created but it does not have execute permission
if i dont use -c option the output file has execute permission ..
Please help
The command gcc -c generates a non-executable object file. If you want the output to be executable, do not use the -c option.
I am not sure what you hoped -c was for, but it is exactly for not generating an executable, and your GCC is working as designed.
From the man gcc:
-c Compile or assemble the source files, but do not link. The linking
stage simply is not done. The ultimate output is in the form of an
object file for each source file.
It is not executable. It needs to undergo linking process to become an execution file.