OpenFrameworks and Boost - c++

In the last days I have been learning about the Boost and Open Frameworks. I did some programs using them, however when I use them in the same program g++ gives me the error
undefined reference to `boost::system::generic_category()'
still I'm linking boost_system. Is there some reason to not use both libraries in the same program?

That is a linker error, it needs an object file or library that provides the definition of function boost::system::generic_category.
Normally, to link to boost::system library add -lboost_system to the linker command line.
See Link Your Program to a Boost Library for more details.

Here is the openFrameworks addon for Boost.
Download and see 'How to use' instructions.

Related

How can I compile SDL2 and GLEW applications statically on Linux?

I am attempting to compile an OpenGl application that uses SDL2 and GLEW in such a way that it will run on any version of Linux it may find itself -- not just where it was originally compiled. To do this, I have tried several things none of which work.
I have tried directly linking to .a files produced by running make in the extracted root directory of GLEW and SDL from each library's website download. This produces the following errors:
/usr/bin/ld: /opt/SDL2-2.0.4/build/.libs/libSDL2.a(SDL_syssem.o): undefined reference to symbol 'sem_getvalue##GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
I have tried building as I do with dynamically linked libraries, which works fine except for the cross-platform capabilities, (with pkg-config --libs sdl2 and pkg-config --libs glew) but adding -static, at which point I get the following errors:
/usr/bin/ld: cannot find -lGLEW
/usr/bin/ld: cannot find -lGL
When I change the previous scenario to point to my statically compiled GLEW libraries, I get undefined reference errors to OpenGl functions along with undefined reference errors like the following from many SDL functions. Adding -lGL does not change anything.
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_dynapi.o): In function `SDL_InitDynamicAPI':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_dynapi.o): In function `SDL_InitDynamicAPI':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_dynapi.o): In function `SDL_InitDynamicAPI':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_sysloadso.o): In function `SDL_LoadObject_REAL':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_sysloadso.o): In function `SDL_LoadObject_REAL':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_sysloadso.o): In function `SDL_LoadFunction_REAL':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_sysloadso.o): In function `SDL_LoadFunction_REAL':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_sysloadso.o): In function `SDL_LoadFunction_REAL':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_sysloadso.o): In function `SDL_UnloadObject_REAL':
When I try using pkg-config --libs --static <library name> for all libraries, I get the following error:
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libSDL2.a(SDL_dynapi.o): In function `SDL_InitDynamicAPI':
/usr/bin/ld: cannot find -lasound
/usr/bin/ld: cannot find -lpulse-simple
/usr/bin/ld: cannot find -lpulse
/usr/bin/ld: cannot find -lsndio
/usr/bin/ld: cannot find -lwayland-egl
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libwayland-cursor.a(libwayland_cursor_la-xcursor.o): In function `XcursorImagesDestroy':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libXcursor.a(file.o):(.text+0x7d0): first defined here
/usr/bin/ld: cannot find -lGLEW
/usr/bin/ld: cannot find -lGL
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(GetDflt.o): In function `GetHomeDir.part.0':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(GetDflt.o): In function `GetHomeDir.part.0':
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.a(xim_trans.o): In function `_XimXTransSocketINETConnect':
collect2: error: ld returned 1 exit status
NOTE: All of the output above is from the command g++ -o /path/to/outputExecutable <list of object files>.o <libraries as described above>
NOTE: I do not think this question is a duplicate of any other question on the Stack Exchange network because I have been trying to figure this out for about one and a half months and I have seen a very large number of these questions and tried everything in them, thus, even if the symptoms are the same the underlying problem is different.
NOTE: This is a closed-source application so dynamic linking is not an option for it requires distributing the source code to allow users to build the binaries on their own systems.
NOTE: I am currently trying to get this to compile with Linux via g++, but, I do intend to use mingw to distribute this application for Windows as well. Any advice that works there is preferable to Linux only advice, but, I can ask another question if I can't figure out that part from what will end up here.
NOTE: I am using Ubuntu 16.04 LTS x64 to compile.
Thank you in advance for even getting this far in this question. Sorry for the wall of text, but, I wanted to provide as much information as possible. I look forward to any answers!
Older Loki games did full static linking. Probably not worth it anymore, and far more difficult if you use external libraries.
Libraries are often not self-sufficient, requiring other libraries, .... Dynamic library have dependency information built-in, but static library is just an archive of .o files - it may depend on something but there is no special section that describes what extra libraries should be used. Your first error says that libSDL2.a uses symbol sem_getvalue##GLIBC_2.2.5 (sem_getvalue function, marked with glibc version) that cannot be resolved - most likely because you didn't add -lpthread to your linker flags. (libSDL.so depends on some version of pthrtead among other things - that's why you don't need to manually link with it if you don't use it directly).
GLEW should have no problems with static linking. You need to be more specific on errors you're getting. Maybe you got your libraries order wrong and linker cannot resolve GL functions. Need to see actual linking line and some 'undefined reference' errors to be more specific.
pkg-config's --static flag should give you dependencies list (e.g. -lpthread should be in the output of sdl2-config --static-libs among many others), but it does not by itself produce static linking with given library. To request static linking, there are -static gcc flag that generates static executable (hard!) and -Bstatic linker flag to use static version for all libraries specified after it (so that way you can use some static libraries and some dynamic). -Bdynamic is a counterpart, asking to use dynamic libraries. E.g. to use static SDL and GLEW but dynamic GL linking line should be something like (if you use gcc to link, not ld directly) gcc ${OBJECT_FILES} -Wl,-Bstatic -lSDL2 -lGLEW -Wl,-Bdynamic -lGL -lpthread -ldl -lm <everything else SDL2 requires - query with sdl2-config>.
Your /usr/bin/ld: cannot find -lasound lines may have two reasons - static linking or related to the fact that you don't have development libraries installed (e.g. libasound2-dev, libpulse-dev, ... - at least they called that on debian, it is unlikely ubuntu have different names). 'User' libraries usually contains e.g. libasound.so.2 but linker will not find this library as it have a version in it. Development package contains headers and symlink libasound.so -> libasound.so.2 - that way linker knows what to use. If you use it indirectly via SDL2 - you don't need that, shared SDL2 already have a link to versioned library.
However there may be little point in doing so at all. You can distribute requred shared libraries with your software and use them either via rpath or LD_LIBRARY_PATH environment variable (maya, steam, etc... - almost everyone doing these this days). Moreover, even with static SDL2 end user can override SDL2 with their own (this is a feature intentionally implemented in SDL2). If there is a bug (or just very different environment) and your software is no longer gets updates - there is a chance that problem may be fixed by just replacing shared libraries. Would you really mind people running your program on wayland or mir if your original SDL2 had only X11 support?
in such a way that it will run on any version of Linux it may find itself -- not just where it was originally compiled is far more complicated, and honestly almost unrealistic (unless you have quite small program and use only very limited set of libraries with a good forward/backward compatibility - but even then it may be hard). One of big problems is glibc; usually it is a good idea to use lowest possible version of glibc to compile your program.
To sum it up, it is possible, but it does not help much.

How can I see what libraries Mingw32 links by default?

I'm using Mingw32 compiler to build a C++ app.
I'm passing -nostdlib to the linker because I only want to link the libraries I'm going to actually use.
However I'm running into a problem with the C++ standard library.
When I link with libstdc++ I get the following error:
undefined reference to '_Unwind_SjLj_Register'
So clearly libstdc++ isn't the right library to link with.
Is there any way of seeing what libraries Mingw32 links with by default when building a C++ app?
What libraries are being excluded when the flag -nostdlib is passed to linker?
Thanks.

Linker error for Raspberry Crosscompile

So I installed the toolchain given by raspberry which works good , I managed to compile the library used by the GUI
I have installed all dependancies for the GUI using
xapt -a armhf -m [packet]
But when the linker has to link all librairies it give me the following error and I'm stuck.
arm-linux-gnueabihf-ld: pkcs11dialogs.o: undefined reference to symbol '_Znwj##GLIBCXX_3.4'
/usr/arm-linux-gnueabihf/lib/libstdc++.so.6: error adding symbols: DSO missing from command line
Any help will be very appreciate !
Merci !
The problem is that you're compiling C++ code and not C. C++ needs a runtime support library, the native GCC library is called libstdc++ and you need to link with that.
It's very easy to do: Use the g++ (arm-linux-gnueabihf-g++ in your case) frontend program to link as well as compile., it will automatically add the C++ runtime library. Or add it manually to your linker command.

Problem linking c++ code using boost with mingw

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

linking boost.asio

I have a problem linking boost.asio. It uses boost.system and the linker errors start with:
/boost_1_39_0/boost/system/error_code.hpp:205: undefined reference to `boost::system::get_system_category()'
which means I need to link boost.system. I already built boost and I have now several lib files.
boost_system-mgw32-d-1_39.dll and lib
libboost_system-mgw34-d-1_39.lib
libboost_system-mgw34-mt-d-1_39.lib
libboost_system-mgw34-sd-1_39.lib
and some more. How do I link them? Which one do I use? Do I copy all of them together?
My system is win32+mingw+eclipse cdt+qt 4.5.2+qt integration for eclipse. I already learned that I need to at a LIBS= section to my .pro file.
Can you give my some hints?
Thank you.
The libraries are named based on whether or not multi-threading support is enabled, static and dynamic linkage, debug and release mode, and more. Here's some details:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix-variants.html#library-naming
I'm not sure about eclipse as I don't use it, but with gcc (and mingw) you need to specify both a directory to find the libraries in (-L) and the file to link with. For example, if you wanted to link with the single-threaded debug version:
-L/path/to/libraries -lboost_system-mgw34-sd-1_39