[Top][All Lists]

[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

From: Mark Brand
Subject: Re: [Mingw-cross-env-list] QT 4.7.0 p1 qjpeg plug-in missing symbols problem
Date: Tue, 22 Jun 2010 18:28:35 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: 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 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]