Firstly, this is not a complaint. Basically, I’m just wondering why
there is an SDLmain.lib that links code into my project rather than a
one time initialization call, something like SDL_OnetimeInit().
I have a desire to build my application using STATIC library linking
(not the dynamic linking that SDL forces). I discovered that if I
rebuild SDLmain using a static library build, and if I say name it
SDLmain-static.lib, then I can build my project using statically linked
libraries.
In the current design, SDLmain.lib forces all applications to be
dynalinked only (unless I rebuild and support another SDLmain.lib that
is statically linked). Again, this is an easy workaround, but I
wondering, am I missing something here in the design concept?
For the sake of completeness, the reason I want my application to
statically link is because I’m using VS 2005. Any application built
with VS 2005 that is a statically linked release build will run on any
computer. An application built with VS 2005 that is dynamically linked
requires the MS redistributable SxS assemblies to also be installed on
all target systems (somewhat of a pain).
Im sure that it is to keep SDL client programs source compatible across
different OSes. So even though windows needs a winmain or whatever, you dont
have to provide one, as SDLmain does. However, I have heard that you can
write your one platform specific main, and not link to SDLmain at all,
provided you do the setup that SDLmain does, see the source for the various
platforms for details.
I believe that SDLmain basically gives
Finally, you are aware that statically linking to SDL forces you to relesae
at least the object files of your program, or the source code.On 6/4/06, Doug wrote:
Firstly, this is not a complaint. Basically, I’m just wondering why
there is an SDLmain.lib that links code into my project rather than a
one time initialization call, something like SDL_OnetimeInit().
I have a desire to build my application using STATIC library linking
(not the dynamic linking that SDL forces). I discovered that if I
rebuild SDLmain using a static library build, and if I say name it
SDLmain-static.lib, then I can build my project using statically linked
libraries.
In the current design, SDLmain.lib forces all applications to be
dynalinked only (unless I rebuild and support another SDLmain.lib that
is statically linked). Again, this is an easy workaround, but I
wondering, am I missing something here in the design concept?
For the sake of completeness, the reason I want my application to
statically link is because I’m using VS 2005. Any application built
with VS 2005 that is a statically linked release build will run on any
computer. An application built with VS 2005 that is dynamically linked
requires the MS redistributable SxS assemblies to also be installed on
all target systems (somewhat of a pain).
D> Firstly, this is not a complaint. Basically, I’m just wondering why
D> there is an SDLmain.lib that links code into my project rather than a
D> one time initialization call, something like SDL_OnetimeInit().
D> I have a desire to build my application using STATIC library linking
D> (not the dynamic linking that SDL forces). I discovered that if I
D> rebuild SDLmain using a static library build, and if I say name it
D> SDLmain-static.lib, then I can build my project using statically linked
D> libraries.
D> In the current design, SDLmain.lib forces all applications to be
D> dynalinked only (unless I rebuild and support another SDLmain.lib that
D> is statically linked). Again, this is an easy workaround, but I
D> wondering, am I missing something here in the design concept?
D> For the sake of completeness, the reason I want my application to
D> statically link is because I’m using VS 2005. Any application built
D> with VS 2005 that is a statically linked release build will run on any
D> computer. An application built with VS 2005 that is dynamically linked
D> requires the MS redistributable SxS assemblies to also be installed on
D> all target systems (somewhat of a pain).
There is nothing to stop you statically linking the runtime libs, and
dynamically linking SDL. All you have to do is rebuild SDLmain so that
it also uses the runtime libs statically. The main SDL library will
continue to work just fine without rebuilding.
VS2005 doesn’t let you create an app that just uses MSVCR71.dll or
whatever ? That’s really bad if it doesn’t.–
Best regards,
Peter mailto:@Peter_Mulholland
For the sake of completeness, the reason I want my application to
statically link is because I’m using VS 2005. Any application built
with VS 2005 that is a statically linked release build will run on any
computer. An application built with VS 2005 that is dynamically linked
requires the MS redistributable SxS assemblies to also be installed on
all target systems (somewhat of a pain).
You have to distribute the dlls with your exe. This amounts to put them
in the same dir as your exe. Installation in a system folder is wrong for
these.
BrunoOn Sun, 04 Jun 2006 01:48:40 -0300, Doug wrote:
BB> Finally, you are aware that statically linking to SDL forces you to relesae
BB> at least the object files of your program, or the source code.
The licence USED to state that static linking was acceptable provided
an unchanged version of the SDL library was being used. I think
though, this only applied to platforms where dynamic linking was
either undesirable or unavailable, such as embedded platforms.–
Best regards,
Peter mailto:@Peter_Mulholland
There is nothing to stop you statically linking the runtime libs, and
dynamically linking SDL. All you have to do is rebuild SDLmain so that
it also uses the runtime libs statically. The main SDL library will
continue to work just fine without rebuilding.
This is what I did. I just rebuild SDLmain to statically link to the C
runtime library. As mentioned, I did NOT rebuild SDL.DLL at all - it
remains unchanged and unmodified.
Before I started investigating this, I had not realized the linking
structure of SDL, in that I didn’t see how SDLmain is code that is part of
MY application, and SDL.DLL is “external” code that is outside of my main
application’s “sandbox”. Since I did NOT want to rebuild all of SDL, I
ignored this for a while. Since I discovered that I can just rebuild only
SDLmain to static link to solve my problem, this was a VERY easy solution.
Just in case anyone else made the same mistake I did, there is no
SDLmain.DLL - there’s only an SDLmain.LIB that drops “init” code directly
into my application’s code space.
VS2005 doesn’t let you create an app that just uses MSVCR71.dll or
whatever ? That’s really bad if it doesn’t.
VS2005 uses manifests embedded in the application. These manifests
indicate what runtime libraries the application requires. Only a release
build statically-linked application has no EXTERNAL dependencies on a
runtime library. And since VS2005 is new, a typical WinXP system does not
have the required runtime libraries present.
Microsoft provides a distro package that installs the runtime libraries
required - and this is the “best practice”. But if you know which runtime
libraries are needed, you CAN copy them to the application’s folder and if
they are present the application will run. The latter case is not
recommended my Microsoft as it does an endrun around the SxS assemblies
management.
Finally, you are aware that statically linking to SDL forces you to relesae
at least the object files of your program, or the source code.
I would like to clarify this point, just to make sure I’m doing it right…
I rebuilt ONLY SDLmain.lib to be statically linked. The code in SDLmain.lib
becomes part of MY application anyways as there is no SDLmain.dll. By
building SDLmain.lib statically, it just means that the SDLmain code (which
will reside in my app) now expects to use the static C runtime library as
opposed to the dynamically-linked C runtime library.
I have NOT rebuilt SDL.DLL to be statically linked, as it doesn’t have to be.
SDL.DLL is external to my application, and however SDL.DLL is linked doesn’t
really matter - it seems.
So in summary, by changing SDLmain.lib to statically link to the C runtime
library, I’m not “embedding” any SDL code into my application’s codespace that
wasn’t there already. All it does is say to the SDLmain code, use this
runtime library instead of that one.
This is what I did. I just rebuild SDLmain to statically link to the C
runtime library. As mentioned, I did NOT rebuild SDL.DLL at all - it
remains unchanged and unmodified.
Before I started investigating this, I had not realized the linking
structure of SDL, in that I didn’t see how SDLmain is code that is part of
MY application, and SDL.DLL is “external” code that is outside of my main
application’s “sandbox”. Since I did NOT want to rebuild all of SDL, I
ignored this for a while. Since I discovered that I can just rebuild only
SDLmain to static link to solve my problem, this was a VERY easy solution.
Just in case anyone else made the same mistake I did, there is no
SDLmain.DLL - there’s only an SDLmain.LIB that drops “init” code directly
into my application’s code space.
That does indeed sound like the best way to do it on VC2005.
VS2005 doesn’t let you create an app that just uses MSVCR71.dll or
whatever ? That’s really bad if it doesn’t.
VS2005 uses manifests embedded in the application. These manifests
indicate what runtime libraries the application requires. Only a release
build statically-linked application has no EXTERNAL dependencies on a
runtime library. And since VS2005 is new, a typical WinXP system does not
have the required runtime libraries present.
Microsoft provides a distro package that installs the runtime libraries
required - and this is the “best practice”. But if you know which runtime
libraries are needed, you CAN copy them to the application’s folder and if
they are present the application will run. The latter case is not
recommended my Microsoft as it does an endrun around the SxS assemblies
management.
Oddly, Microsoft’s redistributable runtime was compiled with an external
.manifest file which makes it VERY easy for an end user to delete a <1KB
file and break everything as well. Another oddity is that VC2005 is the
first product line for x64 compilation (aside from the Platform SDKs)
yet Windows XP Pro x64 was released first, so has no VC2005 runtimes
included at all either. So far it really seems their x64 work has just
been for preperation for Vista.
Microsoft provides a distro package that installs the runtime libraries
required - and this is the “best practice”. But if you know which
runtime
libraries are needed, you CAN copy them to the application’s folder and
if
they are present the application will run. The latter case is not
recommended my Microsoft as it does an endrun around the SxS assemblies
management.
So in summary, by changing SDLmain.lib to statically link to the C runtime
library, I’m not “embedding” any SDL code into my application’s codespace that
wasn’t there already. All it does is say to the SDLmain code, use this
runtime library instead of that one.
Yep, this is fine. In fact, if you look at the SDLmain source files,
you’ll see they’re all in the public domain for you to use/copy/reuse
any way you like.
See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
There is nothing to stop you statically linking the runtime libs, and
dynamically linking SDL. All you have to do is rebuild SDLmain so that
it also uses the runtime libs statically. The main SDL library will
continue to work just fine without rebuilding.
This is what I did. I just rebuild SDLmain to statically link to
the C runtime library. As mentioned, I did NOT rebuild SDL.DLL at
all - it remains unchanged and unmodified.
This is not a very good idea in some cases. Your application, SDLmain and
SDL.DLL should all be using the same copy of the MS C runtime lib, be that
MSVCRT.DLL (or 70, 71, etc) or a static copy. Which is why SDL on Windows
normally links to MSVCRT.DLL.
Usually, you only need this when you, for example, free() memory that was
malloc()'d and returned by the 3rd party library (not necessarily applicable
to SDL), or when you need to manipulate a FILE* object returned by the 3rd
party library. With SDL on Windows, however, there is another consideration:
if you do
putenv(“SDL_VIDEODRIVER=directx”);
in your app, and your app links to a static C lib, and you are using SDL.DLL
(which will always link to either MSVCRxx.DLL or its own copy of C lib), SDL
will not see this envvar at all.
I do not have a list of what objects MS C libs maintain internally, but if
the above example is any indication, there are others.
if you do
putenv(“SDL_VIDEODRIVER=directx”);
in your app, and your app links to a static C lib, and you are using SDL.DLL
(which will always link to either MSVCRxx.DLL or its own copy of C lib), SDL
will not see this envvar at all.
Which is why SDL_putenv() and SDL_getenv() exist.
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
My app is not really a spit-polished-shrink-wrapped-killer-app, but
rather it’s just a proof-of-concept testing tool. So I don’t need many
spiffy features of SDL or environment handling, etc.
When I send the test app out for others to use, I really just wanted a
.ZIP file with the app and the SDLxxx.DLL files. Now by statically
linking, I don’t have to worry about excess VS2005 baggage.
So far, with my statically-linked app, it and SDL is working fine
together and I haven’t run into any issues at all. I am being careful
not to “cross-pollinate” memory handling in that my app’s new/deletes
are self-contained, and stuff allocated within SDL is also freed within
SDL (like SDL_FreeSurface(), SDL_FreeRW(), etc).
