From xemacs-m  Sat Mar 22 20:47:50 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id UAA02198
	for <xemacs-beta@xemacs.org>; Sat, 22 Mar 1997 20:47:49 -0600 (CST)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.5/8.8.5) id SAA10160;
	Sat, 22 Mar 1997 18:59:30 -0800
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: 19.15 Binary kit build instructions, call for builders
X-Url: http://www.miranova.com/%7Esteve/
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
X-Attribution: sb
From: Steven L Baur <steve@miranova.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Date: 22 Mar 1997 18:59:29 -0800
Message-ID: <m2913f8ga6.fsf@altair.xemacs.org>
Lines: 283
X-Mailer: Gnus v5.4.34/XEmacs 20.1(beta10)

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

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

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

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

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

Instructions for kit building are as follows.

The optimal binary kit would be built as such:

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

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

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

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

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

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

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

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

Libraries which should definitely be statically linked include:

	XPM
	compface
	Motif
	JPEG
	PNG

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

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

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

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

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

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

</Ben Wing Added>

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

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

Do your builds with

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

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

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

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

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

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


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

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

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

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

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

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

------------------------------------------------------------------------------

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

Built by Chuck Thompson <cthomp@xemacs.org>

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

HOW TO INSTALL
==============

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

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

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

After unpacking, you will have a directory structure like:

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

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

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

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

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

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

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


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

