Hi ! 
I currently use Visual C++ 6, and I do use SDL and SDL_IMAGE in my code.
My projects are compiled as Win32.
So I’ve always got to have those sdl.dll, sdl_image.dll, zlib.dll, jpeg.dll,
libpng1.dll together with my .exe and my datas.
Is there any possibility to have those dll be in the .exe directly ? Any
compilation option that could do this to avoid having too many files ?
Thanks already for the help 
MrHoward.
The name for the solution that you are looking for is a “statically
linked executable”… which, just happenes to be the thing I myself am
working on right now (for my own project, SDL already supports them).
Since SDL is LGPLed, however, unless you plan on releasing source code
to your application, you are legally obligated to provide the user a way
to relink against newer/older/customized versions of each of these
libraries. The EASIEST way to do this is to provide a “dynamically
linked executable” (what you have now)… One common alternative is to
just package your application with BOTH a static executable, and a
dynamic one.
I hope that helps explain the situation to you.
As for the specifics of telling VC++ TO make a static executable, I
don’t have VC++ availible here to figure it out.
Best of luck,
-LorenOn Mon, 2002-08-26 at 00:29, MrHoward wrote:
Hi !
I currently use Visual C++ 6, and I do use SDL and SDL_IMAGE in my code.
My projects are compiled as Win32.
So I’ve always got to have those sdl.dll, sdl_image.dll, zlib.dll, jpeg.dll,
libpng1.dll together with my .exe and my datas.Is there any possibility to have those dll be in the .exe directly ? Any
compilation option that could do this to avoid having too many files ?Thanks already for the help
MrHoward.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi there;
I believe you can also supply intermediate object files for your own code
instead of giving away source-- what we did the old days before DLLs (or
newer days if you used RISC OS as doggedly as I did) I personally think
binary shared libraries are a complication I can do without for packaged
software because they must make debugging, version control and portability a
pain. So my build structure compiles a load of LGPL software (SDL,
SDL_mixer, SDL_rotozoom etc.) together with my program, while also spitting
out a MyGame.a file for the receipients to relink against if they like.
cheers,On Monday 26 August 2002 12:13, Loren Osborn wrote:
The name for the solution that you are looking for is a “statically
linked executable”… which, just happenes to be the thing I myself am
working on right now (for my own project, SDL already supports them).
Since SDL is LGPLed, however, unless you plan on releasing source code
to your application, you are legally obligated to provide the user a way
to relink against newer/older/customized versions of each of these
libraries. The EASIEST way to do this is to provide a “dynamically
linked executable” (what you have now)… One common alternative is to
just package your application with BOTH a static executable, and a
dynamic one.
–
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026
trying to linke everything statically is a nightmare, because
you need to recompile sdl and every other lib that does not come
already as a static lib. and i was NOT able to recompile the png lib…
i managed to create a static lib for sdl_mixer, sdl_image , libjpeg
and sdl , but i still need to provide the png.dll …
i personally prefer static libs if possible, because of the well
known “dll hell”. i always forget to include the right dll in my game ,
and there is the possibility of api-changes wich leads to
nonpredictable errors.
AND - because sdl.dll and the other opensource-libs are not very
distributed, one main argument of dll-usage, the reduction of disk
space, does not count.
so why not always provide precompiled dev-packs with static libs ?
i would love that!
regards, andre
Loren Osborn <linux_dr at yahoo.com> wrote:
(08/26/2002 13:13)>The name for the solution that you are looking for is a "statically
linked executable"… which, just happenes to be the thing I myself am
working on right now (for my own project, SDL already supports them).
Since SDL is LGPLed, however, unless you plan on releasing source code
to your application, you are legally obligated to provide the user a way
to relink against newer/older/customized versions of each of these
libraries. The EASIEST way to do this is to provide a “dynamically
linked executable” (what you have now)… One common alternative is to
just package your application with BOTH a static executable, and a
dynamic one.I hope that helps explain the situation to you.
As for the specifics of telling VC++ TO make a static executable, I
don’t have VC++ availible here to figure it out.Best of luck,
-Loren
On Mon, 2002-08-26 at 00:29, MrHoward wrote:
Hi !
I currently use Visual C++ 6, and I do use SDL and SDL_IMAGE in my code.
My projects are compiled as Win32.
So I’ve always got to have those sdl.dll, sdl_image.dll, zlib.dll, jpeg.dll,
libpng1.dll together with my .exe and my datas.Is there any possibility to have those dll be in the .exe directly ? Any
compilation option that could do this to avoid having too many files ?Thanks already for the help
MrHoward.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl