Ulrich Eckhardt <doomster <at> knuut.de> writes:
> On Sunday 27 January 2008 04:06, Martin wrote:
> > 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
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
> > 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.
SDL mailing list