Re: creating stand-alone extended tclsh
- From: "Gerald W. Lester" <Gerald.Lester@xxxxxxx>
- Date: Sun, 29 Apr 2007 07:29:50 -0500
Alexandre Ferrieux wrote:
On Apr 29, 12:06 pm, David Gravereaux <davyg...@xxxxxxxxx> wrote:4) relish your in your large executable, though I prefer those grilled red onions
and mustard to top my dogs.
I'm a bit surprised by this aversion of static linking. Though
obviously it's a waste of system resources for libc or libX11, for
most of the rest of libs, it changes absolutely nothing because the
executable is the only one in the system that will *ever* use it
(specific libraries : only for specific needs). While static linking
has several pointwise advantages I have come across:
- debugging in old versions of gdb
- no risk of half-install
- no risk of version mismatch
- single-file installerless executable (like a *kit but with no
startup overhead due to extracting DLLs to temporary files).
The aversion comes from experience.
The experience of constant rebuilds when a new version of an extension (available pre-built in a binary) we use comes out or when we need another extension.
Feel free to do as you like, experience tells most of us that is not the way to go.
BTW, version mismatch between executables is almost non-existent due to TEA. You are much more likely to hit a problem, over time, that some of the scripts you are using want version X and some want version Y of a packages. With static linking this is a problem, with dynamic loading Tcl will load the correct version in for you automatically (both can exist on the disk at the same time due again to TEA).
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
.
- Follow-Ups:
- Re: creating stand-alone extended tclsh
- From: Eric Hassold
- Re: creating stand-alone extended tclsh
- From: Alexandre Ferrieux
- Re: creating stand-alone extended tclsh
- References:
- creating stand-alone extended tclsh
- From: Will Parsons
- Re: creating stand-alone extended tclsh
- From: David Gravereaux
- Re: creating stand-alone extended tclsh
- From: Alexandre Ferrieux
- creating stand-alone extended tclsh
- Prev by Date: Re: creating stand-alone extended tclsh
- Next by Date: Re: creating stand-alone extended tclsh
- Previous by thread: Re: creating stand-alone extended tclsh
- Next by thread: Re: creating stand-alone extended tclsh
- Index(es):