OpenCV: Undefined reference to xcb_poll_for_reply - c++

As of late I have been getting the following error whenever I try to compile any program that uses the open cv libraries, I use g++ to compile:
g++ Example.cpp -o Ex `pkg-config opencv --cflags --libs`
No matter the content of the file (I have checked with programs that worked a couple of weeks ago) I always get the following error:
/usr/lib64/libX11.so.6: undefined reference to `xcb_poll_for_reply64'
/usr/lib64/libX11.so.6: undefined reference to `xcb_wait_for_reply64'
Do you have any idea of what might be the cause? (and how to fix it)
An example program that fails to compile:
#include "path/opencv2/highgui/highgui.hpp"
#include "path/opencv/highgui.h"
using namespace cv;
int main (int argc, char * argv[])
{
Mat image = imread(argv[1], CV_LOAD_IMAGE_GRAYSCALE) ;
return 0;
}

Add -lxcb to your command line (this will instruct the linker linking w/ the xcb library). Please make sure the 64b version of xcb is in the linker path (you can always put it explicitly via the -L switch)

The error was caused by some changes done to the libX11.so.6, talked with the FE machines support and they fixed it.

Related

Cannot use filesystem::path when compiling with MacPorts LLVM / Clang 15.0.5 on macOS 10.13 or 10.14 [duplicate]

I was trying to out the new filesystem STL library, but for some reason am getting errors. The Clang++7 website indicates that it should support the new filesystem library – indeed clang is running ahead of g++ I believe.
I used some code from another Stack Exchange post, so it should be valid based upon the number of upvotes. This could should go to the specified directory and print all files in that directory. Here is the code.
#include <iostream>
#include <string>
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
int main(int argc, char *argv[])
{
std::string path = "/home/.../Downloads";
for (const auto & entry : fs::directory_iterator(path))
{
std::cout << entry.path() << std::endl;
}
}
The error messages I am getting are:
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `main':
/media/.../clangcpp/filesystem_app/main.cpp:13: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator*() const'
/media/.../clangcpp/filesystem_app/main.cpp:13: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator++()'
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `path<std::__cxx11::basic_string<char>, std::experimental::filesystem::v1::__cxx11::path>':
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/experimental/fs_path.h:198: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `directory_iterator':
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/experimental/fs_dir.h:188: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::directory_iterator(std::experimental::filesystem::v1::__cxx11::path const&, std::experimental::filesystem::v1::directory_options, std::error_code*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I made sure to include the experimental/filesystem header instead of just filesystem which removed any red squiggles in Clion. I tried to compile from CLion as well as from the command line. The compilation string I used was:
clang++-7 -Wall -std=c++17 main.cpp -o app
Does anyone have a sense of what is wrong here? In the compile error messages I see the reference to std::experimental::filesystem::v1::__cxx11::.. and I am wondering why this does not say cxx17, but I was not sure if that was the cause of the issue. I explicitly indicated c++17 in the compilation string above.
filesystem is still experimental and requires an extra library.
If you are using libstdc++, link with -lstdc++fs (or target_link_libraries(${PROJECT_NAME} stdc++fs)).
For libc++, use -lc++fs (similar for the CMake command).

C++ - Undefined reference to "sodium_init"

I am attempting to make a testing application using libsodium, however I am getting the error:
main.cpp:6: undefined reference to `sodium_init'
I ran the following commands to install in as the root user.
$ ./configure
$ make && make check
$ make install
This the code that is having the issue.
#include <stdio.h>
#include <sodium.h>
int main(int argc, char **argv)
{
if (sodium_init() == -1)
{
return 1;
}
printf("libsodium had no issues!\n");
return 0;
}
I am using CodeLite as my IDE, and my C++ compiler options are the following:
-g;-O0;-Wall;-lsodium
The options were default and I added -lsodium to the list.
Attempting to compile main.cpp directly from the terminal with the following command g++ -lsodium main.cpp throws the same error.
Could someone please help me with my issue.
Libraries for linking are searched in order, so you need to place the libraries after your local translation units:
g++ main.cpp -lsodium
In your IDE, make sure you add -lsodium as a linker argument.

Embedding SpiderMonkey JS

I'm working on a C++ application. I would like to embed SpiderMonkey in the application.
I'm working with CMake, but I couldn't get that build. So, in an attempt to reduce complications, I tried the example code on this page. This wouldn't link using cmake or gcc from the command line.
So, even simpler, just to ensure I can link properly I am trying to get the following to work.
From the command line with gcc:
g++ --std=c++11
-I/home/thetasinner/moz/js/src/build_DBG.OBJ/dist/include
-L/home/thetasinner/moz/js/src/build_DBG.OBJ/js/src -DDEBUG
-Wl,--verbose -lmozjs-54a1 -lm -lz -ldl test.cpp -o test
On the following minimal code example:
#include <iostream>
#include <stdexcept>
#include "jsapi.h"
#include "js/Initialization.h"
int main(int argc, char** args) {
if (!JS_Init()) {
throw std::runtime_error("failed to initialise.");
}
std::cout << "It's alive!\n";
JS_ShutDown();
return 0;
}
Even this doesn't link. I get the errors
/tmp/ccqjx5RY.o: In function `main':
custom.cpp:(.text+0xf2): undefined reference to `JS_ShutDown()'
/tmp/ccqjx5RY.o: In function `JS_Init()':
custom.cpp:(.text._Z7JS_Initv[_Z7JS_Initv]+0xa): undefined reference to
'JS::detail::InitWithFailureDiagnostic(bool)'
collect2: error: ld returned 1 exit status
The headers are found and the linker is finding the mozjs library
attempt to open /home/thetasinner/moz/js/src/custom_build_DBG.OBJ/js/src
/libmozjs-54a1.so succeeded
-lmozjs-54a1 (/home/thetasinner/moz/js/src/custom_build_DBG.OBJ/js/src
/libmozjs-54a1.so)
I am working on Linux (Ubuntu 16.04 and Debian 8.7 tried) because that's where the build tools are. I don't even want to touch Window's yet.
The 'js' executable built in the spidermonkey build works fine, which I assume has the lib I'm trying to link inside it. So I would have thought the lib itself is built okay.
Can anybody help me resolve these linker errors? There are lots of answers to questions about much older versions of SpiderMonkey, but there's nothing for more recent versions. I'm interested in version 45 (which I've tried with very similar errors) or the tip version 52.
I'm comfortable enough digging around in the code working out how to do what I want with it once it builds, hence the interest in the latest version which isn't properly documented, I'm just completely stumped with the building step.
I suspect it's just an ordering problem on the command line:
g++ --std=c++11
-I/home/thetasinner/moz/js/src/build_DBG.OBJ/dist/include
-L/home/thetasinner/moz/js/src/build_DBG.OBJ/js/src -DDEBUG
test.cpp -o test
-Wl,--verbose -lmozjs-54a1 -lm -lz -ldl
Compilation first, followed by linking, with libraries in order of dependency. (My first guess was you'd neglected to mention mozjs on the command line. It took a second look to see it was just in the wrong place.)

Fail to use SDL with MinGW on windows

I wanted to start learning to program with SDL. So I download x86 for windows,
put all the lib and the include in MinGW. But when I compile it doesn't know the SDL functions exist.
# define SDL_MAIN_HANDLED // somehow it want it to not define its own main
#include <iostream>
#include <sdl2/SDL.h>
using namespace std;
int main( int argc, char* argv[] ) {
SDL_SetMainReady(); // just for check
return 0;
}
I read that the linking need to be in specific order (mingw32, SDL2main and then libSDL2), But I think Eclipse run a wrong compiling command.
The eclipse command:
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\fire.o" "..\\src\\fire.cpp"
g++ -o fire.exe "src\\fire.o" -lmingw32 -lSDL2main -llibSDL2
src\fire.o: In function `main':
C:\Or\C++\Projects\fire\Debug/../src/fire.cpp:16: undefined reference to `SDL_SetMainReady'
collect2.exe: error: ld returned 1 exit status
Do you think I miss something?
I think you need to change -llibSDL2 to -lSDL2.
Ok I solve it. I'm not sure if the problem was lack of support on 32 bit or the fact that minGW and SDL were from different compilers that probably didn't match..
But what I did is to delete minGW from my pc and download WinBuild. WinBuild its a download manager that offer a lot of libs and tools, include minGW64 bit and SDL.
The advantage is that they were all compile from the same compiler with the same configurations.
after that i change the path to minGW in to the new 64 bit path inside WinBuild folder, add g++ from Winbuild the to the path as well and restart.
Then, adding and linking work without any problem!
I still need to put # define SDL_MAIN_HANDLED on the start to make it work, but its work!

Linking OpenGL using MinGW on Windows x86_64

I would like to develope an application using C++ and OpenGL for Windows 64bit.
I am using the following Compiler x86_64-w64-mingw32-g++.
The following code snippet (Test.cpp) is sufficient to trigger the error I get:
#include <GL/gl.h>
int main(int argn, char **argv) {
glClear(GL_COLOR_BUFFER_BIT);
}
(I know this code is meaningless, but it is sufficient to trigger the error during linking.)
I use the following Makefile:
Test:
g++ -lopengl32 -o Test Test.cpp
This yields the following error:
undefined reference to `__imp_glClear'
I have no clue what I am missing, and would be very thankfull for any advice.
For me the g++ main.cpp -o run.exe -lopengl32 seems to work just fine, so you most likely wont need -Wl,--enable-stdcall-fixup to compile it.