I have a whole project that I had to move from one machine to another and since moving the code, it has been coming up with an error of undefined reference to 'CLSID_FileOpenDialog'.
I'm using the x64 8.1.0 Posix SEH release though I have tried a couple of other versions, such as 7.3.0. I need to use the posix version as I have mutexes in my code and these do no work in the win32 versions.
Is there some library of similar that I need to add to the linker to stop this from happening?
I was using Mingw64 on the old machine so cannot understand why this is happening.
Thanks for any help!
Literally after posting this, I noticed that my project settings didn't include the "ole32", "comctl32", "oleaut32" and "uuid" libraries.
Adding these fixes the issue.
Related
So I spent all day trying to get c++ threads to work with eclipse Kepler and mingw. I have tried adding the -std=c++11 flag, -lpthread flag, another flag and even added a symbol to the table GXX_EXPERIMENTAL_CXX0X. My latest attempt at getting threads to work is to follow this advice
std::thread is not a member of namespace std using Eclipse Kepler MinGW
which says:
Plain MinGW cannot support std::thread. You will need to use a
MinGW-w64 toolchain (such as those shipped with Qt 5) that has "posix"
threading enabled, so that libstdc++ exposes the thread, mutex and
future functionality. You can find an installer here.
Now I have a folder called:
C:\Program Files\mingw-builds\x64-4.8.1-posix-seh-rev5
How do I get this to work with eclipse so I can use threading? Do I have to replace something in my mingw file or somehow link this to eclipse? I have no clue where to even begin.LET ALONE if this is recommended.
Take a look at this FAQ
I think it is along the lines of what you want to do because basically you need to show eclipse a different version of MinGW. It looks like you'll need to set the PATH variable correctly so eclipse can find the new version.
I am quite new to programming, and was working on a project at school which I hoped to take home and complete, and so I copied all the files (including that of code::blocks) thinking that I would simply be able to get it up and running quickly! However when I open the file and attempt to run the program I get a list of errors such as:
undefined reference to '_Unwind_SjLj_Register'
undefined reference to '_Unwind_SjLj_Resume'
undefined reference to '__gxx_personality_sj0'
undefined reference to '_Unwind_SjLj_Unregister'
and many more..
I assume this problem is likely caused by missing files since the computer I copied it from likely had a different directory. Or could it be because I am on a 64 bit version of windows 7, compared to the 32 bit version I was working on? (I really don't know just trying to think of some potential ideas).
Does anyone know of a solution? Should I simply uninstall and attempt to reinstall with minGW and SFML myself? Or is there a way to get around this without having to uninstall.
Thanks
Your compiler seem to be incompatible. If you've installed Qt with MinGW bundled together, you'll most likely have gotten MinGW 4.8.0 DW2 installed - it's the compiler for which a Qt package exists. On the other hand, if you've used the compiler that shipped with Code::Blocks you've most likely used the TDM 4.7.1 SJLJ compiler.
If you now try to use the same SFML libs or object files with from one compiler with another compiler, it won't work. Instead you'll have to option to either use the same compiler on both systems or compile everything freshly for both compilers.
I wrote a C program and works fine on Windows 7 and Linux, but when I execute it on Windows XP I get the error:
"_except_handler4_common could not be located in the dynamic link library msvcrt.dll"
I researched it and some people said to delete the DLL "dwmapi.dll" which I don't have, so that's not my problem.
Some one told me to use depends walker(depends.exe) to find who is using msvcrt.dll. I did and find that pcre library is using it and there actually is a problem with it, but I don't have any idea how to solve this. Can any one help me?
Here's image of what depends walker show me:
Reason possibilities (afaiu):
a) You linked to msvcrt.dll specifically when building - this should
not happen according to Microsoft support unless you specifically do
it.
b) Some other installed or copied program/driver on your XP that
links to "wrong" version of msvcrl.dll is being triggered.
Depending on what the reason is,
here are few ideas to resolve:
1) There might be some program/driver/etc. installation on your XP
machine that has introduced "Vista/Win7 related crap" onto it. It is
said (by the internets) that PCRE3.DLL belongs to "GnuWin32 Non-system
processes". That means you can try to find it and rename/delete it. Or
delete the program you that uses it.
2) Installing the redist for XP of the C++ redistributable that you
used to build on Win7 might help. This is link for VS2005: (darn..
use google - i can only give two links per post :P)
Rebuilding:
3) Just build the file from sources on your XP machine using some
VisualStudio version you can get on it. And check those VS project
properties!
4) Fix your build on Windows7. You might be linking to
_except_handler4_common in msvcrt.dll in your Windows 7 build. Make sure that you do not do that. You can specifically instruct the linker
not to link to it in VisualStudio project properties
"/NODEFAULTLIB:msvcrt80.lib". You also did not specify what are you
using for building. VS2005, VS2008, VS2010, gcc?
Answer based on educated guesses and Jeffrey Tan research here:
and research here:
(On behalf of OP)
The problem was with the pcre3.dll, as i've told before, and i simply change the version of it, I was using the version 7.x and change to 4.4 that calls pcre.dll instead of pcre3.dll, that solve my problem if any one have the same issue.
here is the link to the correct lib:
pcre-4.4-dll.zip
I'm stuck in my work because of compatibility issues with libraries compiled with dw2 exception handling, where the MinGW Cross Compiler I use on Ubuntu has sjlj instead.
Its been a real pain trying to figure this out on my own. I somehow need to build a custom MinGW Cross Compiler I can use on Ubuntu that has dw2, instead of sjlj. Otherwise I will keep getting errors like: undefined reference to _unwind_resume. If anyone could possibly point me in the right direction, I would be most grateful.
Try with MXE (MinGW Cross Environment)
http://mxe.cc/
MXE is built according to MinGW.org's (MinGW on Windows) instructions as far as I've tested (Meaning dw2). Mingw-w64 and the repos from most distros use sjlj too, so, that's a nope..
MXE's only "problem" is that it only builds static libs, but it includes quite a repertoire. It also may not be a problem.
Should that be unacceptable, http://mingw.org/wiki/LinuxCrossMinGW follow those steps. If the script fails due to a Function Name, go to line 130 in the .function file and comment those 3 lines about local
Trying to compile a C++ kernel project with MinGW & NASM (formerly DJGPP & NASM). Have actually tried Cygwin too, with the exact same results below:
First, just swapped out \DJGPP\bin for \MinGW\bin. Got the following link error: target coff-go32 not found.
Swapped target to elf32-i386, and got cannot perform PE operations on non PE output file 'build/kernel.elf' This was a bit of a weird error, since to my knowledge I'm not doing any 'PE operations'.
Changed target again, to pe-i386, got a new error build/Common.o:Common.cc:(.text+0x2a): undefined reference to 'atexit'
It seems MinGW is generating atexit calls for static classes. DJGPP did not. The kernel does it's own DTOR handling during shutdown. I am aware that defining atexit would 'solve' this, but that would be more of a hack at this point, and not a longterm solution. I want rather to get MinGW compiling the existing code without any (or minimal) modifications.
Frankly, I'm not that familiar with the Windows build environment and could use any tips on what to do. The project (minus the changes listed above) compiles and boots fine under DJGPP. The difference seems to be in the way DJGGP and MinGW handle compile-time class declarations?
EDIT: Finally broke down and built a cross-compiler on Cygwin. All working now.
You need to build a free-standing cross compiler. This problem has been referenced many times at the OSDev Wiki to the point that most people recommend you begin writing a kernel by first creating a cross compiler.
This article will provide a step-by-step reference to building your own cross compiler. Note, in Windows, you may have to build the cross compiler using MingW or Cygwin