[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] Static vs. shared Qt
From: |
Volker Grabsch |
Subject: |
Re: [Mingw-cross-env-list] Static vs. shared Qt |
Date: |
Tue, 13 Dec 2011 10:56:21 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Mark Brand schrieb:
> >
> >This is because all DLLs will contain all (statically
> >linked) helper libraries. I don't know how much of a
> >problem this is for Qt. But I guess the only "clean"
> >solution is to build everything as a shared library,
> >not just Qt.
>
> Right. It's not a good general solution, but it does work around the
> QtScript/QtWebKit problem.
>
> Having said that, for some "pure" Qt applications, it might actually
> be seen as an advantage to have all dependencies embedded in the Qt
> DLLs.
I see the sentiment here, but if your application has to
ship with a bunch of DLLs anyway (QtCore, QtGui, etc.),
why not adding some more to save some space. :-)
On the other hand, it *might* be a good idea to keep
the number of DLLs to a minimum. For instance, creating
one big Qt-DLL, one extra DLL for QtScript, and one
EXE file for the application.
> >Which leads us back to a recurring issue of static vs
> >shared: Once I implemented our multi-target approach,
> >does it make sense to apply this to static/shared, i.e.
> >treating the "mainly-static" and "mainly-shared"
> >approaches as two separate targets?
>
> I hadn't realized you were considering a static/shared choice in the
> multi-target approach.
I didn't consider it before. It was just an idea
flashing though my head. :-)
> I think the patch in question (two messages
> ago) should still in work for "mostly shared" mingw-cross-env. The
> OPENSSL_LIBS, PSQL_LIBS, and SYBASE_LIBS lists could be reduced or
> maybe even eliminated for shared builds. Also, there's at least one
> patch to link static sub-dependencies explicitly. But this stuff
> should be harmless as-is.
The first question is how to encode this in the TARGET - as
a second vendor, or as a suffix to "mingw32", or whatever?
The second question is whether that additional TARGET is
worth the additional maintainance overhead. For instance,
what about win32/win64/osx all in combination with
static/shared? That might become huge, especially if we
need separate build rules for each of these 6 variants.
Also, I wonder whether it really makes sense to build
shared libraries via mingw-cross-env, given the already
existing projects which seem to do the trick as well:
http://mingw-cross-env.nongnu.org/#see-also
http://download.opensuse.org/repositories/windows:/mingw:/win32/SLE_11/noarch/
https://admin.fedoraproject.org/pkgdb/acls/list/**mingw**
That's why I'd like to head some opinions on that.
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
- Re: [Mingw-cross-env-list] Qt libjscore.a not installed, G Coco, 2011/12/01
- Re: [Mingw-cross-env-list] Qt libjscore.a not installed, Mark Brand, 2011/12/05
- Re: [Mingw-cross-env-list] Qt libjscore.a not installed, G Coco, 2011/12/05
- Re: [Mingw-cross-env-list] Qt libjscore.a not installed, Mark Brand, 2011/12/06
- Re: [Mingw-cross-env-list] Qt libjscore.a not installed, Mark Brand, 2011/12/08
- Re: [Mingw-cross-env-list] Qt libjscore.a not installed, Mark Brand, 2011/12/08
- Re: [Mingw-cross-env-list] Qt libjscore.a not installed, Mark Brand, 2011/12/12
- [Mingw-cross-env-list] Static vs. shared Qt (was: Qt libjscore.a not installed), Volker Grabsch, 2011/12/12
- Re: [Mingw-cross-env-list] Static vs. shared Qt, Mark Brand, 2011/12/12
- Re: [Mingw-cross-env-list] Static vs. shared Qt,
Volker Grabsch <=
- Re: [Mingw-cross-env-list] Static vs. shared Qt, Mark Brand, 2011/12/13
- Re: [Mingw-cross-env-list] Static vs. shared Qt, Bart van Andel, 2011/12/13