I use Yocto (Krogoth) to build my imx6 images and toolchains, however it's a bit heavy and slow for working on kernel drivers. As such my dev cycle is to build the kernel on its own, just using the output of a "do_patch" run in yocto as the source tree base and sourcing the toolchain environment.
This is normally not a problem, as mostly I'm focussed at that end of the s/w stack. However, I now need to be able to run a Qt application (running under eglfs) on top of my continually updated kernel, for a bug hunt. To do this, I need the imx6 graphics driver working, so I get the galcore source from git://github.com/Freescale/kernel-module-imx-gpu-viv.git export my kernel build directory, make it and deploy it. That module loads perfectly. However running the working application that has already been built with Yocto causes a crash, somewhere in libQt5EglDeviceIntegration.so.5. All the libs etc. are part of the original working image, the same place I took my kernel source from.
What do I need to do to make this work? Is there some part of Qt tied to the graphics driver that's going to force me to rebuild the entire library? What's the relationship between galcore.ko and Qt? Is there now a weird dependency between my application and the linux kernel?!
EDIT: PEBCAK. I'm an idiot. I didn't check out from the right SHA1 (that listed in the recipe) for the galcore driver. Still, the answer below is instructive, so I'd like to keep this question.
What do I need to do to make this work?
No idea. Maybe your self-built galcore.ko is incompatible with the binary blob OpenGL libraries from Freescale somehow? Does the original galcore.ko work correctly? How does the backtrace look?
Is there some part of Qt tied to the graphics driver that's going to force me to rebuild the entire library?
No need to rebuild Qt. While Qt is linked against the OpenGL library, the OpenGL ABI/API is stable and therefore a Qt rebuild isn't needed. Besides that, you aren't changing the OpenGL libraries.
What's the relationship between galcore.ko and Qt?
Qt uses OpenGL for rendering when using QtQuick. The OpenGL library (libGL.so and a few variants like libGLes2.so) is provided by Freescale as a binary blob. The OpenGL library makes syscalls that end up in the galcore.ko kernel module.
libQt5EglDeviceIntegration.so.5 is the part in Qt that does the first OpenGL calls to initialize OpenGL.
Is there now a weird dependency between my application and the linux kernel?!
Well, yes, indirectly via Qt -> libGL.so -> kernel [galcore.ko]
I'm writing an application that uses Qt, and I'd like to make it available to Windows users. I'm using mingw. I want to configure Qt with -exceptions as well as -static. Is this possible? I've found a post on a blog that states that static builds with mingw and exceptions will cause memory leaks:
http://blog.lugru.com/2010/04/static-qt-compilation-and-mingwm10-dll-mingw-confusion/
Some of my code throws exceptions, which should be handled in the GUI part of my code by displaying an error dialog (meaning: I don't want to remove all exceptions from my code).
I tried to build Qt with both -static and -exceptions and it didn't seem to work (I still got error messages about exceptions when I tried to compile my code). I won't rule out the possibility that I somehow messed that up, but if these options are mutually exclusive, it would be nice to know before I spend all day compiling Qt again. Thanks!
I am currently using QtCreator 2.4.1 with Qt 4.7.4 development libraries (in Ubuntu) and am trying to track down a bug which after profiling with valgrind seems to occur internally within QGraphicsView::paintEvent(…) method
To help isolate this problem I would like to step into the Qt sources. Having done some searching through both the Qt forums and stack overflow and have not being able to find a way to integrate the sources with my version of QtCreator.
I have currently tried downloading the sources via the QtSDK manager and adding a “Source Path Mapping” within Tools->Options->Debugger. I am sure that this step is where I am making a mistake as I am unable to even switch to source when viewing internal Qt header files i.e. from QGraphicsView.h
I have so far tried adding the following Source Path Mappings
Source Path=/var/tmp/qt-src
TargetPath=/home/paul/QtSDK/QtSources/4.7.4
and
Source Path=/var/tmp/qt-src
TargetPath=/home/paul/QtSDK/QtSources/4.7.4/src
Neither works.
I have also tried building Qt directly from source, adding this to my "Qt versions" list within Qt Creator and creating a new project configuration using this version. This also did not work.
Likewise I have tried adding the src folders to my gdbinit file. This also fails to work.
I am completely lost with this.
Paul
Someone asked a similar question here: Need to step into Qt sources (my IDE is Qt Creator).
Someone else asked about Valgrind errors with Qt here: Suppression files for Qt memory leaks with Valgrind
And here is a little more info about Using Valgrind with Qt Creator along with some explanation about how to read the results. Its a little dated from late 2010.
Related Suggestions
I wouldn't debug the QGraphicsView class just because of all the effort to make it work or find the problem might be for nothing... Qt is moving to using the SceneGraph as the backend for QML and the rendering engine for QGraphicsView might become obsolete.
Updating to the latest stable build of the Qt libraries may make a big difference for QGraphicsView.
If you post the valgrind error you are getting to the Qt Trolls, someone might be able to explain what is going on for you.
There are other debugging techniques besides the traditional debugger. I've been programming in Qt in Windows (without valgrind) and with a large multi-threaded application, that loads a bunch of Dll's. I've had to put some faith into the Object Tree Model clean up and work on all the new calls I put in. Most of the time I just use QDebug to find errors. Then I am also using a combination of qInstallMessageHandler() with QDebug to implement decent logging for the hard to track bugs.
See also Qt Debugging Techniques.
I'm new to QT and I've been trying to compile a static build of QT of DAYS (literally) I'm pretty much out of Ideas and the QT documentation is probably the least helpful I have ever read. It doesn't work out of the box thats the problem. It needs to be tweaked a considerable amount before you can compile it as static. Finally the other night I managed to compile it statically and then followed the instructions to deploy it. I then copied the executable to another machine where it promptly complained for the lack of dll msvcp100. WTF! I thought that the static build was dependency free! Can you guys give me a definitive answer that can solve my problems?
That's the Visual C++ runtime library, not QT. You need to install http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.