making self contained executables?

i've tried to find out how to do this before, but my compiler documentation doesn't seem to have any mention of how to do this.

i use borland c++ builder; i have v6, but could upgrade if necessary.

what i would like to do is, instead of having to manage the locations of all the library files used by my applications, to compile them into the executable.

there are lots of apps i use that are totally self-contained executables, so how do i achieve this? what is the correct jargon to google or search the helpfiles with?

thanks!

Essentially, you need an executable that is statically linked. I have no direct knowledge of how you do that, but basically it means "don't link to DLL's".

--
Mats

Quote:

---

Originally Posted by m37h0d

there are lots of apps i use that are totally self-contained executables, so how do i achieve this? what is the correct jargon to google or search the helpfiles with?

---

"Most" applications nowadays are not self-contained. They install proper runtime with the installer. Statically linking bloats the size of your program every time. Instead you can install the runtime once and never need it again.
I prefer the latter.

Quote:

---

Originally Posted by Elysia

"Most" applications nowadays are not self-contained. They install proper runtime with the installer. Statically linking bloats the size of your program every time. Instead you can install the runtime once and never need it again.
I prefer the latter.

---

thanks, but do you have a link handy or something to help me find out how to actually achieve this?

Not for Borland, no.

Quote:

---

Originally Posted by Elysia

"Most" applications nowadays are not self-contained. They install proper runtime with the installer. Statically linking bloats the size of your program every time. Instead you can install the runtime once and never need it again.
I prefer the latter.

---

Just DLL'izing the runtime doesn't necessarily prevent code bloat. Most applications will install a local copy of the runtime just in case it wasn't there to begin with. (By "runtime" I don't mean the C library -- dynamically linking with that is pretty much a no-brainer.) And installing a runtime for the entire system is a huge no-no, in my book. I hate it when a program wants to touch things in the system directory.

So the end result is the DLL's get duplicated everywhere anyway. I far prefer this code replication to the nightmare that would result otherwise. Disks are big -- who cares.

Quote:

---

Originally Posted by brewbuck

Most applications will install a local copy of the runtime just in case it wasn't there to begin with. (By "runtime" I don't mean the C library -- dynamically linking with that is pretty much a no-brainer.)

---

That pretty much defeats the purpose of linking dynamically, though. I hate it when programs do that.

Quote:

---

And installing a runtime for the entire system is a huge no-no, in my book. I hate it when a program wants to touch things in the system directory.

---

This is where they belong! It's runtime. Therefore it should belong in the system directory so that all programs can access it. That's the point of the directory.

Quote:

---

So the end result is the DLL's get duplicated everywhere anyway. I far prefer this code replication to the nightmare that would result otherwise. Disks are big -- who cares.

---

Some people are still stuck on 56k and 26k or worse modems.

that's all well and good, but i really need this to be as foolproof as possible!

this application is going to be running on a tool, not someone's personal computer.

the most important thing to me is that someone can't do something stupid, like move a file, and break it.

Install runtime on remote computer.
Install application on remote computer.
All works.

But, you could try switching to an alternate IDE if you really want static. Try Visual Studio for example.

With risk of derailing this thread further, I'd like to point out that Windows has pretty poor capabilities of coping with a variety of VERSIONS of runtime-DLL's. The Linux model of naming the file with version number all the way down to build-number, and then using symbolic links to get generic versions available to programs that don't care is much better.

Unfortunately, this means that unless the applications start using:
MyLibrary4.2.3.11.dll
instead of
Mylibrary4.dll

each application would have to keep it's own copy to ensure that some other DLL of the same name doesn't interfere with it's own one.

--
Mats

Quote:

---

Originally Posted by Elysia

This is where they belong! It's runtime. Therefore it should belong in the system directory so that all programs can access it. That's the point of the directory.

---

Why the heck do I want ALL my programs to break just because one of them installs a buggy library? What if some program relies on some bit of undefined behavior, which changes in the next version of the runtime? Sure, the program is technically buggy by relying on undefined behavior, but try explaining that to the end user who's screaming on the phone that when they installed your program, some other program they use broke.

IMHO, the only modern function of DLLs is to make upgrading and patching easier, NOT to reduce code replication. As matsp says, the situation is somewhat better on UNIX.

I understand what you mean. And I also hate it when programs misuse DLLs like that.
But... enough of that. The question at hand...

so uhh...lots of opinions about it, but does anybody have a clue about how to do it?

Ya don't say... I already asked, but... you don't think you can use another IDE? Visual Studio is very good and popular and can do what you want fine.

Quote:

---

Originally Posted by Elysia

Ya don't say... I already asked, but... you don't think you can use another IDE? Visual Studio is very good and popular and can do what you want fine.

---

yeah, not the first time i've considered doing it, but that's just not a plausible option at this point.

Are you using any extra DLLs, or just the standard C/C++ runtime?

Quote:

---

Static Libraries

Borland C++ Builder
Borland does not really encourage us to do this. Obviously they just could not imagine anyboudy would like to do something as obscure as a static library? Therefore there is no tool for this included in the integrated development environment.

If somebody absolutely insists on producing static libraries anyway will have to live with the command line utilities in the Commandline Window. For creating static libraries there is the the program tlib.exe, which I am not going to go in further detail about. Call syntax and possible options are documented in the online documentation to the C++ Builder.

For those who have to live with this piece of software I only recommend creating a dynamic library instead. That has some glitches, too, but will in the long run be much less annoying.

---

From http://herbert.the-little-red-haired...ows/index.html

Useless food for thought: http://www.ddj.com/windows/184416443

Quote:

---

Originally Posted by dwks

Are you using any extra DLLs, or just the standard C/C++ runtime?

From http://herbert.the-little-red-haired...ows/index.html

Useless food for thought: http://www.ddj.com/windows/184416443

---

this link is actually incorrect.

i got my boss to cough up the $ to sign up at experts exchange.

you just have to uncheck 2 runtime build options and you're off!

Mm'kay, care to tell us what those two build options are? :)

depends on your version. they're both under project->options

in 6, you must uncheck both packages->"build with runtime packages" and linker->"use dynamic RTL"

the first one is the same for BCB2k6, but the second one is something about "release build" or some such. i dont' remember that one offhand.