The question appeared when I was trying to install SFML (Simple and Fast Multimedia Library for c++) on codeblocks Mgw32 on my Thinkpad2 tablet. I did everything according to instructions from SFML web page. Then I copied and successfully compiled test code (simple code that creates window and draws circle) from the same instructions.
However code always was crashing during the run time (I was getting usual windows crash report saying that something went wrong in msvcrt.dll). I figured out that it crashed when sf::RenderWindow instance was created. All SMFL functions before sf::RenderWindow was working properly.
I checked web and read that some people managed to solve same problem (compiles but crashes during runtime) by compiling SFML by codeblocks on their computers. And here comes something that I want to understand: what is the difference between library that was downloaded already in compiled form for particular OS and particular coding environment that is used by user and library that was compiled by user? Does compilation by user adjust code for software and hardware that user uses? If so then to what extent and will (or rather how will) this compiled code run on different hardware with the same OS?
I feel that question is very broad (it's because I have very limited knowledge in the area) so I don't expect precise answer all that I want is just some hit that can point direction where I should look for answer.
Related
I finally solved this amusing riddle so I'll answer my own question.
It drove me half nuts though, so I guess it might help a few fellow programmers.
Problem definition
What I want to do seems fairly simple: create my own widget and integrate it to my own Qt Creator (the version that runs on my local machine, as shipped with the standard Qt install) so that I can use it freely to design my own interfaces with the ad hoc GUI design tool.
Promoting a generic QWidget works adequately, it's just not very convenient.
I thought seeing the widget in the GUI design tool (instead of an invisible rectangle) and having the possibility to modify specific properties (instead of having to do it programmatically) would be nice.
Unfortunately, this did not go as smoothly as I hoped.
I can’t even be responsible for my own compiler!
Using:
a pristine Win 10 on a freshly reformatted system, with no previous compilers whatsoever installed
the default free version of MSVC 2019 (desktop C++ development pack, toolchain v14.26, compiler v16.4) downloaded by the standard installer
the default current Qt v5.14.0 (MinGW and MSVC2017 targets), downloaded by the standard Qt installer.
I started by naively compiling the example (the clock widget) for x64. Nothing happened. Then x86. Same result or lack thereof.
I actually realized this was conceptually wrong just before trying to compile it for MinGW.
Clearly the produced DLL had to match the native format of the actual Qt Creator, so this idea of the makefile magically adding a plugin to the current Qt Creator binary was all rubbish.
I gave up the wishful thought and set off to put the proper bit of DLL in its proper place by hand.
That's where I went astray for good.
I soon saw that the Qt Creator executable being shipped with Qt 5.14.0 has been compiled with MSVC2017 in win32 mode (that's stated in the "about" window, though no precise version of the compiler and/or toolchain is clearly stated, just this rather unreliable "MSVC2017" which is also used to designate an actual MSVC2019 environment).
The path defined in the example project was leading to some cryptic MSVC2017 subtree where nothing happened at all.
Putting DLLs there had no effect. Deleting the ones that were already present had no effect either.
Clearly my version of Qt Creator never used any of these DLLs. I have no idea what use they are supposed to be and frankly I could not care less. It was just another cold trail that wasted a bit more of my time.
Looking at the "about plugins.." window from Qt Creator, I noticed that all plugins listed there were located in <Qt install root>\Qt\Tools\QtCreator\lib\qtcreator\plugins\ (as stated in the windows that opens when clicking the "details" button).
I wrongly assumed this was were all plugins should go.
However, putting the result of the standard example (the cute little clock widget) into this directory did nothing at all.
I then lost a whole day trying to understand why in the blazes this bloody plugin would not show up.
Since the current MSVC integration is somewhat whacky (Qt still refers to MSVC2017 while using the binary compatible MSVC2019), I set out to try and use the v14.16 Microsoft toolchain (the last using MSVC2017 that can be installed with the Web installer).
I never managed to make this bloody older version of the toolchain work.
Frankly this Qt/VS integration is a quagmire. It boils down to calling this horrendous "vcvarsall.bat" command file that sets up a truckload of cryptic environment variables.
As it happens, vcvarsall.bat requires an extra command line argument (-vcvars_ver=14.16) that Qt is unable to pass (it considers the compiler definition invalid instead... What a rotten luck...).
You can still wrap the call into yet another batch file (#vcvarsall.bat %* -vcvars_ver=14.16) and feed that to the Qt compiler setup.
But even then I never could bring the bloody thing to compile.
I got missing includes and whatnot. Clearly the IDE must make some other assumptions about whatever file locations that make it impossible to work outside the "autodetected"' MSVC versions (namely the MSVC2019 current version in the present state of things).
I was mightily pissed off after all this painful waste of time, so I scoured the Qt forums again and got cluttered by countless (mostly Linux) discussions about paths and compiler options. More time wasted. A lot of time, actually.
In a last desperate attempt I used the nifty process explorer (that's right, spying on all resources opened by an executable) to locate the DLLs used by my running copy of Qt Creator. That is when I finally located the go[beep]mn directory.
From there on everything went quite smoothly indeed. Just compile your little DLL and put it in the right place, and Bob will be your uncle.
A bit of bullshit lore
There are two informations that might lead you to think the designer plugins live either in
Qt\Tools\QtCreator\lib\qtcreator\plugins (the path reported by the "About plugins..." window)
or
Qt/5.14.0/msvc2017/plugins/designer (the cryptic install path used by the example project)
Both are wrong and misleading.
Another bit of lore pretends the Qt Creator executable requires the exact same version of the compiler to produce compatible plugins.
This is another piece of bullshit. You can very well compile with MSVC2019 for the current version of the tool, that has apparently been compiled with MSVC2017 (though the about window does not say with which exact version of the toolchain or compiler, alas).
All you need is a binary compatible DLL (obviously), that means a Win32 compilation from a binary compatible Microsoft compiler (which could theoretically be as old as MSVC2015, as far as binary compatibility is concerned, but since apparently nothing but the latest version of the toolchain is likely to ever work, this is of purely academic interest).
It is not even necessary to compile in release mode, apparently debug DLLs work just as well.
Trying to make the previous version of MSVC work is not only a nightmare of undocumented and cryptic failures, it is also totally useless.
And the solution is...
Just build the project for MSVC 2019 (what Qt calls MSVC2017 for some reason) in WIn32/release mode and put the go[beep]mn resulting DLL into this directory:
<Qt install root>\Qt\Tools\QtCreator\bin\plugins\designer
Yup, that's right. You get a Qt\Tools\QtCreator\lib\qtcreator\plugins where strange things seem to happen but no "widget plugin" will ever be loaded, and another Qt\Tools\QtCreator\bin\plugins with a bunch of subdirectories, including the "designer" folder where your little "widget plugin" will finally come alive.
You get also a lot of bullshit and/or outdated tips from various Qt forum threads. Apparently Qt is crawling with a truckload of different "plugins" that don't all live in the same hovel and love to migrate with each new minor version...
I could find no hints or lists of useful directories in the Qt documentation either. And believe me, I did read quite a lot of Qt documentation.
And btw, to make use of your reusable widgets you will still need to provide either their source code or an interface header and some DLL/LIB for linking.
This "plugin" thing is a nice way to integrate your widget to the GUI editor, but it will not install a library containing your widget nor its interface header (that would be a nifty trick indeed :)).
Bloody awful nightmare. But now it's over and playing with my little custom widget cuties is a load of fun. Yay...
I am in a introductory c++ class and the teacher gave us a .exe from his visual studio code to show us what our program is supposed to look like. My question is can I run this on the command line. I have problems with wine and would rather not use it (i.e. wine xxx.exe). I have tried ./xxx.exe. All the questions I have seen deal with actual programs running a real game or something so I don't think this is a duplicate but if it is please point me to the correct place.
The binary format for linux and windows is different, so there must be a middleware that will know how to call a windows binary in linux, this currently is wine, if it's a console windows application it could also be dosbox.
You already said that you had problems with wine and prefered not to use it, sorry, you have to. executing a binary from windows in linux without wine is like trying to opening a wine bottle in linux, linux is not a bottle opener, not it's windows - binary format compatible.
Another thing you could ask for your teacher is the source code for his application, you could try to compile under ubuntu (if he used standard c++) and run there.
I need to be able to launch a basic GUI from an application written in C++ on Mountain Lion. The obvious ways this would normally be accomplished is through either a cross-platform library like gtk or qt or by launching the c++ code from an objective-c based application. Each has its problem in this case. The application I'm writing uses a class library to connect to a robot. For the application to use the functionality, it must be compiled using the g++ compiler from terminal. The code was never designed to run on anything past Snow Leopard, so it's quite touchy when it comes to compiling and linking. This would seem to preclude my ability to start the C++ code from objective-c written using the xcode ide unless xcode includes compile options that I'm not aware of, at which point other platforms like gtk or qt seem viable. The problem with those is that I haven't been able to get a single one to even compile on Mountain Lion, let along been able to write an application using one. Is this a problem with Mountain Lion/lack of updates? And are there other options for creating the GUI? Maybe a GUI library compatible with Mountain Lion or a way to launch a cocoa-based GUI from the C++ code? It doesn't need to be complex - just a window with some lines drawn in it.
Thanks in advance!
I'm going to enter a small game competition in the coming months. They require the submission to be able to be compiled ( and it will be, before being run/evaluated for the contest) on Linux. I'm going to be using SDL and C++. I've only ever developed on Windows before and I've grown quite accustomed to the benefits Visual Studio gives. I'd like to be able to develop in windows with VS, and then near the end of the process migrate it over to linux. Beside making sure SDL is already installed on the Linux machine, are there things I can do throughout development that will make the process easier? Also, the contest rule for all of this states:
it must also work on an open platform (we strongly recommend making sure that your program run on modern flavors of GNU/Linux, as all of the judges will have access to it).
I assume compiling/running in Ubuntu (already have a home server with this) would be sufficient for this?
Your question is slightly open-ended, but my first suggestion would be to use a proper cross-platform build system such as CMake from day one. I would refrain from "migrating" to Linux at the very end; you may be under a rough schedule (and maybe run into problems you did not anticipate). Thus, a continuous build of (working) Linux versions will help ease your worries.
Furthermore, if the game is meant to run solely under Linux, why not install Ubuntu in a Virtual Machine somewhere and get acquainted with one of the development environments such as kdevelop or qtcreator? Wouldn't direct contact with the platform you are developing for make things a little easier?
I'm developing games and started like you. I'd advise you to use SFML library for this purposes. It's not very big and is very good thing to start from.
There you can use:
2D renderer (OpenGL)
Fonts
Timers
Wrappers around images/sprites
Post effects/shaders
Sound
Network
In this page you can find a few start examples.
I've downloaded HD Photo Device Porting Kit 1.0 and successfully compiled and executed it on x86 PC.
I want to port the image viewer program to ARM-based Windows Mobile Smartphone, but there is some missing ARM code.
First, no "/image/x86/x86.h" equivalent header file for ARM. But the file is very simple, so I copied and renamed it to "arm.h" and successfully compiled and linked the source code.
But at runtime, DWORD alignment exception occurrs. I found that on ARM build, it seems that ARMOPT_BITIO should be declared for properly aligned read & write. But with ARMOPT_BITIO, some IO functions are missing, e. g. peekBits, getBits, flushToByte, flushBits.
I copied x86 version of these functions (peekBit16, flushBit16, etc), but no luck, it does not work (I've got a stack overflow error).
I can't debug the complex HD Photo source files. Please let me know where can I find the missing ARM code.
Any help would be much appreciated. Thanks!
Based on my experience of porting some Microsoft code to ARM Linux, I do not think there is an easy way around it, unless someone has ported it already. You'll have to dive into this sort of low-level debugging.
Bugs I encountered were mainly related to unaligned access, and missing platform API calls. Also incorrect preprocessor checks resulted in code thinking it's running on big-endian platform.
The method I found useful to debug in such scenario is to build the code for the target platform and for the platform where it's known to work, and debug/trace these builds in parallel using a number of use cases. This will catch the most severe bugs.