On Thu, Jun 14, 2012 at 9:44 AM, Till Oliver Knoll <
till.oliver.kn...@gmail.com> wrote:
> 2012/6/14 Josiah Bryan <josiahbr...@gmail.com>:
> >>> ...
> >>> What compiler do you use? The MS Visual Studio compiler? ...
> >> In particular make sure you use the same runtime as the Qt libraries.
> >> ...
> > I'm just using Qt Creator and (I assume) Mingw - I installed the Qt SDK
> with
> > it's default settings, so however it configured Qt Creator - that's what
> I
> > use.
>
> [...]
>
> By the way: when questions like these come up ("with what runtime does
> your executable/library link?") you should become best friend with
> "Dependency Walker". It is either part of the Visual Studio package
> (not sure about the "Express" edition) or the Windows SDK (or both,
> can't remember) - all available from the MS download website of your
> trust - or from:
>
> http://dependencywalker.com/
>
> [...]
>
> Yes, that's right (still: use depends.exe on your own binary and make
> sure you have a consistent linking, debug vs release. As Anreas
> already pointed out at least the Qt libraries have a -d.dll naming
> pattern for their debug libraries.
>
> By the way, the actual problem is not when you build your application
> in, say, debug mode, but link against a *release* version of Qt - as
> long as one one single C/C++ runtime library is pulled in! And *that*
> is giving you serious problems, as soon as you have a debug C/C++
> runtime library pulled in by your binary, but another C/C++ runtime
> library in release mode! Memory allocated in the one library can't be
> free'd in the other, since you end up with separate heap spaces etc. -
> and that is almost impossible to debug. The system might simply freak
> out and terminate your process.
>
> Mixing debug and release Qt libraries - QtCored (debug) and QtGui
> (release), for instance - is also not a good idea, because the QtGui
> would still link against a release QtCore instance, and since those
> libraries usually keep global instances which should better be unique
> - bang!
[...]
Thanks to your suggestion and my new best friend, depends.exe, I see all
the Qt libs are linking correctly to the "-d" version - **except* for
phonon! *Depends.exe shows while the rest of the libs are debug versions,
the phonon lib is "phonon4.dll" - whats up with that? Why would qmake/Qt
Creator be linking the debug versions of the Qt libs, but the release
version of phonon?
> If that doesn't help: Do the usual "Remove everything and rebuild"
> trick! Sometimes some old *.obj object files linger around and get
> linked into your binary. So also make sure that all moc_* etc.
> generated files are deleted (somewhere under "Build" -> "Clean All" or
> "Dist Clean" or something).
>
Already did that yesterday before emailing this list - no luck there. I've
even installed Qt creator on a fresh PC (never before had Qt on it) and
checked out a fresh copy of my project source - same problem when trying to
run in debug mode.
>
> Next: Strip down your project to the very minimum: comment out
> everything in your main function but e.g.
>
> QApplication app(argc, argv);
> ...
> // everything else commented out
> ..
> qDebug("Set a breakpoint here!");
> return app.exec();
>
> Set a breakpoint at the qDebug line, recompile and debug. If that
> works (and I sure hope so), start re-enabling your code and see where
> it starts getting messy.
>
Doing that right now - my work in this direction has also pointed me toward
phonon as the problem, tho I'm still trying to narrow down the exact line
of code. So, I guess it goes back to why is phonon4.dll being used and not
the debug version?
Cheers!
-Josiah
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
