I'm trying to port/build some of my code written for gcc (on linux) as a dll on windows. First I tried to build in under VC++ but there were so many errors/warnings (mainly in VC's own include files, which didn't really make much sense to me :)) so I installed MinGW distro (which includes Boost libraries). Compilation went quite smoothly, however linking failed with undefined references to functions from boost libraries. The "-t" parameter showed that the linker doesn't actually use the boost libraries for some reason (yes, the -L path is correct, the libraries are there, linker doesn't complain when I use -l).
After much googling I found out that the order is the problem, that I have to place my -l parameters after all my .o files (because of dependencies). This seemed to solve all the problems except one undefined reference to thread library. Again -t showed that this library is actually not used by the linker (not in the list) the others are (I use boost_system and boost_date_time as well). I played with the order of the parameters again but the result was the same. Any idea what am I missing?
The error is:
c:/x5/cpp/build//timed_cond.o:timed_cond.cpp:(.text$_ZN5boost6detail24basic_condition_variable7do_waitINS_11unique_lockINS_5mutexEEEEEbRT_NS0_7timeoutE[bool boost::detail::basic_condition_variable::do_wait<boost::unique_lock<boost::mutex> > (boost::unique_lock<boost::mutex>&, boost::detail::timeout)]+0x246): undefined reference to `_imp___ZN5boost11this_thread18interruptible_waitEPvNS_6detail7timeoutE'
I use same versions of Boost library (1.44.0) on both platforms
Ok, I found the answer. Looks like the problem is in boost libraries being static in MinGW-distro. Normally they are configured to be linked dynamically and that caused above issue. This answer explains it...
Related
I've recently been trying to make use of the boost libraries and whilst I have been able to include header-only libraries just fine I'm now stuck on including the linked libraries. I've managed to use b2 to build the libraries with gcc and then link to them, but whilst trying to include thread I get these errors.
I've read that these errors can be caused by using the wrong toolset for building but I can't see how I could of got that wrong as I've only ever used mingw and I used toolset=gcc when building. Here are my toolchain executables just in case I have done something wrong there. What am I doing wrong?
Turns out my path variable was incorrect and included Haskells mingw directory instead of the one I was using. After getting rid of Haskell from my path and adding the directy of the version mingw that I was using everything worked as intended.
I have a C++ based dynamic library that I have built for the big 3 OSs that relies heavily on boost. Currently, I am compiling it for the raspberry pi. It took me a while to find the magic words to get the library to even build (-frepo as a compiler flag was the key, but I confess that I am not certain why this is the case).
Now, when I try to link to the library, I get an 'undefined reference' error to every boost call that my library makes, i.e.:
//`libmylib.so`: undeifined reference to `boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr()'
When I build libmylib.so, I also build a custom version of boost as libboost.a. This all compiles and links fine on other OSs and non-ARM architectures so I tried putting -lboost as one of the flags, but I still get the same plethora of undefined reference errors form libmylib.so.
Needless to say, all my paths are correct.
It seems like linking behaves a bit differently on the raspberry pi than it does on other linux systems. For example, I built a static library (libmythread.a) that uses libpthread. When I link to that libmythread.a, I also get undefined reference errors unless I also use -lpthread in the build recipe. On my Thinkpad running Fedora, I would never have to do this since I included -lpthread in the compilation of the static library libmythread.a.
I would love to find a tutorial or guide that explains these discrepancies. I would also love to overcome them!
I also tried the same build on a conventional linux machine and everything linked fine, no problem. At least I know that my build process is OK. This does open up the possibility, though, that the -frepo flag is doing something funny that I don't understand and that this could be the root of the problem.
Solved. In the end, the trouble stemmed from the -frepo flag. This was necessary to compile a file called legacy_abi.cpp that is part of my library to allow third party developers using older and more exotic OSs/compilers. This isn't needed on the Pi, so I just removed it from the offending file from the build, dropped the -frepo flag and happy happy.
One final note, aptitude (for Pi, anyway) only supplies boost up to 1.49 (as far as I can tell). My project requires boost >= 1.50. This is an inherited project, so I'm still discovering all its little idiosyncracies.
I must say, I'm new to using Boost libs, but I have used them for a few of my projects, and have been super pleased with them.
Now, I would like to get all files with certain extension in one of my folders, so, looking it up online, I found this>How to get list of files with a specific extension in a given folder
I'm using Code Blocks on Windows 7.
I have done everything it seemed required, and when I try to compile it, I get three errors>
C:\boost_1_58_0\boost\system\error_code.hpp|221|undefined reference to
boost::system::generic_category()'|
C:\boost_1_58_0\boost\system\error_code.hpp|222|undefined reference to
boost::system::generic_category()'|
C:\boost_1_58_0\boost\system\error_code.hpp|223|undefined reference to
`boost::system::system_category()'|
I was looking it up online, and found that, besides pointing my "Search directories (compiler and linker) to boost installation, I need to point it directly to boost system lib somehow.
I tried -lboost_system in my Linker settings, but that didn't solve it.
I'm hardly an expert here, so I'm asking you guys if you can help me.
Does anyone have any ideas?
You need to provide the path where your lib is with the -L option of GCC.
Check this section of Boost documentation
I'm trying to link the thread library of boost 1.50.0 and am having some problems. The problem is that the implementation of the thread cannot be found.
I've checked around here, on random sites and on the official manuals and concluded that there can only be one reason for this (since the actual library I'm linking contains the correct files). There is no auto-linking in MinGW. This means there can be no platform implementation for the threads available (and hence the error).
One of the errors I'm getting is:
undefined reference to `imp__ZN5boost6thread4joinEv'
that comes from myTread.join().
So my questions is, what is the library (or libraries) I need to link in addition to the boost thread library (in this case named libboost_thread-mgw46-mt-1_50.a)?
And furthermore, is there any documentation for all library dependencies in boost?
I could of course be completely wrong, so any help appreciated!
Currenty I'm linking only boosts libraries; threads, chrono and system.
EDIT
To clarify, I'm linking with the following command:
g++ -LPATH_TO_BOOST\lib -o test-boost-thread.exe src\test-boost-thread.o -lboost_thread-mgw46-mt-1_50 -lboost_chrono-mgw46-mt-1_50 -lboost_system-mgw46-mt-1_50
I've tried changing positions of the libraries, but that didn't help.
In your case, given the file name that you posted, the linker line would be -lboost_thread-mgw46-mt-1_50 (remove lib and .a/.so/.lib). There might be (or you might want to create) a symlink that points to it like libboost_thread.a -> libboost_thread-mgw46-mt-1_50.a, in which case you can use the shorter -lboost_thread.
Hmm, seems like I completely forgot about the BOOST_THREAD_USE_LIB flag. Setting this made it work.
Strange error though.
I used CMake and Visual C++ to build the HyDE library. Then, still in VC++, I was able to successfully create code and build an executable that links into HyDE.lib and the HyDE header files.
I then discovered that in order to work with others at my company, it would be preferable to develop in Eclipse CDT. Knowing very little about Eclipse CDT, I created a default hello world project, deleted the code and then dumped in all of my code into the src folder. Then I attempted to change the includes and lib path and libs to mirror what had worked in VC++. At this point everything seems to compile, but I get an error in linking:
/cygdrive/c/EclipseWorkspace/425HyDE/Debug/../src/FS5HyDE.cpp:16: undefined reference to `HyDEAPI::HyDE::HyDE(HyDESystemModel::SystemModel*, bool)'
(There are many more errors like this, all referring to HyDE methods.) Here is what is being run at the command line:
g++ -L"C:\Progra~1\boost\boost_1_42\lib" -L"C:\EclipseWorkspace\HyDE" -o"425HyDE.exe" ./src/Adapter_FS5HyDE.o ./src/EPSCommands.o ./src/EPSCurrentSensor.o ./src/EPSFault.o ./src/FS5HyDE.o ./src/HyDEObservation.o ./src/MCDH.o ./src/MCDH_Module.o ./src/PDBComponent.o ./src/PowerSystem.o ./src/Program.o ./src/SSPCComponent.o ./src/Telemetry.o ./src/TelemetryReport.o -l:libboost_thread-vc90-mt-gd-1_42.lib -lHyDE
This is definitely not a library ordering problem because I've the other ordering as well (there are only two). Is it possible that there is a problem with compiling HyDE.lib in VC++ (which uses a Windows compiler) and compiling my program with g++? Could there be a problem in the way that Eclipse CDT is autogen'ing the makefiles? Any other ideas?
(Note: there appear to be plenty of others questions on SO with similar problems, but after reading through them I have yet to find one that addresses my problem.)
Classic missing symbol error. Which source file defines:
HyDEAPI::HyDE::HyDE(HyDESystemModel::SystemModel*, bool)' ?
Was this file added to the compilation? Can you spot it on the command line you pasted?
If this symbol belongs to an external library, after adding the directory path with -L , you could add the name of the specific library you want to link with your program using -l.
I'm going to suggest that you try to add to the compilation command the directory path to HyDE.lib, followed immediately by the library name, like this:
-L"C:\path_to_hyde_library" -l:HyDE.lib
and then tell us what happened.
Solution: Since the HyDE library was compiled with the Visual Studios compiler and I'm attempting to build the code that links to it with the Cygwin toolchain the two compilers use different name mangling schemes so that the latter linker can not find the expected symbols in the HyDE library. The only solution that I've found is to recompile the HyDE library with the Cygwin toolchain or compile the new code with whatever compiler Visual Studios is using. (grumble grumble)
./src/FS5HyDE.o and ./src/HyDEObservation.o should be the latest parameter if other object files (*.o files) need them, it means that the most needed object files should be appeared as last as possible in the parameters list.