I wanted to use threads in my code and thought that the upcoming C++0x extensions would be handy as they will become a standard eventually. This seemed to be future-proof without the need to use additional libraries like the boost::thread.
Unfortunately I couldn't find useful information about which features regarding threads are currently supported by gcc. I'm using unique_locks which seem not to work, yet. This is the output of the linker:
.build_debug/src/core/simulator.o: In function `Simulator::start(int, int, int, int)':
simulator.cpp:(.text+0x1fc): undefined reference to `_ZSt4lockISt11unique_lockISt5mutexES2_IEEvRT_RT0_DpRT1_'
.build_debug/src/core/simulator.o: In function `Simulator::resume()':
simulator.cpp:(.text+0x351): undefined reference to `_ZSt4lockISt11unique_lockISt5mutexES2_IEEvRT_RT0_DpRT1_'
.build_debug/src/core/simulator.o: In function `Simulator::pause()':
simulator.cpp:(.text+0x417): undefined reference to `_ZSt4lockISt11unique_lockISt5mutexES2_IEEvRT_RT0_DpRT1_'
.build_debug/src/core/simulator.o: In function `Simulator::stop()':
simulator.cpp:(.text+0x4cd): undefined reference to `_ZSt4lockISt11unique_lockISt5mutexES2_IEEvRT_RT0_DpRT1_'
Does anybody understand these messages? I guess they are referring to the usage of unique_locks. But why do these errors occur?
My source code resembles this one:
std::unique_lock<std::mutex> lkIntra(intraMtx, std::defer_lock);
std::unique_lock<std::mutex> lkInter(interMtx, std::defer_lock);
std::lock(lkIntra, lkInter);
EDIT: I tried to compile this with gcc 4.3.X and 4.4.5. The linker was g++ 4.3, 4.4 and 4.5.
EDIT2: I just tried to use the boost equivalents to the std-threads. After adding the compiler flag "-lboost_thread" the compilation worked. Without which the linking process resulted in similar error messages. Now I'm wondering whether I need to do something alike when using standard threads (I already tried "-lpthread").
The current development version of G++ supports it: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00729.html
The 4.5.1 version doesn't seem to (at least, for me on Mac OS Intel).
Related
I am trying to add an external FORTRAN Code to OpenModelica 1.13.0. My function and model definitions are correct and the FORTRAN code normally works. But whenever I add a write(*,*) or read(*,*) method to the code I get the following error as OpenModelica Simulation output:
undefined reference to _gfortran_transfer_real_write##GFORTRAN_1.4
I wonder how can I solve this issue.
Thank you.
This (probably) happens because you are not linking gfortran with the simulation. If the library is shared (so, DLL, dylib), the dependency is usually handled automatically, so you are probably trying to link a static library (.a) or object file (.o, .obj).
In your external function, add an annotation Library="gfortran" or since you probably already have your library in there, Library={"mylib", "gfortran"}.
Also note that OpenModelica 1.13 is getting old and should be upgraded.
For OMShell one can call the setCFlags("-lgfortran") or inside OMEdit add -lgfortran at Simulation Setup > General > C/C++ Compiler Flags. It will solve the issue.
I've got the following situation:
Library X is a wrapper over some code in C.
Library A depends on library X.
Library B uses Template Haskell and depends on library A.
GHC bug #9010 makes it impossible to install library B using GHC 7.6. When TH is processed, GHCi fires up and tries to load library X, which fails with a message like
Loading package charsetdetect-ae-1.0 ... linking ... ghc:
~/.cabal/lib/x86_64-linux-ghc-7.6.3/charsetdetect-ae-1.0/
libHScharsetdetect-ae-1.0.a: unknown symbol `_ZTV15nsCharSetProber'
(the actual name of the “unknown symbol” differs from machine to machine).
Are there any workarounds for this problem (apart from “don't use Template Haskell”, of course)? Maybe library X has to be compiled differently, or there's some way to stop it from loading (as it shouldn't be called during code generation anyway)?
This is really one of the main reasons that 7.8 switched to dynamic GHCi by default. Rather than try to support every feature of every object file format, it builds dynamic libraries and lets the system dynamic loader handle them.
Try building with the g++ option -fno-weak. From the g++ man page:
-fno-weak
Do not use weak symbol support, even if it is provided by the linker. By default, G++ will use weak symbols if they are available. This option exists only for testing, and should not be used by end-users; it will result in inferior code and has no benefits. This option may be removed in a future release of G++.
There is another issue with __dso_handle. I found that you can at least get the library to load and apparently work by linking in a file which defines that symbol. I don't know whether this hack will cause anything to go wrong.
So in X.cabal add
if impl(ghc < 7.8)
cc-option: -fno-weak
c-sources: cbits/dso_handle.c
where cbits/dso_handle.c contains
void *__dso_handle;
By default, Visual Studio compiles a project to use the Multi Threaded DLL, found in the Visual Studio runtime. I want to compile my program using only /MT instead of /MD. Granted, that most systems already have this installed, and it's also available as a re-distributable.
When I change /MD to /MT, I get an error:
MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _free already defined in LIBCMT.lib(free.obj)
And four or five similar errors.
To try and fix this I removed LIBCMT.LIB from the default libraries.
I then get the error:
libcpmt.lib(_tolower.obj) : error LNK2019: unresolved external symbol __calloc_crt referenced in function __Getctype
Removing MSVCRTD.lib from the default list leads to similar errors?
It should be noted that:
-This is an OpenGL project, using the glfw library.
-I am using the SOIL image library by lonesock for texture loading.
Without any further precise information, I would say your first problem is that you're somehow mixing release and debug versions of libraries. MSVCRTD.lib is the debug version of MSVCRT.lib.
Either you have some debug settings hanging around in your own projects, or you're linking against debug versions of libraries you're using.
Never ever mix debug and release versions. If you're lucky you get an error like this. In some rare situations all magically seems to work until it doesn't.
i've got a small opengl 3.2 app that i've been developing on linux using the standard gnu tools (gmake/gcc). the code seems pretty portable--i had no problems running it on osx until i started using gl3 features that the mac mini gl drivers don't seem to support. i've got a bootcamp partition with windows xp on the same mini, and i'd like to run my app there if possible.
the windows drivers definitely support gl 3.2, but i'm having trouble linking. this seems like a really common issue, but i haven't found any answers online that address using opengl > 1.2 under cygwin. i'm using glew-1.5.5 and linking like so:
g++ -o glToy *.o -L/cygdrive/c/Program\ Files/glew-1.5.5/lib -lglew32 -lglut32 -lglu32 -lopengl32
but i get a whole lot of this sort of output:
Program.o:/home/Jacob/glToy/Program.cpp:134: undefined reference to `__imp____glewUseProgram'
Program.o:/home/Jacob/glToy/Program.cpp:235: undefined reference to `__imp____glewActiveTexture'
Program.o:/home/Jacob/glToy/Program.cpp:73: undefined reference to `__imp____glewGetShaderiv'
...
any ideas what i'm doing wrong? or perhaps this isn't a workable setup? other ideas for getting this going on the mac mini (2009 version)? thanks!
you can also skip linking, just get glew.c and put it in /include (not /include/GL like glew.h) and then change your #include to <glew.c>
you aren't linking glew properly or glew is broken... nothing to do with gl itself
the easy fix is just to use the extension api and forget about glew.
I have an old c++ project compiled with VC6.
I need to statically link a new library to implement a new functionality.
Unfortunately the new library define a symbol (i.e. _inflate) that is already defined in a previously linked static library.
Of course I cannot get rid of either library, and of course I have no access to the library's source code.
Is there a way to avoid the linker error (LNK2005)?
If you know that the two versions of _inflate are identical, or at least "compatible", then you can use the /FORCE:Multiple linker option to force it to ignore name clashes.
Of course, if it links to a version of that code that is "incompatible" in any way it could cause undefined behaviour.