Link SDL2 statically with Visual C++ 2012

I encounter an error when statically linking SDL2 in my application with Visual 2012.
I built SDL2 from latest repository, using the Visual 2012 project provided, with modifications so that it builds as a static lib with static VC runtime.

The application builds, but at execution it crashes with "application.exe has triggered a breakpoint."
According to Visual debugger, this happens line 98 in SDL_stdlib.c: (the line after _chktsk() below)

Code:
void
__declspec(naked)
_chkstk()
{
}

I can build SDL2 as dynamic dll or static dll, and in both cases my application is working.

If I build with SDL2 static lib, but with Runtime Library ‘Multi-threaded debug’ instead of ‘Multi-threaded’, my application works.

I added dependencies to winmm.lib, imm32.lib, version.lib as explained here (http://stackoverflow.com/questions/11095424/how-to-statically-compile-an-sdl-game-on-windows-with-vs2010).
I tried to exclude LIBCMT as advised here (http://stackoverflow.com/questions/3007312/resolving-lnk4098-defaultlib-msvcrt-conflicts-with), but then I get a bunch of unresolved externals.

My application is just an SDL initialization and exit:

Code:
#include “SDL.h”

int main(int argc, char** argv){
if (SDL_Init(SDL_INIT_VIDEO) == -1) {
return 1;
}

SDL_Quit();

return 0;

}

Any tips to investigate further would be great :slight_smile:

Are you using Visual Studio 2012 for a Store application, or Desktop
application?On Sat, Mar 30, 2013 at 10:08 AM, li <elie.huvier at gmail.com> wrote:

**
I encounter an error when statically linking SDL2 in my application with
Visual 2012.
I built SDL2 from latest repository, using the Visual 2012 project
provided, with modifications so that it builds as a static lib with static
VC runtime.

The application builds, but at execution it crashes with "application.exe
has triggered a breakpoint."
According to Visual debugger, this happens line 98 in SDL_stdlib.c: (the
line after _chktsk() below)

Code:

void
__declspec(naked)
_chkstk()
{
}

I can build SDL2 as dynamic dll or static dll, and in both cases my
application is working.

If I build with SDL2 static lib, but with Runtime Library ‘Multi-threaded
debug’ instead of ‘Multi-threaded’, my application works.

I added dependencies to winmm.lib, imm32.lib, version.lib as explained
herehttp://stackoverflow.com/questions/11095424/how-to-statically-compile-an-sdl-game-on-windows-with-vs2010
.
I tried to exclude LIBCMT as advised herehttp://stackoverflow.com/questions/3007312/resolving-lnk4098-defaultlib-msvcrt-conflicts-with,
but then I get a bunch of unresolved externals.

My application is just an SDL initialization and exit:

Code:

#include “SDL.h”

int main(int argc, char** argv){
if (SDL_Init(SDL_INIT_VIDEO) == -1) {
return 1;
}

SDL_Quit();

return 0;
}

Any tips to investigate further would be great [image: Smile]


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

MrOzBarry wrote:

Are you using Visual Studio 2012 for a Store application, or Desktop application?

A Desktop application.

What were your unresolved external functions?On Sun, Mar 31, 2013 at 2:42 AM, li <elie.huvier at gmail.com> wrote:

**

MrOzBarry wrote:

Are you using Visual Studio 2012 for a Store application, or Desktop
application?

A Desktop application.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

MrOzBarry wrote:

What were your unresolved external functions?

That’s a list of __security_cookie, something like:

1>hello.obj : error LNK2019: unresolved external symbol @__security_check_cookie at 4 referenced in function _SDL_main
1>hello.obj : error LNK2019: unresolved external symbol ___security_cookie referenced in function _SDL_main

I tried to follow the information found here (http://forums.codeguru.com/showthread.php?458059-quot-unresolved-external-symbol-__security_cookie-quot-Problem), and it seems that can I solve this error by either adding a dependency to bufferoverflowU.lib, or disabling Security Check in project options (flag /GS-).
In both cases, I get the following error when building:

error LNK2001: unresolved external symbol _WinMainCRTStartup

In both cases though, I can still build and successfully run if I use a ‘Multi-threaded debug’ Runtime Library instead of ‘Multi-threaded’.

Is your project a win32 console or a windows form project? You may have to
tell the compiler it is a windows/form project in your project settings if
you specified that it’s a console project.On Sun, Mar 31, 2013 at 10:21 AM, li <elie.huvier at gmail.com> wrote:

**

MrOzBarry wrote:

What were your unresolved external functions?

That’s a list of __security_cookie, something like:

Quote:

1>hello.obj : error LNK2019: unresolved external symbol
@__security_check_cookie at 4 referenced in function _SDL_main
1>hello.obj : error LNK2019: unresolved external symbol ___security_cookie
referenced in function _SDL_main

I tried to follow the information found herehttp://forums.codeguru.com/showthread.php?458059-quot-unresolved-external-symbol-__security_cookie-quot-Problem,
and it seems that can I solve this error by either adding a dependency to
bufferoverflowU.lib, or disabling Security Check in project options (flag
/GS-).
In both cases, I get the following error when building:

Quote:

error LNK2001: unresolved external symbol _WinMainCRTStartup

In both cases though, I can still build and successfully run if I use a
’Multi-threaded debug’ Runtime Library instead of ‘Multi-threaded’.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

MrOzBarry wrote:

Is your project a win32 console or a windows form project? ?You may have to tell the compiler it is a windows/form project in your project settings if you specified that it’s a console project.

You mean the flag /SUBSYSTEM:WINDOWS, right?
This is the case already.

I don’t have access to VS2012 anymore, so I’m sort of running out of ideas

  • anyone else with VS2012? I can’t say I ever ran into any sort of
    CRTStartup problem when I tried compiling and linking to SDL2 apps.

Sorry I can’t be of any more helpOn Mon, Apr 1, 2013 at 9:09 AM, li <elie.huvier at gmail.com> wrote:

**

MrOzBarry wrote:

Is your project a win32 console or a windows form project? You may have
to tell the compiler it is a windows/form project in your project settings
if you specified that it’s a console project.

You mean the flag /SUBSYSTEM:WINDOWS, right?
This is the case already.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Can you post your modified .vcxproj file somewhere so one can try to
repro this?

If VS11 access is the only problem … a free download of the Express
version is here:
http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktopOn 4/1/2013 6:56 AM, Alex Barry wrote:

I don’t have access to VS2012 anymore, so I’m sort of running out of
ideas - anyone else with VS2012? I can’t say I ever ran into any sort
of CRTStartup problem when I tried compiling and linking to SDL2 apps.

Sorry I can’t be of any more help

On Mon, Apr 1, 2013 at 9:09 AM, li <elie.huvier at gmail.com <mailto:elie.huvier at gmail.com>> wrote:

MrOzBarry wrote: 	

Is your project a win32 console or a windows form project?  You
may have to tell the compiler it is a windows/form project in your
project settings if you specified that it's a console project.
	


You mean the flag /SUBSYSTEM:WINDOWS, right?
This is the case already.

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Andreas Schiffler wrote:

Can you post your modified .vcxproj file somewhere so one can try to repro this?

I uploaded my application project (Game.vcxproj) and SDL project (SDL_VS2012.vcxproj) here: http://www.files.com/set/5159b39a5e530

Except that I put the wrong file in the zip.
So here are the right ones

Back to this topic with some results that are hopefully interesting…

I managed to build everything I need statically (SDL, SDL_image, SDL_ttf.)

I found three ways to get rid of the unresolved symbol _WinMainCRTStartup; in all cases I build with /NODEFAULTLIB, so that I know which are the actual dependencies.

Solution 1) Dependency on msvcrt.lib; this works well, but my application gets a dependency on msvcr110.dll, which I clearly don’t want (it would require to bundle MS VC11 redist or the dll file.)

Solution 2) Dependency on libcmt.lib; that’s what I settled with for now (no extra Windows dll dependency.)
However, I have to remove the _chktsk function from SDL_stdlib.c (lines 95-99), otherwise the application crashes on startup.
I also have to remove the declaration of _fltused in SDL_stdlib.c (line 53) if I use SDL_image, otherwise build fails with LNK2005: __fltused already defined.

Solution 3) No dependency on msvcrt.lib and libcmt.lib, but define SDL_main as entry point for the application.
Actually I cannot build my application like this, but it works for a minimalist application, only linking with SDL.lib, drawing a rectangle.

So I wonder, do I need a dependency on Visual C runtime? If yes, my understanding is that SDL_stdlib.c is not compatible with static VC runtime, but only with msvcrxx.dll.

Message-ID: <1366905161.m2f.36777 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Back to this topic with some results that are hopefully interesting…

I managed to build everything I need statically (SDL, SDL_image, SDL_ttf.)

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? Bear in mind that if you have a properly designed installer
application, then the only place you should WANT to do this is in the
actual installer itself. You might want to stick all of the dll files
into the same directory as your actual program so that it’ll give them
preferential treatment, and so they won’t be deleted by something else
uninstalling itself, but as a general rule of thumb you usually DO
want to use dynamic linking for some things (particularly SDL and your
language runtime), so that you can just distribute those when you want
to provide improvements, instead of distributing your entire program.

Certainly, there are places where I would consider purely static
linking good, but they basically consist of installers and core system
components, and then mostly to reduce the chances of breaking your
system by overwriting something important. For ordinary applications
AND ordinary system components, I would use at least the msvcrt dll.

I found three ways to get rid of the unresolved symbol _WinMainCRTStartup;
in all cases I build with /NODEFAULTLIB, so that I know which are the actual
dependencies.

Solution 1) Dependency on msvcrt.lib; this works well, but my application
gets a dependency on msvcr110.dll, which I clearly don’t want (it would
require to bundle MS VC11 redist or the dll file.)

Go and check the redistribution terms for msvcrt*.dll (might be here:
http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx).
If the redistribution terms are acceptable for your usage, then I’d
suggest shipping it with your executable. There are other ways to deal
with the need for an entry point, but you don’t really want to deal
with that, and it actually DOESN’T improve things for the most part.

Solution 2) Dependency on libcmt.lib; that’s what I settled with for now (no
extra Windows dll dependency.)
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?

I also have to remove the declaration of _fltused in SDL_stdlib.c (line 53)
if I use SDL_image, otherwise build fails with LNK2005: __fltused already
defined.

_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.

Solution 3) No dependency on msvcrt.lib and libcmt.lib, but define SDL_main
as entry point for the application.
Actually I cannot build my application like this, but it works for a
minimalist application, only linking with SDL.lib, drawing a rectangle.

So I wonder, do I need a dependency on Visual C runtime? If yes, my
understanding is that SDL_stdlib.c is not compatible with static VC runtime,
but only with msvcrxx.dll.

As a general rule of thumb, and C program on the Windows platform does
require one or another of the Microsoft Visual C runtimes. In fact,
even Mingw/MSys use it (not so certain about Cygwin). Here’s a link
that’s relevant to this issue:


. In essence, the Visual C runtime implements the actual support for C
in Windows. You might not be able to build your application without
the runtime, 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.

Now, I said earlier that there are ways other than what you did to
deal with the entry-point, and indeed there are. In fact, this is also
true of the runtime. There are basically four “common” runtime
environments on the Windows platform (and five if you count Windows
8): Win32 (by far the most common), Interix (or something like that,
it’s a Posix emulation layer), .NET, and Native. These are what actual
programs perceive as the OS. The Microsoft Visual C runtime is not
party of any of these environments, which implies that you can do
without it: and indeed, you can. In fact, there’s currently a project
to create an open-source alternative, and if you’re one of the handful
of Windows assembly programmers then you might not use a runtime at
all. However, if you’re using anything other than C, that really just
means that you have to implement all of that functionality yourself.
This is NOT something that application developers should be doing,
this is a job for COMPILER DEVELOPERS.

In short: make an exception to your static-linking for the Microsoft
Visual C runtime, static linking to that is almost guaranteed to be
more trouble than it’s worth.> Date: Thu, 25 Apr 2013 08:52:42 -0700

From: “li” <elie.huvier at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Link SDL2 statically with Visual C++ 2012

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 :slight_smile:

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; counting on msvcrxx.dll on the target system would probably work, but then I have to choose a version (say msvcr80.dll), but if I can build without this kind of dependency it’s even better.
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.

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.”

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 :smiley:

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.

So I have to work on this /clr switch, and on libs configuration to restore _fltused.
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.

I still want - if possible - libcmt.lib and not msvcrt.lib, so any hint on the _chkstk issue would be appreciated…

SDL does not attempt to replace the C runtime. You need to link to the Visual C++ runtime (which includes both the security cookie and _WinMainCRTStartup)!

All that SDL_stdinc.* does is implement needed standard C types/functions that are missing from some C/C++ runtimes. When the C/C++ runtime does include these functions, SDL’s implementations default to the C/C++ runtime’s implementations.------------------------
Nate Fries

If you’re truly insistent on ditching MSVCrt, however, you could always disable just about every default compiler option and use Matt Pietrick’s libctiny (I hope you’re ready to fix dinosaur code issues, though) or Google’s minicrt (if that’s even still floating around, I can’t seem to find the source code or even a download with Google lol), or you could always go through the “fun” of implementing your own CRT.

As it happens, MSVCRT source code is supposed to be included with Visual C++, so you actually have a first-hand reference to how to implement a Visual C+±compatible CRT if you wanted to (and yes, you can totally statically link it).------------------------
Nate Fries

I’ve run into the chkstk assertion when I allocate more than 4k in a stack
frame. If you’re allocating that much, I would recommend using
SDL_stack_alloc() / SDL_stack_free() or dynamically allocating the data you
need.On Sat, Mar 30, 2013 at 7:08 AM, li <elie.huvier at gmail.com> wrote:

**
I encounter an error when statically linking SDL2 in my application with
Visual 2012.
I built SDL2 from latest repository, using the Visual 2012 project
provided, with modifications so that it builds as a static lib with static
VC runtime.

The application builds, but at execution it crashes with "application.exe
has triggered a breakpoint."
According to Visual debugger, this happens line 98 in SDL_stdlib.c: (the
line after _chktsk() below)

Code:

void
__declspec(naked)
_chkstk()
{
}

I can build SDL2 as dynamic dll or static dll, and in both cases my
application is working.

If I build with SDL2 static lib, but with Runtime Library ‘Multi-threaded
debug’ instead of ‘Multi-threaded’, my application works.

I added dependencies to winmm.lib, imm32.lib, version.lib as explained
herehttp://stackoverflow.com/questions/11095424/how-to-statically-compile-an-sdl-game-on-windows-with-vs2010
.
I tried to exclude LIBCMT as advised herehttp://stackoverflow.com/questions/3007312/resolving-lnk4098-defaultlib-msvcrt-conflicts-with,
but then I get a bunch of unresolved externals.

My application is just an SDL initialization and exit:

Code:

#include “SDL.h”

int main(int argc, char** argv){
if (SDL_Init(SDL_INIT_VIDEO) == -1) {
return 1;
}

SDL_Quit();

return 0;
}

Any tips to investigate further would be great [image: Smile]


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 :slight_smile:

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 :smiley:

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
(http://wiki.osdev.org/C%2B%2B_Bare_Bones#C.2B.2B_specifics) 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:
(http://wiki.osdev.org/C%2B%2B), 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:
http://stackoverflow.com/questions/2782915/what-should-i-know-about-structured-exceptions-seh-in-c
.

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 :slight_smile: . 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 :wink: .

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:

  1. 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);
  2. 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
  3. 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

Message-ID: <1366938849.m2f.36784 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

If you’re truly insistent on ditching MSVCrt, however, you could always
disable just about every default compiler option and use Matt Pietrick’s
libctiny (I hope you’re ready to fix dinosaur code issues, though) or
Google’s minicrt (if that’s even still floating around, I can’t seem to find
the source code or even a download with Google lol), or you could always go
through the “fun” of implementing your own CRT.

I’m actually doing something similar: writing a C-style
virtual-function interface for part of the C runtime! Admittedly my
goal is “constrained”, but said goal is to write a printf
implementation that will send it’s output to an arbitrary character
stream interface, while being compatible with completely arbitrary
character encodings (including with variable widths, alignment
multiples other than the actual size of a character, and offsets from
those alignments), including “characters” that are actually e.g. C++
classes, so it’s insane in it’s own way.

A decent portion of the old portion of the C standard library is
fairly simple and straight forward, but setjump/longjmp require
assembly, and various other problems come up as well, and that’s not
even considering issues like C++'s exceptions, and run-time type
information, where I’ve gotten the impression that they might actually
vary with the compiler flags. These are dark and dangerous waters.> Date: Thu, 25 Apr 2013 18:14:09 -0700

From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Link SDL2 statically with Visual C++ 2012

Jared Maddox wrote:

If you’re truly insistent on ditching MSVCrt, however, you could always
disable just about every default compiler option and use Matt Pietrick’s
libctiny (I hope you’re ready to fix dinosaur code issues, though) or
Google’s minicrt (if that’s even still floating around, I can’t seem to find
the source code or even a download with Google lol), or you could always go
through the “fun” of implementing your own CRT.

I’m actually doing something similar: writing a C-style
virtual-function interface for part of the C runtime! Admittedly my
goal is “constrained”, but said goal is to write a printf
implementation that will send it’s output to an arbitrary character
stream interface, while being compatible with completely arbitrary
character encodings (including with variable widths, alignment
multiples other than the actual size of a character, and offsets from
those alignments), including “characters” that are actually e.g. C++
classes, so it’s insane in it’s own way.

A decent portion of the old portion of the C standard library is
fairly simple and straight forward, but setjump/longjmp require
assembly, and various other problems come up as well, and that’s not
even considering issues like C++'s exceptions, and run-time type
information, where I’ve gotten the impression that they might actually
vary with the compiler flags. These are dark and dangerous waters.

Trust me, I know, I’m implementing my own C runtime right now. Basic C++ support is important (in fact, I just finished getting MinGW static global C++ constructors and destructors to work), but I never use exceptions so that will probably be the last thing I make work (especially since MinGW and Visual C++ do it completely differently (and in fact MinGW can do it two different ways), and this means massive bloat in my runtime to implement it both ways…)
As for setjmp/longjmp; you make it sound like capturing the current context and resetting it later is difficult. :)------------------------
Nate Fries