Re: [Mingw-cross-env-list] QT 4.7.0 p1 qjpeg plug-in missing symbols problem

[Mark Brand]

> > > Seems like qjpeg plugin library can not find the symbols in libjpeg.a, though 
> > > libjpeg.a is definitely there and has the symbols in question.
> > The problem is that "-ljpeg" is missing from the g++ call. It's not your
> > fault. I guess we should blame qmake for not realizing that the qjpeg
> > plug-in depends on this.
> >
> > The same thing happens for qtiff too if you add "qtiff" to QTPLUGIN.
> Do you see a way to fix that in Qt, or at least to formulate it as a
> bug report to them?

It's a fairly complex issue, but I'll do my best to explain it succinctly:

The Qt "plugin" concept is intended for shared Qt.  It increases 
convenience by loading the shared library automatically only when it is 
actually needed. For static Qt, however, the plugin becomes nothing more 
than a static library that causes some extra inconvenience when 
building. This is explained here:
http://doc.qt.nokia.com/4.6/plugins-howto.html#static-plugins.

An extra complication arises when the static plugin (library) depends on 
another *static* library, as when qjpeg needs -ljpeg. This is because 
qmake cannot tell what the static dependencies are. The workaround of 
adding the libraries to QTPLUGIN seems like the best solution so far. 
It's understandable, flexible and imposes no maintenance burden. (We 
should probably add it to mingw-cross-env documentation.)

The two main candidates for a better solution are 1) avoiding the plugin 
or 2) giving qmake the ability to handle static dependencies of plugins.

For the SQL drivers, there is a choice between "built-in" or "plugin" 
forms of the driver. It makes sense to choose "built-in" for static Qt. 
I intend to introduce using the "built-in" forms with the next update of 
qt.mk.

For the image formats, the plugin is the only choice. It would be a 
significant effort to change this.

There is no obvious way (to me) to give qmake the ability to handle 
static dependencies of plugins. It might be possible to add the 
dependencies to the options in the makespec's qmake.conf or .prl files, 
but I am reluctant to make these files dependent on the static/shared 
choice.

I have discussed this issuse with Qt developers. They consider this to 
be out of scope for them for several reasons. To start with, static Qt 
is not something they want to encourage. Secondly, the plugin mechanism 
was designed for shared Qt. They feel that applications needing plugins 
should really use shared Qt. Thirdly, that someone would want to link a 
plugin to static system libraries is seen as a more surprising fact than 
the failure of qmake to provide the missing -ljpeg! It seems pretty 
clear that we are on our own in supporting this configuration.

In conclusion, I think mingw-cross-env users are faced with the choice 
of using the workaround for plugin dependencies or using shared Qt to 
avoid the problem.

regards,

Mark