[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] QT 4.7.0 p1 qjpeg plug-in missing symbols pro
Re: [Mingw-cross-env-list] QT 4.7.0 p1 qjpeg plug-in missing symbols problem
Tue, 22 Jun 2010 18:28:35 +0200
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20100608 SUSE/3.1.0 Thunderbird/3.1
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:
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
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
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.