From xemacs-m  Sun Mar 23 13:16:02 1997
Received: from xemacs.cs.uiuc.edu (localhost [127.0.0.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id NAA08399;
	Sun, 23 Mar 1997 13:16:01 -0600 (CST)
Message-Id: <199703231916.NAA08399@xemacs.org>
To: Steven L Baur <steve@miranova.com>
cc: xemacs-beta@xemacs.org
Subject: Re: 19.15 Binary kit build instructions, call for builders 
In-reply-to: Your message of "22 Mar 1997 21:52:37 PST."
             <m2ybbfm9y2.fsf@altair.xemacs.org> 
Date: Sun, 23 Mar 1997 13:16:01 -0600
From: Chuck Thompson <cthomp@xemacs.org>

    >> Maybe it's my memory that's bad, but it seems to me every time
    >> we've tried this, there have been blowups reported.  We're
    >> shooting for turnkey operation with the binaries, so why risk
    >> it?  I can still hear Jamie laughing.

    sb> I've only been through the 19.14 release process.  Should they
    sb> be 100% static?  Lead me.  The worrisome problem I have with
    sb> 100% static executables is the impossibility of dealing with
    sb> system security patches.  I suppose we can always update the
    sb> stuff on ftp.xemacs.org if something really bad like the
    sb> recent BSD locale bug crops up again.


The reason I relaxed the static linking of standard system libraries
is because that was actually causing some problems.  Also, on some
systems (Solaris for example) it is virtually impossible to build a
100% statically linked binary.

The reason for requiring static linking of other libraries such as xpm
is twofold.  First, it has been well established that XEmacs can be
overly sensitive to different revisions of the same library.  Second,
we don't want to force people to go and install XPM, JPEG, and a host
of other libraries just to be able to run the pre-built binaries.



			-Chuck

