From xemacs-m  Sun Mar 23 09:47:08 1997
Received: from homer.sccon.com (homer.sccon.com [207.22.28.12])
	by xemacs.org (8.8.5/8.8.5) with SMTP id JAA06423
	for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 09:47:03 -0600 (CST)
From: andreas@sccon.com
Received: by homer.sccon.com (SMI-8.6/SMI-SVR4)
	id KAA10353; Sun, 23 Mar 1997 10:44:03 -0500
Date: Sun, 23 Mar 1997 10:44:03 -0500
Message-Id: <199703231544.KAA10353@homer.sccon.com>
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: <m2913f8ga6.fsf@altair.xemacs.org>
References: <m2913f8ga6.fsf@altair.xemacs.org>
X-Mailer: VM 6.21 under 20.1 XEmacs Lucid (beta9)
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

    Steven> [I'm shameless cribbing from Chuck's June 20th, 1996
    Steven> posting, new text other than substituting 14 with 15, is
    Steven> marked]

    Steven> I'm putting out a call for binary kit builders for 19.15.
    Steven> I've already gotten some volunteers for Linux, a
    Steven> non-Martin volunteer for Solaris 2.5, and DEC.  I'll post
    Steven> a roster and a list of what kits need to be built once the
    Steven> personnel is decided.  I'm relaxing the time line on when
    Steven> the kits need to be in place on the ftp site.  The
    Steven> schedule looks like:

i volunteer for solaris 2.5.1 using gcc... i can also create a package 
so that it can be added via the solaris pkgadd command is someone
would like me to...

cheers,
andreas
--
Steller Computer Consultants 	    Andreas Kaempf
       P.O. BOX 3873	             603-595-7461
   Nashua, NH 03062  USA	   andreas@sccon.com
.....................................................
Fragen Sie nicht, was Ihr Computer fuer Sie tun kann.
Fragen Sie, was Sie fuer Ihren Computer tun koennen.



    Steven> Sunday, March 23 -- beta 104 (final beta)

    Steven> Tuesday, March 25 -- 19.15 prerelease <Some Binary Kit
    Steven> building> Thursday, March 27 -- Net announcement

    Steven> If I've screwed something up, please let me know.  Many of
    Steven> you know more about binary kit building than I do.

    Steven> Instructions for kit building are as follows.

    Steven> The optimal binary kit would be built as such:

    Steven> 	--with-menubars=lucid --with-scrollbars=lucid
    Steven> --with-dialogs=motif if you have Motif --with-xpm
    Steven> important - please use xpm 3.4h --with-xface
    Steven> --with-tooltalk if you've got it --with-sound=native if
    Steven> your system has it --with-sound=both if you've got
    Steven> netaudio (else don't sweat it) --with-gif --with-png
    Steven> --with-jpeg --with-dbm if you've got it

    Steven> Compile with the highest level of optimization you feel
    Steven> comfortable with.

    Steven> <sbNEW> Please avoid the -fast Solaris option.  </sbNEW>

    Steven> <Ben Wing Added> Also make sure *NOT* to strip the binary.
    Steven> A stack backtrace should at least show the names of the
    Steven> functions on the stack (the default behavior without -g, I
    Steven> think).  </Ben Wing Added>

    Steven> If you don't have Motif then build with Athena dialogs
    Steven> instead.  Do not change the menubar or scrollbar toolkit
    Steven> without talking to me first.

    Steven> <sbNEW> I'm less in favor of requiring Motif than Chuck
    Steven> was due to my very disappointing experiences with it.  I'd
    Steven> prefer to see the dynamic Linux Motif build use Lesstif
    Steven> not Motif on general principles, but won't require it.
    Steven> </sbNEW>

    Steven> I'm relaxing the static!, static!, static! rule somewhat.
    Steven> Any standard system library may be dynamically linked.
    Steven> Any library which might not be installed on a system MUST
    Steven> be statically linked.  Let me repeat that.  ANY library
    Steven> which might not be installed on a system MUST be
    Steven> statically linked.

    Steven> Basically if a library doesn't get installed when doing
    Steven> the most minimal install of the OS, or if there is quite a
    Steven> bit of variation between installations of the OS
    Steven> (e.g. Linux) then you should be linking statically.

    Steven> Libraries which should definitely be statically linked
    Steven> include:

    Steven> 	XPM compface Motif JPEG PNG

    Steven> <Ben Wing Added> Given the size of Motif, I'd almost think
    Steven> it useful to have two binaries -- one statically linked
    Steven> with Motif, the other dynamically linked with Motif.  This
    Steven> is how the Linux Java JDK is distributed, for example.

    Steven> Also, ncurses and the db libraries should probably be
    Steven> statically linked.

    Steven> Also, if you do link dynamically, try VERY VERY hard to
    Steven> link against the oldest possible versions of the
    Steven> libraries.

    Steven> <sbNEW> I'm relaxing that requirement on Linux.  It should
    Steven> be linked against libc-5.4, and if someone can suggest a
    Steven> way to make it print out an `Upgrade your insecure/buggy
    Steven> libc' message before dropping core on an earlier version
    Steven> I'm open to suggestions.  </sbNEW>

    Steven> Also, on Linux, I would strongly consider statically
    Steven> linking with libc and libm, although dynamically linking
    Steven> with the standard X libraries is probably OK.  Remember
    Steven> the _h_errno SNAFU in 19.13.

    Steven> <sbNEW> This is not a good idea, unfortunately.  We will
    Steven> have the _h_errno SNAFU until we cease support of Linux
    Steven> libc 5.  </sbNEW>

    Steven> </Ben Wing Added>

    Steven> If you use something like Athena3d, that's fine, but make
    Steven> sure the thing is statically linked.

    Steven> <sbNEW> I'd encourage this, actually.  </sbNEW>

    Steven> Do your builds with

    Steven> 	USRLOCAL=/usr/local CONFIG=`./config.guess`

    Steven> 	./configure $CONFIG \ --prefix=$USRLOCAL \
    Steven> --bindir=$USRLOCAL/bin/$CONFIG

    Steven> $USRLOCAL can be anything you want, it doesn't matter -
    Steven> all the pathnames will be relative to that by the time I
    Steven> see them.

    Steven> Use ldd or your system equivalent on all of the
    Steven> executables (xemacs itself, and the lib-src executables)
    Steven> to verify that they are linked the way you think they are
    Steven> linked.

    Steven> The tar file you send me should then contain a README, and
    Steven> two directories: bin/$CONFIG/ and
    Steven> lib/xemacs-19.15/$CONFIG/, which should contain no more
    Steven> (and no less) <sbNEW>unless I goofed</sbNEW> than the
    Steven> following files:

    Steven> 	README.$CONFIG Installation bin/$CONFIG/
    Steven> bin/$CONFIG/b2m bin/$CONFIG/ctags bin/$CONFIG/emacsclient
    Steven> bin/$CONFIG/etags bin/$CONFIG/gnuattach
    Steven> bin/$CONFIG/gnuclient bin/$CONFIG/gnudoit
    Steven> bin/$CONFIG/pstogif bin/$CONFIG/rcs-checkin
    Steven> bin/$CONFIG/xemacs symbolic link to xemacs-19.15
    Steven> bin/$CONFIG/xemacs-19.15 lib/xemacs-19.15/$CONFIG/
    Steven> lib/xemacs-19.15/$CONFIG/DOC-19.15-XEmacs
    Steven> lib/xemacs-19.15/$CONFIG/cvtmail
    Steven> lib/xemacs-19.15/$CONFIG/digest-doc
    Steven> lib/xemacs-19.15/$CONFIG/emacsserver
    Steven> lib/xemacs-19.15/$CONFIG/fakemail
    Steven> lib/xemacs-19.15/$CONFIG/gnuserv
    Steven> lib/xemacs-19.15/$CONFIG/hexl
    Steven> lib/xemacs-19.15/$CONFIG/make-docfile
    Steven> lib/xemacs-19.15/$CONFIG/make-path
    Steven> lib/xemacs-19.15/$CONFIG/mmencode
    Steven> lib/xemacs-19.15/$CONFIG/movemail
    Steven> lib/xemacs-19.15/$CONFIG/profile
    Steven> lib/xemacs-19.15/$CONFIG/rcs2log
    Steven> lib/xemacs-19.15/$CONFIG/sorted-doc
    Steven> lib/xemacs-19.15/$CONFIG/tm-au
    Steven> lib/xemacs-19.15/$CONFIG/tm-file
    Steven> lib/xemacs-19.15/$CONFIG/tm-html
    Steven> lib/xemacs-19.15/$CONFIG/tm-image
    Steven> lib/xemacs-19.15/$CONFIG/tm-mpeg
    Steven> lib/xemacs-19.15/$CONFIG/tm-plain
    Steven> lib/xemacs-19.15/$CONFIG/tm-ps
    Steven> lib/xemacs-19.15/$CONFIG/tmdecode
    Steven> lib/xemacs-19.15/$CONFIG/vcdiff
    Steven> lib/xemacs-19.15/$CONFIG/wakeup
    Steven> lib/xemacs-19.15/$CONFIG/yow


    Steven> This is the directory setup that you will get if you just
    Steven> do "make install".

    Steven> I am actually a little bit picky about file permissions
    Steven> and ownership in this file, but don't worry too much. I
    Steven> repack all distributions before I put them on the ftp
    Steven> site.

    Steven> What follows is a sample README.$CONFIG.  Your READMEs
    Steven> should look approximately like this, with appropriate
    Steven> query-replace results.  However, do mention anything else
    Steven> you think needs to be mentioned.

    Steven> And of course, attempt an installation as described in the
    Steven> README, on a different machine if possible.

    Steven> When you're done, dump them in
    Steven> ftp.xemacs.org:/pub/beta/incoming/.  Please also put there
    Steven> the config.status file you used to build the kit.

    Steven> <sbNEW> Please add a file called Installation which
    Steven> contains the command line used to build the binary, and
    Steven> the summary output of configure, exactly as documented in
    Steven> etc/BETA.  </sbNEW> Thanks!

    Steven> ------------------------------------------------------------------------------

    Steven> This directory contains Solaris 2.4 executables for XEmacs
    Steven> 19.15.  These were compiled with Motif, XPM, X-Face,
    Steven> ToolTalk, PNG, GIF, JPG, DBM, full optimization, and have
    Steven> system libraries dynamically linked and all others
    Steven> statically linked.

    Steven> Built by Chuck Thompson <cthomp@xemacs.org>

    Steven> The tar file which contains these executables contains
    Steven> only the executables (the architecture-dependent files.)
    Steven> To use these executables, you will also need the
    Steven> architecture-independent files (the `lisp', `etc' and
    Steven> `info' directories.)  These files are distributed in a
    Steven> seperate file (xemacs-19.15-common.tar.gz.)

    Steven> HOW TO INSTALL ==============

    Steven> Simply cd to the directory in which you wish to install
    Steven> xemacs, and then unpack the architecture independent tar
    Steven> file, followed by the architecture-dependent files for
    Steven> those architectures you use.

    Steven>   cd /usr/local/ # or wherever you install 3rd-party
    Steven> software gzip -dc xemacs-19.15-common.tar.gz | tar -pxf -
    Steven> gzip -dc xemacs-19.15-sparc-sun-solaris2.4.tar.gz | tar
    Steven> -pxf -

    Steven> Replace `/usr/local/' with what you like, but it probably
    Steven> ought not have `xemacs' or a version number in it - that
    Steven> directory is expected to be the common prefix for
    Steven> installed software, and xemacs-specific subdirectories of
    Steven> it will be created.  The directories are arranged in such
    Steven> a way that multiple versions of xemacs can peaceably
    Steven> coexist under the same `/usr/local/' tree.

    Steven> After unpacking, you will have a directory structure like:

    Steven>   ./bin/sparc-sun-solaris2.4/xemacs-19.15* executable
    Steven> ./lib/xemacs-19.15/lisp/ lisp library
    Steven> ./lib/xemacs-19.15/etc/ data directory
    Steven> ./lib/xemacs-19.15/info/ documentation
    Steven> ./lib/xemacs-19.15/sparc-sun-solaris2.4/ utility programs
    Steven> ./lib/xemacs/lock/ lock directory ./lib/xemacs/site-lisp/
    Steven> local lisp code

    Steven> For the executable to work, the directory layout must look
    Steven> pretty much like this; the executable looks for "sibling"
    Steven> directories at run-time to figure out where its lisp
    Steven> library is.  These constraints on the local directory
    Steven> layout are necessary to avoid having to hardcode pathnames
    Steven> into the executables, or require that environment
    Steven> variables be set before running the executable.

    Steven> It is possible to do a multi-architecture in such a way
    Steven> that the executables for the various architectures are on
    Steven> different partitions; in that case you must install some
    Steven> symbolic links so that the directory structure appears as
    Steven> above from the clients.

    Steven> For example, assume that $LOCAL refers to a directory
    Steven> which is mounted only on machines of the same type; and
    Steven> $SHARED refers to a directory which is shared among all
    Steven> machines.  You could set up the directory hierarchy like
    Steven> this:

    Steven>   $LOCAL/bin/xemacs-19.15*
    Steven> $LOCAL/lib/xemacs-19.15/sparc-sun-solaris2.4/
    Steven> $LOCAL/lib/xemacs-19.15/lisp@ ->
    Steven> $SHARED/xemacs-19.15/lisp/ $LOCAL/lib/xemacs-19.15/etc@ ->
    Steven> $SHARED/xemacs-19.15/etc/ $LOCAL/lib/xemacs-19.15/info@ ->
    Steven> $SHARED/xemacs-19.15/info/ $LOCAL/lib/xemacs@ ->
    Steven> $SHARED/xemacs/

    Steven>   $SHARED/xemacs-19.15/lisp/ $SHARED/xemacs-19.15/etc/
    Steven> $SHARED/xemacs-19.15/info/ $SHARED/xemacs/lock/
    Steven> $SHARED/xemacs/site-lisp/

    Steven> That is, the various $SHARED directories contain only the
    Steven> architecture-independent files, but still look like normal
    Steven> installation trees, since the architecture-independent
    Steven> directories have been replaced with symbolic links to the
    Steven> single $COMMON tree.


    Steven> -- steve@miranova.com baur Unsolicited commercial e-mail
    Steven> will be billed at $250/message.

