Qt-interest Archive, October 2005
Dependency on mingwm10.dll
Message 1 in thread
I am trying to eliminate the dll dependencies of my small GUI
application to be able to ship a single executable file. I built
statically Qt so there is no dependency on the Qt dll's.
However, I still need the program still requires the mingwm10.dll to
execute.
Does somebody know how to eliminate this dependency?
Thanks,
Victor
Message 2 in thread
> Try to change the compiler.
As I far as I know (
http://www.trolltech.com/developer/platforms/supported.html ) the only
free compiler for Windows is MinGW.
Then in Windows, do I have to *inevitably* ship the application with the
mingwm10.dll? Can I not eliminate this dependency?
Thanks,
Victor
Matthieu Brucher wrote:
>Try to change the compiler.
>
>Matthieu
>
>
>
>
>>Message du 12/10/05 08:21
>>De : "Victor Broto" <vbroto@xxxxxxxxx>
>>A : qt-interest@xxxxxxxxxxxxx
>>Copie à :
>>Objet : Dependency on mingwm10.dll
>>
>>I am trying to eliminate the dll dependencies of my small GUI
>>application to be able to ship a single executable file. I built
>>statically Qt so there is no dependency on the Qt dll's.
>>
>>However, I still need the program still requires the mingwm10.dll to
>>execute.
>>
>>Does somebody know how to eliminate this dependency?
>>
>>Thanks,
>>
>>Victor
>>
>>--
>>To unsubscribe - send "unsubscribe" in the body to qt-interest-request@xxxxxxxxxxxxx
>>List archive and information: http://lists.trolltech.com/qt-interest/
>>
>>
>>
>>
>>
>
>
>
>
Message 3 in thread
> As I far as I know (
> http://www.trolltech.com/developer/platforms/supported.html ) the only
> free compiler for Windows is MinGW.
What about the free Microsh*t command line compiler? Or Borland bc55
command line compiler? The latter isn't listed on the trolltech
compatibility page but you might get it to work .
IMHO you'll save yourself a lot of hassle by buying the Microsh*t IDE
if you're planning on doing a lot of win32 development.
sga
Message 4 in thread
Even when using VC++ you have to ship the C runtimes, unless you use VC++6
which has the same C runtime as shipped with Windows already.
Volker
"steve ahlgren" <steveahlgren@xxxxxxxxx> wrote in message
news:cfa9c0b70510121433v35843c94q4b36ecf8d7949359@xxxxxxxxxxxxxxxxx
> As I far as I know (
> http://www.trolltech.com/developer/platforms/supported.html ) the only
> free compiler for Windows is MinGW.
What about the free Microsh*t command line compiler? Or Borland bc55
command line compiler? The latter isn't listed on the trolltech
compatibility page but you might get it to work .
IMHO you'll save yourself a lot of hassle by buying the Microsh*t IDE
if you're planning on doing a lot of win32 development.
sga
Message 5 in thread
You can compile everything with the static multi-thread runtime, but it
requires some work.
Matthieu
Volker Hilsheimer wrote:
> Even when using VC++ you have to ship the C runtimes, unless you use VC++6
> which has the same C runtime as shipped with Windows already.
>
> Volker
>
> "steve ahlgren" <steveahlgren@xxxxxxxxx> wrote in message
> news:cfa9c0b70510121433v35843c94q4b36ecf8d7949359@xxxxxxxxxxxxxxxxx
>
>>As I far as I know (
>>http://www.trolltech.com/developer/platforms/supported.html ) the only
>>free compiler for Windows is MinGW.
>
>
> What about the free Microsh*t command line compiler? Or Borland bc55
> command line compiler? The latter isn't listed on the trolltech
> compatibility page but you might get it to work .
>
> IMHO you'll save yourself a lot of hassle by buying the Microsh*t IDE
> if you're planning on doing a lot of win32 development.
>
> sga
Message 6 in thread
At 10/12/2005 04:33 PM, steve ahlgren wrote:
> > As I far as I know (
> > http://www.trolltech.com/developer/platforms/supported.html ) the only
> > free compiler for Windows is MinGW.
>
>What about the free Microsh*t command line compiler? Or Borland bc55
>command line compiler? The latter isn't listed on the trolltech
>compatibility page but you might get it to work .
>
>IMHO you'll save yourself a lot of hassle by buying the Microsh*t IDE
>if you're planning on doing a lot of win32 development.
I manage the project that Victor works on. We're building cross-platform
software (runs on Windows, many Linuxes, Free/Net/Open-BSD, several other
Unixes, MacOSX, etc). I'm less interested in a free compiler/IDE and more
about making sure all of code adheres to a platform-independent
nature. MinGW seems to be the best mechanism to do that.
We can use any IDE we want, so long as it uses a MinGW
core/compiler/linker, etc. In such a case, we still
To sum it up: we are *not* a Microsoft-only shop and therefore have little
interest in Microsoft-centric tools, or at least compilers (separate from
the IDE).
Victor, let's go post notes to the MinGW community about statically-linking
their libraries. I'm confident we can do this, as one of the main selling
points of MinGW over cygwin (as far as I understand it) is that cygwin
doesn't allow one to statically link their run-time library, while MinGW does.
Any comments about how we can statically-link mingw libs here will be
appreciated.
-Matt
Message 7 in thread
I use the VS2003 compiler with the Open Source edition with no problem.
Victor Broto wrote:
> > Try to change the compiler.
>
> As I far as I know (
> http://www.trolltech.com/developer/platforms/supported.html ) the only
> free compiler for Windows is MinGW.
> Then in Windows, do I have to *inevitably* ship the application with the
> mingwm10.dll? Can I not eliminate this dependency?
>
> Thanks,
>
> Victor
>
> Matthieu Brucher wrote:
>
>> Try to change the compiler.
>>
>> Matthieu
>>
>>
>>
>>
>>> Message du 12/10/05 08:21
>>> De : "Victor Broto" <vbroto@xxxxxxxxx>
>>> A : qt-interest@xxxxxxxxxxxxx
>>> Copie à : Objet : Dependency on mingwm10.dll
>>>
>>> I am trying to eliminate the dll dependencies of my small GUI
>>> application to be able to ship a single executable file. I built
>>> statically Qt so there is no dependency on the Qt dll's.
>>>
>>> However, I still need the program still requires the mingwm10.dll to
>>> execute.
>>>
>>> Does somebody know how to eliminate this dependency?
>>>
>>> Thanks,
>>>
>>> Victor
Message 8 in thread
Victor Broto said:
> Then in Windows, do I have to *inevitably* ship the application with the
> mingwm10.dll? Can I not eliminate this dependency?
Stupid question: why would you want to eliminate this dependency? This DLL
is explicitly allowed to be included in free and non-free programs and it
is small enough (16kB) to not mind it much.
You could of course try to link statically, do that it is included in the
executable instead of being a dependency.
Konrad
Message 9 in thread
At 10/13/2005 06:49 AM, Konrad Rosenbaum wrote:
>Victor Broto said:
> > Then in Windows, do I have to *inevitably* ship the application with the
> > mingwm10.dll? Can I not eliminate this dependency?
>
>Stupid question: why would you want to eliminate this dependency?
We don't. We want to statically link the library file such that there is
not external file dependency such that we can distribute one .exe file with
no concerns about other lib files, path placements, different flavors of
Windows operating systems, etc. Seems like a fair question to me.
> This DLL
>is explicitly allowed to be included in free and non-free programs and it
>is small enough (16kB) to not mind it much.
Yep, that's our understanding.
>You could of course try to link statically, do that it is included in the
>executable instead of being a dependency.
Exactly.
-Matt
Message 10 in thread
Matt England said:
> We want to statically link the library file such that there is
> not external file dependency such that we can distribute one .exe file
> with
> no concerns about other lib files, path placements, different flavors of
> Windows operating systems, etc. Seems like a fair question to me.
I just did a short check in my MinGW installation. It seems that this
particular piece of code (mingwm10.dll) is only available as DLL. I could
not find any static counterpart and the configure script for the MinGW
runtime does not contain an option for static.
So if you want to do static linking I guess you have to:
*compile the MinGW runtime manually (shouldn't be too hard - it's a matter
of calling gcc -c on all source files and ar rcs on the results)
*manipulate the linker specs to include the static lib instead of the DLL
(which I personally would find a frightening experience)
Anyway: all flavours of Windows that I have seen so far (3.1, 95, NT4,
W2k, XP pro) have the same "feature"(*) - they search for DLLs first in
the directory the EXE is installed in and then in the pathes listed in the
PATH variable. So if you place all necessary DLLs in the same directory as
the EXE then you should be fine regardless of any Windows version.
(*)others call that "security hole"
...of course this leaves you with the problem that your application
consists of more than one file. Most projects seem to solve this problem
by providing an installer as a single EXE (eg. self-extracting ZIPs or
using the Nullsoft installer).
Konrad
Message 11 in thread
Matt England wrote:
> At 10/13/2005 06:49 AM, Konrad Rosenbaum wrote:
>> You could of course try to link statically, do that it is included in the
>> executable instead of being a dependency.
>
> Exactly.
In some DOS projects from the past, I used "linkers" that can embed any
type of resource into an executable. For example, one could link
DOOM.EXE and its various *.wad files, and produce a version of DOOM (the
game) that runs as a single executable.
These were DOS tools, of course, but maybe something similar is
available for Windows? If yes, you could just "link" your executable
and the mingw dll together. It would still be dynamically linked, but
the user wouldn't notice, because the dll would get embedded as a
resource into the exe.
Message 12 in thread
"Nikos Chantziaras" <realnc@xxxxxxxx> wrote in message
news:dimao8$oi2$1@xxxxxxxxxxxxxxxxxxxxx
> Matt England wrote:
> > At 10/13/2005 06:49 AM, Konrad Rosenbaum wrote:
> >> You could of course try to link statically, do that it is included in
the
> >> executable instead of being a dependency.
> >
> > Exactly.
>
> In some DOS projects from the past, I used "linkers" that can embed any
> type of resource into an executable. For example, one could link
> DOOM.EXE and its various *.wad files, and produce a version of DOOM (the
> game) that runs as a single executable.
>
> These were DOS tools, of course, but maybe something similar is
> available for Windows? If yes, you could just "link" your executable
> and the mingw dll together. It would still be dynamically linked, but
> the user wouldn't notice, because the dll would get embedded as a
> resource into the exe.
This is not going to work - for your software to locate and load the DLL
from the resource it has to execute code, which requires your software to
start, which again requires that the OS can find the DLLs it depends on.
Note that static linkage against a C runtime is a bad idea for a number of
reason (i.e. multiple heaps).
Volker
Message 13 in thread
Volker Hilsheimer wrote:
> "Nikos Chantziaras" <realnc@xxxxxxxx> wrote in message
> news:dimao8$oi2$1@xxxxxxxxxxxxxxxxxxxxx
>> In some DOS projects from the past, I used "linkers" that can embed any
>> type of resource into an executable. [...]
>>
>> These were DOS tools, of course, but maybe something similar is
>> available for Windows? If yes, you could just "link" your executable
>> and the mingw dll together. [...]
>
> This is not going to work - for your software to locate and load the DLL
> from the resource it has to execute code, which requires your software to
> start, which again requires that the OS can find the DLLs it depends on.
>
> Note that static linkage against a C runtime is a bad idea for a number of
> reason (i.e. multiple heaps).
It isn't static linkage, as the tool was not a real linker. It bundled
everything together, and prepended a loader into the executable. It was
mainly useful for graphics demos, where you could distribute the demo as
a single exe (and encrypted, so the "lamers" could not rip it apart...
Ah, the old times :)
UPX does a similar thing, actually. Of course something like this was
quite trivial to do with DOS executables. It might not be possible at
all in Windows (although UPX succeeds with the loader part).
There were also non-loader based tools like this. They were modifying
the exe so that DOS API calls would refer to the embedded resources
rather than external files ("search and replace API calls", so to
speak). But this won't work for Windows DLLs, of course, for the reason
you mentioned above.
Message 14 in thread
Seems this is possible... remove the -mthreads option from your Makefile, as
mingwm is only needed for exceptions in threads, apparently. Found this out
from a wxwidgets site via google.
Nick
Message 15 in thread
# From: Nikos Chantziaras [mailto:realnc@xxxxxxxx]
# Sent: Friday, October 14, 2005 9:53 AM
# To: qt-interest@xxxxxxxxxxxxx
# Subject: Re: Dependency on mingwm10.dll
#
# It isn't static linkage, as the tool was not a real linker.
# It bundled everything together, and prepended a loader into
# the executable. It was mainly useful for graphics demos,
# where you could distribute the demo as a single exe (and
# encrypted, so the "lamers" could not rip it apart...
# Ah, the old times :)
Well, you can't do it the way that DOS does it - but I've
been led to understand that it *can* be done in Windows,
at least in the case of DLLs. My understanding is that you
can add them as a resource of some kind and thus embed the
DLL directly in the executable.
That said, I'm afraid that I don't know how it actually
works and have never done it. A friend of mine has before
and perhaps he'll be able to find the code where he did it...
I've asked him.
