I am trying to run a opencv based simple rgb to gray scale script and run it through cuda. The header for the C++ script that does the computation links the following api from opencv:
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgproc/imgproc.hpp>
I am trying to compile it using the following makefile logic:
OPENCV_LIBPATH=-L/apps/gcc/4.7.2/opencv/2.4.8/lib
OPENCV_LIBPATH += -l/opt/cuda/5.5/lib64
OPENCV_INCLUDEPATH=/apps/gcc/4.7.2/opencv/2.4.8/include
OPENCV_LIBS=-lopencv_core -lopencv_imgproc -lopencv_highgui -lnppi -lz
CUDA_INCLUDEPATH=/opt/cuda/5.5/include
NVCC_OPTS=-O3 -arch=sm_20 -Xcompiler -Wall -Xcompiler -Wextra -m64
GCC_OPTS=-O3 -Wall -Wextra -m64
main: rgbtogrey.o rgb_to_grey.o Makefile
$(NVCC) -o main.out rgbtogrey.o rgb_to_grey.o -I$(OPENCV_INCLUDEPATH) $(OPENCV_LIBPATH) $(OPENCV_LIBS)
rgbtogrey.o: rgbtogrey.cpp timer.h utils.h
g++ -c rgbtogrey.cpp $(GCC_OPTS) -I $(CUDA_INCLUDEPATH) -I $(OPENCV_INCLUDEPATH)
rgb_to_grey.o: rgb_to_grey.cu utils.h
nvcc -c rgb_to_grey.cu $(NVCC_OPTS)
clean:
rm -f *.o hw
I tried a number of other solutions such as those outlined in
Compiling a basic opencv cuda and Linking Cuda in C++ issue.
Current Error:
/apps/gcc/4.7.2/opencv/2.4.8/lib/libopencv_highgui.a(grfmt_exr.cpp.o): In function `cv::ExrDecoder::ExrDecoder()':
grfmt_exr.cpp:(.text._ZN2cv10ExrDecoderC2Ev+0x9d): undefined reference to `Imf::Chromaticities::Chromaticities(Imath::Vec2<float> const&, Imath::Vec2<float> const&, Imath::Vec2<float> const&, Imath::Vec2<float> const&)'
I am pretty new to this as such am not sure where to look for to solve this error.
EDIT:
1. Following the comment I added the lnppi option to the main after adding the LIB path (see makefile portion updated)
Error now:
/apps/gcc/4.7.2/opencv/2.4.8/lib/libopencv_core.a(persistence.cpp.o): In function `icvGets(CvFileStorage
persistence.cpp:(.text._ZL7icvGetsP13CvFileStoragePci+0x127): undefined reference to `gzgets'
added link to zlib via lz
Try to use the attached libraries under the OpenCV's OPENCV_PATH/3rdparty/lib folder by -libIlmImf -llibjpeg -llibjasper -llibpng -lzlib.
Also take care to the order in which libraries are linked, because any static library must be linked in the appropriate order otherwise unresolved references will appear with GNU ld:
If any [static] library A depends on symbols defined in library B,
then library A should appear first in the list supplied to the linker.
See linker order - GCC for more information.
Related
I am trying to install my C++ igraph library from https://github.com/igraph/igraph to visual studio code using the following method this is my makefile made according to this link.
CXX = g++
CXX_FLAGS = -std=c++17 -O3 -march=native -DNDEBUG
LIB = -Llib
INC = -Iinclude
.PHONY: all
all: a.out
a.out: main.cpp
$(CXX) $(CXX_FLAGS) $(INC) $(LIB) -ligraph -lm -lstdc++ -lgomp -lpthread -o $# main.cpp
.PHONY: clean
clean:
rm a.out
The compiler will always return something like:
g++ -std=c++17 -O3 -march=native -DNDEBUG -Iinclude -Llib -ligraph -lm -lstdc++ -lgomp -lpthread -o a.out main.cpp
/usr/bin/ld: /tmp/ccqJLfvi.o: in function `main':
main.cpp:(.text.startup+0x9): undefined reference to `igraph_rng_default'
/usr/bin/ld: main.cpp:(.text.startup+0x16): undefined reference to `igraph_rng_seed'
collect2: error: ld returned 1 exit status
make: *** [Makefile:12: a.out] Error 1
If i only want to use data structures such as igraph_t graph* it will work, but if i try to call fucntion it will return error and will not generate a.out file. It would be incredablly good if someone would be able to explain why this happens cuz it really got on my nerve right now.
Please follow the instructions in the documentation to set up your package to link to igraph.
Instructions to install igraph: https://igraph.org/c/html/latest/igraph-Installation.html Note that you must both build and install the package. Make a note of the location you used to install it to (the value of CMAKE_INSTALL_PREFIX)
Instructions on compiling your first igraph program: https://igraph.org/c/html/latest/igraph-Tutorial.html Unless you are already comfortable with writing C programs and linking them to external libraries, I strongly recommend that you use CMake to set up your project, as described in the linked tutorial. CMake works the same way on all platforms (Windows/macOS/Linux) and will automatically figure out how to link your program to igraph correctly. When configuring your project, be sure to set CMAKE_PREFIX_PATH to the location where you installed igraph earlier.
I tried to install SFML library to VS Code project using a Makefile. But I am faced with a problem. I have the following code:
#include <SFML/Graphics.hpp>
#include <string>
int main()
{
// Creating the main window
sf::RenderWindow window(sf::VideoMode(800, 600), "Asteroids");
return EXIT_SUCCESS;
}
And I have the following Makefile:
CXX := g++
CXX_FLAGS := -Wall -Wextra -std=c++17 -ggdb
BIN := bin
SRC := src
INCLUDE := include
LIB := lib
LIBRARIES := -lsfml-graphics -lsfml-window -lsfml-system -lsfml-audio -lsfml-main
EXECUTABLE := main
SFML_LIBRARY := "C:\\vcpkg\\installed\\x64-windows\\include"
SFML_LIB := "C:\\vcpkg\\installed\\x64-windows\\lib"
all: $(BIN)/$(EXECUTABLE)
run: clean all
cls
./$(BIN)/$(EXECUTABLE)
$(BIN)/$(EXECUTABLE): $(SRC)/*.cpp
$(CXX) $(CXX_FLAGS) -I$(INCLUDE) -L$(LIB) -I$(SFML_LIBRARY) -L$(SFML_LIB) $^ -o $# $(LIBRARIES)
clean:
-del $(BIN)\* /Q
But when I try to compile the code, I get the following error message:
g++ -Wall -Wextra -std=c++17 -ggdb -Iinclude -Llib -I"C:\\vcpkg\\installed\\x64-windows\\include" -L"C:\\vcpkg\\installed\\x64-windows\\lib" src/main.cpp -o bin/main -lsfml-graphics -lsfml-window -lsfml-system -lsfml-audio -lsfml-main
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\totalboy\AppData\Local\Temp\cclPlFnI.o:D:\C++ Projects\Asteroids/src/main.cpp:7: undefined reference to `__imp__ZN2sf6StringC1EPKcRKSt6locale'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\totalboy\AppData\Local\Temp\cclPlFnI.o: in function `main':
D:\C++ Projects\Asteroids/src/main.cpp:7: undefined reference to `__imp__ZN2sf9VideoModeC1Ejjj'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\C++ Projects\Asteroids/src/main.cpp:7: undefined reference to `__imp__ZN2sf12RenderWindowC1ENS_9VideoModeERKNS_6StringEjRKNS_15ContextSettingsE'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\C++ Projects\Asteroids/src/main.cpp:7: undefined reference to `__imp__ZN2sf12RenderWindowD1Ev'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:23: bin/main] Error 1
Libs:
So, can somebody tell me what I do wrong?
The errors you receive can be attributed to the compilers you are using and used for compiling the SFML libraries you currently have. There are differences in the C++ ABI across compilers (and even across versions of the same compiler) [1]. When you want to link your code to a library, you have to make sure that the compiler you use and the one used with the library are the same, or are ABI-compatible.
When using vcpkg to download libraries, the source of those libraries are the ones that are actually downloaded and not the library itself. The source is then compiled "using the most recent version of Visual Studio that it could find [2]. Thus, if you want to use libraries downloaded via vcpkg in Windows, like in your case, you have to use Visual Studio, or, at least just the compiler, MSVC. So, a fix for your problem is to use MSVC (provided by Visual Studio), instead of the compiler in MinGW, which is usually GCC.
If you still want to use MinGW, there are two options:
The simplest option is to use MinGW-compatible SFML packages. There are official pre-built packages for MinGW over the SFML website. Note that these MinGW packages are only compatible with GCC 7.3.0 (at the time of writing). If you are using a different version or a different compiler, you have to resort to option 2.
Another option is to compile SFML on your own first. Once you have finished compiling, you can now link your code with the SFML libraries you have built. This option is also applicable when you are using compilers other than those used to compile the available pre-built SFML libraries.
References:
[1] https://stackoverflow.com/a/7119896/1116098
[2] https://learn.microsoft.com/en-us/cpp/build/vcpkg?view=vs-2019
I'm trying to cross-compile a small test opengl/glew program and I get linker errors from undefined references.
$ /usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib/ -lglfw -lglew32 -lopengl32 main.cc
/tmp/cct8OpVh.o:main.cc:(.text+0x50): undefined reference to `glfwInit'
/tmp/cct8OpVh.o:main.cc:(.text+0xa6): undefined reference to `glfwOpenWindowHint'
...
The same code does work when compiling for linux:
$ g++ -I/usr/include -L/usr/lib/ -lglfw -lGLEW -lGL main.cc
One thing that caught my eye is that every exported symbol from cross-compiled libraries has an extra underscore prefix:
$ nm /usr/lib/libglfw.a | grep glfwInit$
00000000 T glfwInit
$ /usr/i486-mingw32/bin/nm /usr/i486-mingw32/lib/libglfw.a | grep glfwInit$
00000000 T _glfwInit
This seems to be a common thing since even libstdc++.a shares this property, but why is my cross-compiler linker then looking for non-underscore symbols?
Running arch with following packages (local means AUR):
community/mingw32-binutils 2.23.1-3
community/mingw32-gcc 4.7.2-1
local/mingw32-glew 1.9.0-1
local/mingw32-glfw 2.7.7-1
community/mingw32-pthreads 2.9.1-1
community/mingw32-runtime 3.20-4
community/mingw32-w32api 3.17-1
EDIT
After playing out with both pkg-config and watching glfw recompile and test itself, I came up with the following magic that seems to work, at least I'm compiling:
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib -mwindows main.cc -lglew32 /usr/i486-mingw32/lib/libglfw.a /usr/i486-mingw32/lib/libopengl32.a -static-libgcc
There are few questions though:
What is the difference between linking with -l and without?
Why do I need to use -l with glew and cannot with glfw
I was able to solve my problem and, in case someone ever runs into similar situation hope this helps you.
There are two versions of glew32 -library in my system, glew32.a and glew32.dll.a.
glew32.a does not allow for using --static, glew32.dll.a does.
The two commands which compile succesfully, only first of which I've run are:
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib main.cc -lglew32.dll -lglfw -lopengl32 --static
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib main.cc -lglew32 -lglfw -lopengl32
Looking at my old compiling attempts, the problem was wrong order of libraries and that main.cc was after the libraries.
There is a program, called pkg-config that helps you to configure your compiler. See the manual pages for usage information, but, for this case, its output is:
-mwin32 -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib -lglfw -lglu32 -lopengl32 -lm -s -mwindows -e _mainCRTStartup
Try to compile with this, I guess it will work.
This is my first time trying to make a simple library. I worked in Ubuntu 12.04 with g++ 4.6.3. Here is the problem:
[[mylib.cpp]]
#include<sqlite3.h>
void Mylib::blahblah() {...}
void Mylib::evenmoreblah() {...}
...
[[mylib.h]]
#include <...>
class Mylib {
...
};
Then I made the lib by:
gcc -c -Wall -fpic mylib.cpp
gcc -shared -o libmylib.so mylib.o
I used the library in a single test.cpp which contains only the main(). I put libmylib.so in ./libdir, and compiled by using:
g++ -g test.cpp -o test -lpthread -L/usr/local/lib -lsqlite3 -L./libdir -lmylib
The error I got:
./libdir/libmylib.so: undefined reference to `sqlite3_close'
./libdir/libmylib.so: undefined reference to `sqlite3_exec'
./libdir/libmylib.so: undefined reference to `sqlite3_free'
./libdir/libmylib.so: undefined reference to `sqlite3_open'
You could link -lsqlite3 into your shared library with
gcc -shared mylib.o -o libmylib.so -lsqlite3
If you do that, you don't need to explicitly link -lsqlite3 to your program, but that won't harm.
and the order of linking arguments for your program is important:
g++ -Wall -g test.cpp -o mytest \
-L./libdir -lmylib -L/usr/local/lib -lsqlite3 -lpthread
it should go from higher-level libraries to lower-level (i.e. system) ones. And don't forget -Wall to get almost all warnings from the compiler, which is very useful.
Read the Program Library HowTo.
PS. Don't call your program test which is a shell builtin (and the standard /usr/bin/test). Use some other name.
If your library make references to sqlite3, you should link sqlite after linking your library :
g++ -g test.cpp -o test -lpthread -L/usr/local/lib -L./libdir -lmylib -lsqlite3
Otherwise ld won't find anything useful in libsqlite3 before linking your library and won't be able to find the requested symbols after that.
Since your library uses sqlite3, you need to add that AFTER your own library in the linker command. I think you could add it to the linking of your shared library too, but not certain.
The linker resolves libraries and their references in the order you list them, so the order is important.
I'm tryin to use boost threads on mingw (TDM-mingw, 32bit based on gcc4.6) from qtcreator using qmake. I managed to compile boost 1.4.7 using
bjam --toolset=gcc --layout=tagged --without-mpi --without-python -j 4 stage --build-type=complete
However I simply can not get it to link. I tried to link against several of the libboost_thread libraries created (libboost_thread.a, libboost_thread-mt.a, libboost_thread-mt-dll.a, libboost_thread-mt-s.a), however it always ends up giving me
ld.exe: warning: cannot find entry symbol nable-stdcall-fixup; defaulting to 00401000
main.o:main.cpp:(.text.startup+0x76): undefined reference to `_imp___ZN5boost6thread12start_threadEv'
main.o:main.cpp:(.text.startup+0x89): undefined reference to `_imp___ZN5boost6thread4joinEv'
main.o:main.cpp:(.text.startup+0x9c): undefined reference to `_imp___ZN5boost6threadD1Ev'
main.o:main.cpp:(.text.startup+0xdb): undefined reference to `_imp___ZN5boost6threadD1Ev'
The code I'm trying to compile looks like this:
#include <boost/thread.hpp>
struct thread_main
{ void operator()(){ std::cout<<"Hello World"<<std::endl; } };
int main(int argc, char* argv[])
{
boost::thread thread((thread_main()));
thread.join();
return 0;
}
The compile instructions generated by qmake are as followed:
g++ -c -std=gnu++0x -fopenmp -march=i686 -mtune=generic -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -I'e:/Qt/4.73/Desktop/Qt/4.7.3/mingw/include' -I'e:/Qt/4.73/Desktop/Qt/4.7.3/mingw/include/ActiveQt' -I'release' -I'../Test' -I'.' -I'e:/Qt/4.73/Desktop/Qt/4.7.3/mingw/mkspecs/win32-g++' -o main.o ../Test/main.cpp
g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-subsystem,console -mthreads -Wl -o Test.exe.exe main.o -L'e:/boost/stage/lib' -L'e:/Qt/4.73/Desktop/Qt/4.7.3/mingw/lib' -fopenmp -l boost_thread
According to this it has to be compiled with -DBOOST_THREAD_USE_LIB, however doing so only leads to
ld.exe: warning: cannot find entry symbol nable-stdcall-fixup; defaulting to 00401000
main.o:main.cpp:(.text.startup+0x75): undefined reference to `boost::thread::start_thread()'
main.o:main.cpp:(.text.startup+0x87): undefined reference to `boost::thread::join()'
main.o:main.cpp:(.text.startup+0x99): undefined reference to `boost::thread::~thread()'
main.o:main.cpp:(.text.startup+0xd7): undefined reference to `boost::thread::~thread()'
So how can I convice mingw to link against boost_thread (or if it's a problem with the compile flags given to the linker by qmake, how do I convice it to omit problematic flags?
I think you need to list boost_thread before main.o -- the order is important.
I got a similar error fixed by adding the define line:
#define BOOST_THREAD_USE_LIB
before
#include <boost/thread.hpp>
which apparently makes the linker use the library libboost_thread-mt.a as a static library (as should) and not trying to link it dynamically or such.
as suggested here: Code Blocks, MinGW, Boost, and static linking issues
Late answer:
Here's a full description on how to compile boost yourself with MinGW
...and then also how to configure Eclipse to find the headers and libraries. It's not via qtcreator but should work as well.
http://scrupulousabstractions.tumblr.com/post/37052323632/boost-mingw-eclipse
In summary, compile using something like this:
cd F:\coding\boost_1_52_0
.\bootstrap.bat
.\b2 --prefix=F:\coding\some_installation_location toolset=gcc
variant=debug,release link=static,shared threading=multi install -j3
(the variant= ... line is meant to be on the same line as .\b2. The option -j3 is just for running 3 jobs in parallel.)
Just now I recompiled boost once again and now it works, so I assume it was just a case of bjam using the wrong mingw version for some reason