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
Related
I have found that using MSVC to write C++ code and push to Linux to debug works fairly well for a simple environment where you just take the default gcc, cmake, etc.
But, does anyone know how to control the version of gcc, cmake, etc? Depending on the situation I may need to target several different compilers. Has anyone had any luck controling the core toolchain from MSVC?
It would be great if there is a way to just set up different build configurations.
I have an application written in pure C++ and Qt 5.5.1. It compiles fine in both GCC (Lubuntu 15.10 x86) and MSVC 14.0 (Windows 8.1 x64), and works properly on both those platforms. I now want to distribute it so that it will run on other Linux distros without recompiling them there.
I'm not entirely sure how to achieve this; the Qt docs page generally suggests to link everything statically, but this is not what most other sources say (from what I understand it is a bad idea to link with glibc statically). In any case I cannot really link everything statically because GCC complains that Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking and from what I understand this isn't a warning one can simply ignore. I've tired linking statically against only libgcc and libstdc++, I copied the other missing libraries - libXau.so.6, libXdmcp.so.6 and libxcb.so.1 on a clean CentOS 7 installation and tried to run the program there, but that gave me a segmentation fault; possibly because the system is 64 bit as opposed to the platform I compiled the application on?
How can I distribute the application in a form runnable by most common configurations? Static linking is not an issue because the source is going to be released anyway.
Is it better to link against Qt statically or dynamically (if maximum binary portability is the priority)?
Do I need to provide two separate versions of the binary, 32 and 64 bit, or will a 32 bit build suffice?
My suggestion would be to offer two builds: an unsupported, fully static build that will work "anywhere" with an asterisk that there's no way you can support it if it's a commercial offering. People'll try to run it on their fridges, I kid you not. The officially supported builds must be for specific platforms only, and you can't but have VMs/test targets that run these platforms, and where you build and test on.
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.
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
Is there any compiler for C++ that works under W7 and is easy to install, except VC++?
I never get these scripts and linux emulations to work, and really just want to try another compiler.
The nuwen distribultion of the GCC compiler includes the compiler and all necessary supporting tools and libraries as a single Windows installer. You don't need any Linux emulation in order to use it. A similar, slightly smaller pacakage is TDM's MinGW build. Both of these are on GCC 4.5 (as of Aug-2010).
If you want an IDE, then Code::Blocks also comes as a complete system. This has recently (Jul-2010) been heavily improved, and comes with the GCC 4.4.1 compiler, if you want it. You might also want to look at CodeLite, which is also fairly easy to install.
Mingw is generally easier than cygwin. It doesn't come with a port of every unix tools as cygwin does, but the resulting .exes are native (no need for cygwin.dll)
Cygwin includes the gcc compiler and also provides a Unix look and feel which will be the other thing you need to get scripts and linux emulations to work. (This inlcude the libraries Unix libraries will have functions that VC does not have which might be the issue that you are having)
Qt for Windows comes with MingW, which I've found to be reasonably easy to use and install, and the LGPL version is priced right (free as in beer). You don't need to use any the Qt libraries in your application. I'm not sure which version of GCC is currenlty bundled with it. There are no licensing restrictions for the software you develop (unless you're actually modifying and redistributing source code of the LGPL version of Qt).