I've been using Qt for several months now with no problems. I originally downloaded the Qt 4.8 library with the most recent Qt Creator as of summer 2012, and I was able to start constructing my application. My application has demanding graphics needs, so I've been using the great windowing context Qt provides for OpenGL.
I've been slowly building my skills. I have explored programable shaders with success, and I wanted to leverage the power of Geometry Shaders. I am running OS X 10.7.5 on a MacBookPro6,2 with a GeForce GT 330M GPU. According to what I've read from others here, the upgrade to OS X Lion included a driver to run this GPU under the OpenGL 3.2 Core Specification, including support for programable Geometry Shaders. I also read here that while Qt 4.8 did not support OpenGL 3.2 on OS X, this support was included in their recent release of Qt 5.
I saw that Digia had also released an update to Qt Creator, so (being a little too excited for this potential breakthrough in my work) I uninstalled Qt and downloaded the Qt 5.0.0 library + Qt Creator 2.6.1. I went through the steps in the wizard, started up the new Qt Creator and now nothing works, haha. I have developed a love-hate relationship with my compiler and the cryptic messages it gives me, but this is different. The errors that are being thrown make it sound like it doesn't know how to read the code any more (just to pick one example out of several hundred errors "#include "). The wizard installed Qt fine, and all the guts are there, but I think the link to my gcc compiler has somehow been broken. Not even the examples that came with Qt 5 compile.
Qt has introduced a new "kit" paradigm to make developing on multiple platforms easier, and I have made efforts to change the setup of the kit. Qt detects several gcc compiler options, which I have tried, and I have manually pointed it to the path I get from the terminal command:
which gcc
/usr/bin/gcc
It appears to be gcc 4.2. I see that the most current version is gcc 4.7, but I have the most up-to-date version XCode provides. I also downloaded "Command Line Tools" from XCode and restarted, but it did not remedy my problems as magically as I had hoped. I am trying to update gcc manually, but I'm running into issues because it is asking me to update gmp and mpfr as well, and they are not fully cooperating.
Since the kit paradigm allows multiple libraries to co-exist in Qt, I re-downloaded the Qt 4.8 library, but it suffers from the same problem. I have pointed Qt Creator to qmake for both the 4.8 and 5.0 libraries, but that doesn't seem to be the problem either.
I haven't been able to see evidence of anyone else running into such a crippling problem, so that suggests that I am missing something simple. But even for being a newbie last summer, I felt I had gotten pretty comfortable with Qt, C++, and OpenGL from what I have managed to piece together from the Internet.
If anyone can nudge me in the right direction, I would greatly appreciate it. I am willing to rebuild my application from scratch in Qt 5.0, but I can't use Qt at all at the moment.
I finally got it to work! In the directory /usr/bin/ there was more than one g++ executable. They were labeled with different version numbers (g++-4.0, g++-4.2), but they showed up in Qt's automatic detection. All I needed to do was delete the extras. Leave only the g++ executable that is not labeled with a version number. By limiting the options available to Qt, it automatically selected a compiler and now it works.
It is embarrassing that it took so long for me to find such a fast solution, but it is still a relief. I hope others save time from my experience.
Related
I was wondering which compiler is better to use on Windows OS (8.1) in temrs of compatibility to c++11's (and later 14) functions, liberies and features (like lambdas) and is also comfortable to use (less bugs).
I am a university student hence I'm not looking at the subject product-wise (even though I do like to code a bit more than just projects for my studies).
I am currently using eclipse luna IDE if it matters.
Notice that compiler != IDE.
VC++ is one of the most populars on Windows and depending on its version it has a good support for C++11 features. Check the list on the msdn blog to find out if there's everything you need.
Gcc is also ported to Windows and you can install MinGW to use it (4.8.1.4 at the moment of writing this). It is pretty complete on C++11.
Clang is also available for the Windows platform and it is also complete on C++11 support (plus it has good diagnostic messages), but notice that you will have to use another linker since clang doesn't ship with one (although there is an ongoing effort to write it: http://lld.llvm.org/)
All the compilers I cited above are pretty stable but, based on my experience, if you're looking for latest and greatest C++11/14/17 features, you might just want to go for gcc or clang (VC++ is slower in adding support for newest features and the compiler is undergoing a huge update to modernize). Just keep in mind that these are compilers and not just IDEs, an IDE is a front-end supporting program that uses a compiler undercover to compile files.
To set up a C++11 compiler, I suggest installing MSYS2, it has a package manager (pacman) that can install fresh versions of GCC, GDB, Clang and many libraries like SDL, Lua etc. Very easy to use too.
As far as GCC vs CLang goes - I really tried hard to make CLang work (which is presumably faster and more friendly than GCC - produces better warnings, etc.), but failed. Issues were that CLang (which comes with MSYS2) is hard-coded to use GCC linker which produces some strange linker errors when using libstdc++ (std implementation from GCC). libc++ (a new implementation designed to work with CLang) didn't worked for me on Windows either.
So you either try build CLang from sources and hope that some configuration will work with C++11 library, OR just stick with GCC which works just fine out of the box.
As IDE, I suggest to take a look at CLion. It is very comfortable (infinitely more user-friendly and intuitive than Visual Studio, IMO). Just install it and point it to the mingw64 (or mingw32) folder of MSYS2, it will auto-detect everything for you.
It only works with CMake projects though.
Similar to this question about GTK+ 3 for Windows, is there any place that offers compiled GTK# bindings for Windows? I searched for a while and can't find any official releases (which makes sense since there are no official GTK3 releases for Windows either), but also neither Banshee nor Xamarin come with GTK(#)-3.
I'm also unsure if these instructions for compiling GTK# 2 on Windows are still valid, but the page doesn't provide an awful lot of detail, so I guess it'll take half a day to figure out of it works that way.
Any other place where I might find the GTK# 3 binaries for Windows?
You can get the c# binding for GTK3 from:
https://github.com/mono/gtk-sharp/releases
This includes a windows installer.
These bindings are pre release and are versioned as Gtk# 2.99.3
My understanding is that the version will change to 3.0 when it is released as stable.
I'm trying to go back into programming after a few years break. I also want to try this C++11 stuff. So I installed GCC 4.6 from MacPorts. However, I still want to use Xcode. I remember that I once tinkered with custom compilers, like creating a custom command line tool in one target and using that tool to create custom documentation in another target. Can we get Xcode, both the compiling and debugging systems, to use the newer stuff from MacPorts? (I would adjust these per project so I can use the default tools on other projects, including Mac apps.) I would use the newer stuff to build command-line tools, like testing Boost.
Oh, by the way, I'm still on my obsolete system (August-2002 eMac with a G4 processor) stuck on Mac OS X 10.4 Tiger. So any answers have to be for Xcode 2.5! (I guess you could provide answers for Xcode 3.x and 4.x to help others, but realize that those will be useless for me.) As a key for the speed, MacPorts took over 2 days straight to build GCC 4.6!
Well, I certainly haven't tested any of this stuff on 10.4 or Xcode 2.5, but I did recently get GCC 4.6 working in Xcode 4.2. In 3.6 and 4.2 there are some compiler template XML files that you can modify once you install a new compiler. In 4.2 they are here:
/Developer/Library/Xcode/PrivatePlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/
In 3.6 the are in /Developer/Library/Xcode/Plug-ins
I have no idea if they exist in 2.5, but they might. If you want the details on how I did this with a more recent version you can find them here:
http://thecoderslife.blogspot.com/2015/07/building-with-gcc-46-and-xcode-4.html
It might help give you some ideas on where to start with the older version.
I want to learn Ocaml or Haskell and I want to do it by writing a simple game. Apparently, there's one small problem: nobody cares about Windows and I want to do it on Windows, natively.
Haskell has Cabal, which has SDL, but it doesn't build due to a trivial problem with no workarounds (order of parameters passed to gcc). Ocaml doesn't even have that, it's all in source packages, be it GLCaml or OcamlSDL or whatever.
Is there a place where I can get a working SDL for Haskell or Ocaml on Windows without fighting with a dozen versions of compilers?
The Haskell Platform comes with a binding to OpenGL which should work out of the box on Windows.
Concerning the SDL package on hackage, you can use cabal unpack SDL to get the source code and fix things yourself. To install the package with your changes, run cabal install in the unpacked directory. In any case, drop a line to the maintainer, I'm sure he'll help out.
It's not related to SDL, but you've mentioned OpenGL. There is LablGL binding for OpenGL in OCaml which works out of the box. Wiki example (http://en.wikipedia.org/wiki/Objective_Caml#Triangle_.28graphics.29) compiles and works just fine.
The best instructions I've found for getting SDL to work in windows with a the most recent Haskell platform can be found at this blog. I followed everything step-by-step and it worked perfectly, despite some configure error messages.
It isn't SDL but GLFW works on Windows with Haskell through Cabal.
My article High-fidelity graphics with OpenGL 2 (25th Feb 2008) explained how the GLCaml bindings can be used to write OpenGL-based applications in OCaml that use vertex and fragment shaders (a phong shader is given as an example). There are 9 articles in the OCaml Journal on OpenGL, albeit mostly using the older LablGL library for OpenGL 1.1.
I tried and failed to get OpenGL working from Haskell under Linux in 2007. The Haskell Platform may have changed that but I have neither had time to try it yet myself nor ever heard of anyone using it for this.
However, both OCaml and Haskell must rely upon fragile low-level bindings to OpenGL because they are standalone languages and nobody has ever managed to get any significant commercial software using them to work. As you're on Windows, F#+XNA is a far more logical choice because XNA is tried and tested and F# has a safe high-level interface to it. A Google fight gives you a good idea of what a pioneer you'll be: +haskell +opengl gives 437 hits on Google and +ocaml +opengl gives only 347 hits.
I need to support Windows 98. The Qt documentation claims this is possible, but there are no instructions. The distributed binaries of Qt 4.6 don't run on Win98 and the majority of Qt applications I have sampled also don't. For several apps that do run on 98, I have asked authors how they did it, but the common answer is that it was accidental and they don't know what factors caused it.
In searching the forums for help, I found only guesses that turned out to be wrong. For example, one belief is that to compile for Win9x, you must build the tools and the apps on that platform. Yet, things I found to run were built on newer versions of Windows.
What is required to build the Qt dev tools and then applications for Win98?
How about cross-compiling from WinXP or Linux?
Are there specific components that can't be made to run on Win98?
Are there particular difficulties with dynamic or static linking for Win98 support?
Here is as far as I'm going to get on this:
You can target Windows 98 using MinGW or VC++ 6 SP5 from any Windows version. Cross-compiling from Linux is doable but not easy to set up.
Qt 4.4.3 was the last version officially tested on Win98. To run the distributed binaries on Win98, you need to install older versions of glu32.dll and opengl32.dll that are available from Microsoft. Due to an unresolved bug, Assistant will launch but can't load the help files. The alternate version in the bin directory, assistant_adp.exe, works fine. It seems the only other potential problem is that QtOpenGL may use features not available on older boxes.
Qt 4.5.3 appears to be still compatible except for WebKit, OpenGL, and Phonon. QtOpenGL expects OpenGL 1.5, which I don't know is even possible on older boxes. I didn't look into Phonon deeply enough to see exactly what the problems are. QtWebKit now requires Win2K or better. The distributed binaries work mostly OK. Assistant depends on QtWebKit, so will not launch, but assistant_adp.exe still works.
Qt 4.6.3 distributed binaries are now completely incompatible with Win98. It may be possible to get some things working with MinGW 4.4 and a lot of hacking.
Building Qt Creator requires Qt 4.6.0 and either MinGW 4.4 or VS 2008.
Wow...interesting mission.
So, basically - yes, there is windows 98 support for Qt. The problem is that there is one big IF. For example if you even try to set some different QTextCodec::codecForName, you'll have to provide 3rd party ttf for this purpose, because in most cases Win98 will not recognize it as valid. If you provide the exact error, while compiling it on win98 machine, I could help you.
"How about cross-compiling from WinXP or Linux?" - If you use ONLY Qt libraries everything goes fine. Otherwise in .pro file, you have to link these libs under win32 and unix conditions. So you could even forbid your code, to be compiled and executed in other systems...
"Are there specific components that can't be made to run on Win98?" - Of course. In .pro file you could include different libraries, for different operating systems.
"Are there particular difficulties with dynamic or static linking for Win98 support?" - As far as I know - there isn't.
//off - But it still strange, that someone want to write application for win98, today...