|
|
Kuba Ober schrieb:
On piÄtek 25 marzec 2005 04:14 am, JÃrÃme Conus wrote:
Hi !
I just read a few documents regarding deploying qt applications on
Windows and MacOS platforms.
I guess to avoid any conflicts, the libraries are usually located in
the application's directory on windows and in the application bundle on
the Mac. Thus, each application has its own copy of the qt library.
So, here is what I don't understand : if each app comes with its own
copy of the lib, what's the point of dynamic linking ? Wouldn't static
linking be as good or better ?
*RE-LINKING* You don't have to re-link when you upgrade your Qt library, as
long as the version is >= 3.2 and <= 3.9.
As long as the qt library on windows contains the full version number
(qt-mt334.dll), you always have to relink on windows. I think, the
library name should be qt-mt3.dll instead of qt-mt334.dll and the full
version number should only be visible if you query the version info
resources as ususal for windows dlls.
In fact, this is a valid reason on any architecture. E.g. I've upgraded all
the way from 3.2.x to 3.3.4 on my RedHat/Fedora system without having to
recompile my applications. Saves some time, given the measly performance of
binutils' linker.
* PLUG-INS* If your application is using any Qt plug-ins, it must be
dynamically linked. Otherwise the plugins won't see the symbols of the Qt
library, as there will be none exported in a static link.
Now, it *is* possible for PE32 .exe files to export symbols. With some
twiddling of the makefiles of both Qt *and* of your application, your .exe
could export all the symbols that the plugins need, even if Qt is statically
bound.
Heck, it may even be possible for the ELF executables to export the symbols as
well. At the very least, at runtime it's possible to merge all that symbol
data back into various ELF tables that live in application's address space
and that dynamic linker uses.
But Trolls decided not to support that. I presume it's too much work with too
little gain for them. It's not exactly a weekend job unless you're on
COFF/ELF tools every other day :)
I think they don't support it, because qt runs on a large number of
platforms and exporting symbols from a statically linked executable may
not be possible for all supported platform/compiler combinations. If you
use g++ on IRIX for example, you can't use the -exported_symbol flag of
the linker, because g++ silently adds the -hidden_symbol flag when
linking and the linker allows only one of the flags to be specified.
Cheers, Kuba
--
List archive and information: http://lists.trolltech.com/qt-interest/
--
List archive and information: http://lists.trolltech.com/qt-interest/
|
|