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.
Related
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.
I'm having "Undefined Reference" to the whole schmere, and everything is properly setup (As it seems).
All the libs are linked (I mean, ALL of them, so it's impossible that I've missed something):
The headers are properly included:
And here's my toolchain executables for the compiler (After the change / update).
I'm so paranoid by now that my paths do not even have spaces anymore, and it just does not work (It was working with MinGW x86, but it is full of bugs, string conversion does not work, and whatever. It was installed on C:\MinGW, but now it's installed in a completely different path (The new one)). I've changed the path environment variable accordingly.
So, any ideas? Something in the toolchain executables is wrong? (I've never set it up manually before).
Solved the problem, by returning to the buggy MinGW x86 (Reinstalling the whole Code::Blocks with MinGW by default, and erasing the Code::Blocks .conf file in AppData).
So, I'll have to use the buggy version of GCC because it's the one that "sees" Allegro 5 (For some reason, there's some incompatibility. It just does not find the Allegro functions).
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
More out of interest than anything else, but can you compile a DirectX app under linux?
Obviously there's no official SDK, but I was thinking it might be possible with wine.
Presumably wine has an implementation of the DirectX interface in order to run games? Is it possible to link against that? (edit: This is called winelib)
Failing that, maybe a mingw cross compiler with the app running under wine.
Half answered my own question here, but wondered if anyone had heard of anything like this being done?
I've had some luck with this. I've managed to compile this simple Direct3D example.
I used winelib for this (wine-dev package on Ubuntu). Thanks to alastair for pointing me to winelib.
I modified the source slightly to convert the wchars to chars (1 on line 52, 2 on line 55, by removing the L before the string literals). There may be a way around this, but this got it up and running.
I then compiled the source with the following:
wineg++ -ld3d9 -ld3dx9 triangle.cpp
This generates an a.out.exe.so binary, as well as an a.out script to run it under wine.
If this is not about porting but creating, you should really consider OpenGL as this API is as powerful as DirectX and much easier to port to Mac or Linux.
I don't know your requirements so better mention it.
You can't link against wine as it's essentially a call interdictor/translator rather than a set of libraries you can hook into. If linux is important go OpenGL/SDL/OpenAL.
I believe(I've never tried this) you can can compile Linux binarys against winelib. So it works just like a Linux executable, but with the windows libraries.
http://www.winehq.org/site/docs/winelib-guide/index
go to the directory with the source and type in:
winemaker --lower-uppercase -icomdlg32 -ishell32 -ishlwapi -iuser32 -igdi32 -iadvapi32 -ld3d9 .
make
wine yourexecutable.exe.so
If you get this Error:
main.c:95:5: error: ‘struct IDirect3D9’ has no member named ‘CreateDevice’
make sure you have named your file main.cpp and not main.c.
There is currently no way to compile DirectX code to directly target Linux. You would build your application like you normally would, then run it using a compatibility layer like Wine/Cedega.
you can compile a directx apps in linux, but not launching it straight away.
if you use a crosscompilator that makes windows exe and point to the windows sdk and directx sdk.
Although this question is dated, I decided to updated on it, because it keeps popping up for me as the first suggestion for this particular problem.
As the previous answers already suggested you can compile against winelib. However, there are yet another two solutions.
The first solution would be either to use the MinGW provided for your distributions. MinGW is a 'cross-compiler', that compiles either from macOS or linux to windows and has support for DirectX. Note, that C++ libraries compiled with MinGW are not compatible with the MSVC compiler's ABI, thus cannot be consumed. However, the resulting binaries can be executed using Wine.
The second solution would be to use clang as a cross compiler. Clang usually includes the Compiler and Linker needed for Windows out of the box. However, it'll require you to include provide the headers and libraries yourself. On the other hand, libraries compiled this way are compatible with MSVC and, thus, can be consumed by it.
Side note:
Latter allows you to setup an CI server using linux (I did so on a raspberry pi), which creates compatible binaries for end users.
Wine is the only way to run DirectX in Linux