Re: creating stand-alone extended tclsh

Hi,

Gerald W. Lester wrote:
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.

Tcl is a very flexible language, and people have very different experiences with it, under very different contexts. I don't know what "most of us" believe, but I know my own experience makes me believe both static and dynamic approaches have their "pros" and "cons", and I favour either according to curcumstances.

You're right, more Tclers enjoy flexibility offered by dynamically loading extensions, and this is probably good (if not best) way to go when running on a single machine (or homogeneous environment). But when it comes to software deployment to multiple, heterogeneous systems, statically linked binaries offer very significant advantages.

When you have been faced once to a customer/user reporting a problem you can't reproduce, and you finally find, after a long and hard investigation since you don't have access to his machine, that this is due to some unstable (or just different) shared library which has leaked in his system, experience tells you static linking has its "pros" :-)

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

I fully agree, but this can actually also be considered a "cons" under some circumnstances.

From a quality assurance and release management point of view, you can't be assured that executable tested on the developer’s machine will run unadulterated on the target machine. Even worst, your runtime may work fine for monthes or years before getting suddenly broken by some unrelated install which will put some interfering DLL on your system, or because sysadmins has decided to upgrade some parts of the O.S. on the production environment.

On the opposite, static linking offers:
- a simple solution to tag executables, manage versionning and Q-A certification
- deployment is trivial (I especially enjoy this when "installing" on embedded systems like set-top boxes or routers: copy a single file in flash, run, that's all!)
- rollbacks are made easy
- if different services require different configurations, they can coexist on system without interfering

Last, static executable doesn't mean "load" has to be disabled, so with some care, Tcl can offer best of the 2 worlds. For example, since eTcl is distributed as a static executable, all embedded (and officially supported) extensions should behave the same no matter which distribution you are running, and which version of libpng, libopenssl, libsqlite, etc... you have (or haven't) installed on your system. But it's still possible to load TEA compliant extensions the standard way, to extend and customize it the way you want.

To conclude, *my* experience tells me I love Tcl for supporting easily both static and dynamic approaaches, and letting me decide on a daily basis which one better fits my needs for a given project or context.

Eric

-----
Eric Hassold
Evolane - http://www.evolane.com/
.

Relevant Pages

  • RE: File extensions spoofable in MSIE download dialog
    ... File extensions spoofable in MSIE download dialog ... allows executables to run as soon as a user has elected to open what ... provided in the link over the filename suggested by the header's filename ... Here is the ASP equivalent code to StatiC's php tidbit (tested under both ...
    (Bugtraq)
  • Re: Freewap issues
    ... > I managed to get freewrap to work on Windows XP and created a single ... > file executable of multiple TCL files and some image files .. ... Zip depends on this "tail" to determine how the rest of the file ... since zip ignores data appended in FRONT of it, and executables ...
    (comp.lang.tcl)
  • Re: Tcl on Google Android phones
    ... 'The Jacl executable is 200 MB big, and Android has a executable ... writes the user's files via a socket based mechanism. ... This should also be buildable / testable using pure Tcl and components ... unless that if for all executables combined. ...
    (comp.lang.tcl)
  • Re: New Application Extension reports 404
    ... Substatus code for these 404 requests - that will help diagnose the problem. ... > This is VERY SIMULAR to a WORKING perl script extension of: ... > Thanks in advance for help on these extensions. ... > executables from the IIS4 server.) ...
    (microsoft.public.inetserver.iis)
  • Re: making stand-alone Tcl app for QNX4
    ... >> I would like to convert a Tcl application into a stand-alone ... I've created stand-alone executables for ... >> QNX4, so I am looking for a solution I can compile on the target platform. ... It is just Tcl ...
    (comp.lang.tcl)