Ulrich Eckhardt <doomster knuut.de> writes:
I set my compiler to generate code as a
"multi-threaded DLL." However, it turns out this means VC++ won’t compile
the EXE as a standalone (well, standalone as in the EXE and SDL.dll) but
instead wants to install its own DLLS on the target machine.
Of course, this is actually normal an expected. For things like the C API
(printf, fopen, exit…) you need library code, dito for the C++ API
(namespace std) and any other addon library like SDL, too. So, either you
include all of it in the executable (static linking) or you ship parts of it
as a DLL or require the user to install the DLL. Note: installing libraries
on their own and not only as part of a program is actually pretty normal on
non MS Windows platforms. Further, nothing of this has anything to do with
SDL.
Whether it’s normal or not on other platforms, having to bother with an
installer or extra downloads or programs on Windows is more trouble than I’d
like to put my beta testers - much less my users - through. I’ve always been a
fan of self-contained, no-installer-needed programs, and would likemy own code
to be so simple.
I consider this option unacceptable, as I don’t want to require an
installer for such a simple program.
I don’t want to download libraries that I already have. I also don’t want
copies of the libraries clogging up my RAM even though they could be shared
as DLLs. How about providing a URL where users can download additional
required libs instead of bundling them with your program?
Testing shows the difference in size between a statically linked executable
using the libraries I need and a dynamically linked one is about 45k. I think
the ease of use of not having to download or install the extra file is worth the
extra overhead.
Including the msvcr90.dll files with the program, per
Microsoft’s instruction, isn’t proving a viable solution (it crashes as
well).
If the vendor say “do this” and it doesn’t work, I’d take it to the vendor’s.
All your problems are rather off-topic here.
Ah, but that’s the problem, and why I’m here: the solution from their end is
simple. Compile it as a statically linked program. But all install
instructions for SDL say it must be compiled as dynamically linked when using
Visual Studio, and I’m curious if anyone knows a way around that issue.
In short, my question is: is there a way to use SDL without requiring that
my program be compiled as a multi-threaded DLL?
Yes, using static linking.
Yep, that’s the idea. How, without abandoning SDL, which seems to require that
linking be dynamic?
Why is it that other compilers seem to produce an end-product (a simple
executable) that Microsofts’ solution cannot?
Other compilers don’t work differently, they also need runtime libraries that
are usually linked dynamically.
I apologize; I was under the impression that they produced just an executable.
I think some of our disagreement here might stem from our preferred
environments. Windows users are, in general, much less forgiving of complicated
download processes and installs than those who come from a *nix background.
And I’m sorry if the question seems amateurish, but the build process has
changed a lot since I last wrote in C nearly a decade ago.> On Sunday 27 January 2008 04:06, Martin wrote:
Seriously though, I’ve been reading that there are problems with