Message-ID: <1366918891.m2f.36779 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”
Jared Maddox wrote:
Just to confirm: you’re trying to link EVERYTHING statically, so that
it is bundled into the same actual executable file as your program,
right?
Yes, I’m trying to build a one file application.
I understand that I can provide an installer, which will contain all the
dlls required, but that’s not what I’m trying to do.
I also understand that SDL2 “zlib” license allows me to do so, which is why
I insist on it 
Ok, but what is your actual reason for WANTING to statically link
everything? When I went through this stage it was partially because I
didn’t want to worry about redistibution rules, and partially because
I wanted things to be “nuke proof”. I actually have some ideas on how
I could still pull off that last bit, though I haven’t spent the time
and effort yet. What’s YOUR reason?
Jared Maddox wrote:
For ordinary applications
AND ordinary system components, I would use at least the msvcrt dll.
Go and check the redistribution terms for msvcrt*.dll (might be here:
http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx).
msvcrxx.dll sounds pretty horrible. I can bundle msvcr110.dll, I guess
Microsoft allows it, but I don’t want any dll from the start;
Just for reference, you do know that every Windows application,
including those that actually implement the Win32 api, all have to
perform a load-time (aka not statically linked) access to nt.dll,
right? The kernel interface isn’t reliable, so ALL kernel calls go
through that dll, where they then get translated into calls to the
kernel itself. This is even true of the Native API, and the native api
is used to implement all of the OTHER apis.
If you’re opposed to using nt.dll… well, in that case you’ve gone
off the deep end. It is part of the (poorly) DEFINED way that Windows
applications ARE to follow when interacting with the operating system.
This is used by basically everything that doesn’t get compiled with
the kernel itself, and is basically a “THOU SHALT” sort of thing. I
haven’t seen anything in this conversation that I’ve been convinced
was actually related to SDL, but this one I won’t even try to help you
with, we’re not talking about DOS or bare-metal here.
counting on
msvcrxx.dll on the target system would probably work,
The C runtime dlls aren’t distributed with Windows itself. If the user
has already installed another program then you’re HOPEFULLY safe, but
if they haven’t (let’s say they’ve gotten a new system, and your
program is the first one they want to use on the new install) then
you’re likely to get some confused bug reports. Thus, you really do
want to distribute them if you’re using them.
The link you provide mentions about the /clr switch, I looked at it
suspiciously so far, but I will try to look at it more closely.
/clr is for programs that either use, or interact with, the .NET
runtime, such as those written partially or entirely in C#. It’s very
likely that you DON’T want it.
Jared Maddox wrote:
However, I have to remove the _chktsk function from SDL_stdlib.c (lines
95-99), otherwise the application crashes on startup.
Are you certain about the spelling? Google only seems to know of
_chkstk. What does it tell you about the crash?
You’re right, it’s _chkstk. The crash is the one I described in the initial
post: “application.exe has triggered a breakpoint.”
That sounds like you have debugging enabled? I don’t use MS Visual
Studio so I won’t be much help on this, but if you list your compiler
& similar settings then someone else might be able to point out where
you’re running into problems (a small program, much like your “draw
rectangle” program, that runs into the same problem would be even
better).
Jared Maddox wrote:
_fltused seems to trigger inclusion of floating-point code. Probably
another case of shooting yourself in the foot by using all-static
linking. However, you might try to alter how, exactly, you do your
linking in order to deal with this. In particular, see if moving all
linkage to libcmt.lib & co. to a linking stage AFTER you link the
libraries & your code helps.
That would be due to mis-configuration of my libs and not conflict with
libcmt.lib then, I will try to dig this further, I don’t want to remove
floating-point support 
I don’t blame you, I consider floating-point important for most modern
applications myself. Bear in mind that so far, what I’ve noticed (I
only started paying attention with your previous message, mind you)
all sounds to me like some form or another of configuration (or maybe
code…) problem. If you can get a code sample (like the one I
suggested above) that supports all of the features that you want but
WORKS, then you’ll have a pretty good hint that the problem is either
in your configuration, or your code (or both! that can happen too). If
you CAN get such a working proof-of-concept then I suggest abandoning
your current attempt, making a duplicate of the successful demo, and
reimplementing on top of that. A few months ago I was working on the
formatting of a web page, and that kind of reimplementing-from-scratch
technique was the only thing that got it to do what I thought it was
already supposed to be doing.
Jared Maddox wrote:
[…] but I’m surprised that you were able to get your
rectangle-drawer working without it, since the runtime actually calls
the main (or WinMain!) function.
Yes, it works, which is why I was thinking that I could get entirely rid of
VC runtime.
It’s not working well though, I forgot to mention it, the application is not
closing properly, the process is still running after ‘exit’, even though the
window is closed.
It might not actually be running after that. I haven’t attempted to
implement a Windows C Run-time myself, but I think the OS expects some
sort of call from the application when it’s exiting.
And I understand that I should keep VC runtime; my code is C++ and I rely
comfortably on STL; STL requires libcpmt.lib, which in turn is extremely
likely to require VC runtime.
Oh very much so. In fact, with MSVC++ I’d say that doing without the
runtime is even more of a bad idea. For some references on what you’d
have to do THEN, start reading this
(Bare Bones - OSDev Wiki) page at
the section linked, then skip down to the “kmain.cpp” and read from
AFTER the code and command-line examples, to where the “linker.ld”
section begins (incidentally, you might find some command-line
switches with interesting Visual C++ versions). Also read this:
(C++ - OSDev Wiki), which you might as well read all the
way to the end (bear in minds that the STL sort-of is part of the
language specification, and that “STL” is actually an unofficial name
that all reasonable people are simply okay with, rather than being
official). This is also relevant:
What should I know about Structured Exceptions (SEH) in C++? - Stack Overflow
.
All in all, I’d say those three links should provide all of the
information needed to weasel out of implementing the C & C++ runtime
libraries if you ever have a boss that wants you to do it . In
fact, the very fact that two of those links are to a site dedicated to
writing Operating Systems should be enough to pull off the trick 
.
However, just in case you’re actually interested AFTER looking through
those links, despite not being interested BEFORE, there probably are
some zlib (or similar) licensed C & C++ standard libraries available
that can be adapted to Windows by just changing out OS calls.
Particularly with the STL, I think that you’d only have to worry about
allocation/deallocation, RTTI, and exceptions. I don’t know how the
Microsoft implementation does those, but I do half-remember running
across relevant information online. I strongly recommend against this,
but it can be done.
I still want - if possible - libcmt.lib and not msvcrt.lib, so any hint on
the _chkstk issue would be appreciated…
I don’t recall the problem itself, but if the symbol wasn’t found then
you can implement it yourself, link:
. If your getting some sort of fault triggered by _chkstk then it’s
most likely an access violation, cause by trying to use more stack
space than your program is ALLOWED to have. The three most likely
reasons for this are:
- You allocated so much memory on the stack, either in huge objects
or via a long function-call cascade, that you honest-to-goodness ran
out. I kid ye not, I HAVE ACTUALLY DONE THIS, specifically in an
STL-based game-map system (I believe that it was 3-d too, though it’s
been quite a while);
- You have an infinite loop. I think that everyone does this at least
once, which is why most of us consider fiddling with operating systems
high-level work, and memory-protection is so common; and
- You reduced the stack allocation for your application below some
reasonable level. If this is what you did then you should have a
REALLY
good reason for both using SDL, AND aiming for extremely
memory-constrained systems.
Now, here’s what I think is going on, and please correct me if I’m
wrong: you’re wanting to write a plain, no-frills application, no
fancy glitter or anything else, and thus you’ve been lead to not using
dlls because they’re “fancy”, and to reducing the stack size because a
big stack is inherently heavier than a small one (remember, I’ve gone
down the path I’m describing myself). It’s straight-forward and
logical, but at the same time it’s NORMALLY a bad idea. I recommend
that unless you’re interested in running into lots of headaches (or,
alternatively, implementing a programming language) that you just use
the mscvrt dlls, and distribute them with your program. You can do
this by writing a small helper/launcher program that looks around for
the dlls, writes some copies that are EMBEDDED INTO IT out to disk if
it doesn’t find them (this is very easy to do, and only requires some
command-line programs), and then starts the real program, all using
only Win32 functions. It won’t be cross-platform, but it will be very
EASY to MAKE cross platform, since only a handful of basic functions
are required. I’ve even scratched out concepts of the bits other than
the helper/launcher, and THOSE can be used to embed any data files
into any non-final executable for any platform without even having to
port them.> Date: Thu, 25 Apr 2013 12:41:32 -0700
From: “li” <elie.huvier at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Link SDL2 statically with Visual C++ 2012
