Undefined reference to boost::random::random_device constructor and destructor on MinGW-w64 gcc - c++

My OS is Windows 7 64-bit and C++ compiler I'm using is:
g++ (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 5.3.0
And I installed Boost version 1.60 using:
bootstrap.bat mingw
b2 install target=gcc
Then I tested is it working, using examples from Boost.Random tutorial.
With the first two everything was fine, but the third one gave linker errors about boost::random::random_device. I minimized the code to have only this:
// Compiled with:
// g++ -IC:/Boost/include/boost-1_60
// -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
// main.cpp
#include "boost/random/random_device.hpp"
int main() {
boost::random::random_device rng;
}
And I get the following errors:
C:\Users\Daniel\AppData\Local\Temp\cc5DfdjZ.o:main.cpp:(.text+0x15):
undefined reference to `boost::random::random_device::random_device()'
C:\Users\Daniel\AppData\Local\Temp\cc5DfdjZ.o:main.cpp:(.text+0x20):
undefined reference to `boost::random::random_device::~random_device()'
collect2.exe: error: ld returned 1 exit status
Here, on SO, I found that someone with similar problem added -lboost_system to flags, but for me it didn't helped.
Does anyone have any idea, why it isn't working? I checked, and I have random_device.hpp header in my Boost folder, with declarations of random_device() and ~random_device() in it.

I found what was wrong - the g++ command syntax, that I wanted to use to compile and link my code.
As I wrote in my question, I do this that way:
g++ -IC:/Boost/include/boost-1_60 -LC:/Boost/lib -lboost_random-mgw53-mt-1_60 main.cpp
While the correct one is with main.cpp (or any other source code file(s), that we want to include in compiling process) before the -L and -l flags.
For example:
g++ -IC:/Boost/include/boost-1_60 main.cpp -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
or even
g++ main.cpp -IC:/Boost/include/boost-1_60 -LC:/Boost/lib -lboost_random-mgw53-mt-1_60
Hope it will help anyone, who will make such silly mistake too.

Related

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.)

GoogleTest: CLang error compiling ASSERT_FALSE(false)

I downloaded googletest and built it in a subdirectory named build.
Then, I wrote the following code in a file named main.cpp:
#include <gtest/gtest.h>
TEST(FOO, BAR) { ASSERT_FALSE(false); }
Quite simple indeed.
It relies on the fact that a main function is already provided with googletest if you link the libgtestmain.a library.
GCC (v5.3.1) compiles it using the following command:
g++ -L./googletest/build/googlemock/gtest -L./googletest/build/googlemock -I./googletest/googletest/include/ -lgmock -lgtest -lgtest_main -lgmock_main -pthread -std=c++11 main.cpp
Anyway, clang (v3.6.2) does not compile using the same command:
clang++ -L./googletest/build/googlemock/gtest -L./googletest/build/googlemock -I./googletest/googletest/include/ -lgmock -lgtest -lgtest_main -lgmock_main -pthread -std=c++11 main.cpp
The error is the following one:
/tmp/main-4127ae.o: In function 'FOO_BAR_Test::TestBody()':
main.cpp:(.text+0x7b): undefined reference to `testing::internal::GetBoolAssertionFailureMessage(testing::AssertionResult const&, char const*, char const*, char const*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The code contains almost the sole ASSERT_FALSE(false) statement (that's a minimal, complete example and still it doesn't compile), so I'd say that the problem is not in the code itself.
The same problem arises also from the following statement:
TEST(FOO, BAR) { ASSERT_TRUE(true); }
Is that an issue due to googletest, to clang or whatever?
I'm trying to figure it out, but I'm a little bit in trouble while looking at the code of googletest.
NOTE
I've not been able to find neither an open nor a closed issue for googletest, so I'm to open also a ticket for it on github.
In a while I'll probably post the link to the issue.
As of GCC 5.1, g++ is not ABI-compatible with clang++. Some
bug reports: clang++ no longer ABI-compatible with g++
and Add support for gcc's attribute abi_tag (needed for compatibility with gcc 5's libstdc++).
Till this is fixed you need to link googletest-ing projects
with googletest libraries built with the same compiler.

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!

Cannot call XInitThreads

I have written an SFML C++ game, and tried to start using threads, but after a while everything crashes. After searching I found out the fix seems to be to call XInitThreads();
but this does not work somehow.
simplified code:
#include <X11/Xlib.h>
int main() {
XInitThreads();
//other stuff
return 1337;
}
The error message I get when i try to compile is "undefined reference to symbol 'XInitThreads'. Could it be that the header file is working but there is no file where that method is implemented?
"undefined reference to symbol" is a linker error, not a compiler error. If you get this message, the compiler has already finished compiled the file into an object file, but is unable to find the shared library which contains the function to link the object file into an executable.
If you're using gcc, it generally means you have to add some -l flags, like so:
$ gcc prog.c -lX11
note that the order of -lX11 in the compiler argument matters, you would get an error if you do this:
$ gcc -lX11 prog.c
/tmp/ccBCxiFT.o: In function `main':
:(.text+0x5): undefined reference to `XInitThreads'
collect2: error: ld returned 1 exit status
You should add link X11 library setting -lX11 to your project. If you are using Eclipse navigate to projectproperties->C/C++ Build->Settings->Tool Settings->GCC Linker->Libraries and add "X11"
Add header-
#include<X11/Xlib.h>
Compile your source code using-
gcc <filename.extension> -lX11
Tested in Ubuntu 16.04 LTS

What library do I need to link to use std::list in clang++?

I am trying to use the std::list class in C++, and I need to use clang++ to compile the program. g++ compiles the following program just fine, but I can't figure out how to compile/link it with clang++:
#include <iostream>
#include <list>
int main(){
std::list<int> L;
L.push_back(10);
std::cout << L.back() << std::endl;
return 0;
}
I've tried clang++ -lstdc++ listTest.cpp but still get the following error:
/tmp/listTest-3175a9.o: In function `std::list<int, std::allocator<int> >::_M_insert(std::_List_iterator<int>, int const&)':
listTest.cpp:(.text._ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi[_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi]+0x31): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Clang version:
clang version 3.4 (tags/RELEASE_34/final)
linux version:
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Red Hat Enterprise Linux Server release 6.5 (Santiago)
You should provide library arguments after the translation unit that uses them:
clang++ listTest.cpp -lstdc++
I should note that I couldn't reproduce your issue, but that could easily be down to differences in version/configuration (particularly w.r.t. a stdlib implementation selected for use by default).
I solved it on mine (redhat, clang 3.4, gcc 4.7.2).
By default this project was linking against /usr/lib/libstdc++. I have a build of gcc 4.7.2 installed in a separate location; when I add lines analogous to the following to the link step it works fine
-L${GCC_PATH}/lib -Wl,-R${GCC_PATH}/lib
... provided they appear in the link step before analogous statements for /usr/lib.
edit
You can use strace to help diagnose this problem; I did something like the following:
// copy the link step into a temp shell script
strace -f ./temp.sh |& grep -P 'lib(std)?c\+\+'
... which is when I realized I probably needed a different build of the C++ runtime because I saw it was finding and linking against the one in /usr/lib.