qt plugins and release builds

[Christian Ehrlicher]

> Von: Shane King
> Christian Ehrlicher wrote:
> > Shane King schrieb:
> >> Christian Ehrlicher wrote:
> >>>>     if (WIN32)
> >>>> 	  # qt is always compiled with QT_NO_DEBUG under mingw,
> >>>> 	  # so we need to compile stuff linked against it
> >>>> 	  # the same or otherwise QPluginLoader rejects plugins
> >>>>        add_definitions(-DQT_NO_DEBUG)
> >>>>     endif (WIN32)
> >>>>
> >>>> Hopefully this should solve our issues.
> >>>>
> >>> Please find another way to fix this!
> >> Why? I explain why I think it's the correct fix (QT isn't compiled as 
> >> seperate debug and release builds under mingw, just like on unix). It 
> >> fixes it only for that compiler, in all circumstances. MSVC (or any 
> >> other compiler) isn't affected.
> >>
> > You're wrong here. Qt is compiled with debug_and_release on mingw and it
> > can be compiled as separate debug in windows and linux too. So your fix
> > is wrong.
> 
> OK, I'm wrong on details ...
> 
> You are right that both versions of Qt are generated. However (and this 
> is why I was thinking debug versions of qt weren't being compiled), even 
> in debug builds it ends up linking against the release libraries (eg 
> qtcore4.dll rather than qtcored4.dll). I verified this with depends.exe 
> >from the PSDK.
> 
No need to verify this, I now remember this behaviour... :(
It's a mess. Plz add a note to your change in FindKDE4Internal.cmake that we link against Qt release libs *every* time when using mingw/gcc. Therefore it's correct.
I'll create new Qt packages for mingw which don't have the debug/release check... another thing where we're inconsistent on a single platform :-/


Christian

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger