XEmacs Binary Kit HOWTO, V21.1 :::::::::::::: INTRODUCTION :::::::::::::: These instructions are meant to assist XEmacs developers in the preparation of precompiled XEmacs binary-kits. If you plan on building a binary-kit for the XEmacs project, please join the xemacs-binary-kits mailing list. This is a seasonal, low volume list for discussion among XEmacs binary-kit builders, and announcements from the binary-kit coordinator. To subscribe to xemacs-binary-kits, send an email message to with `subscribe' as the BODY of the message. Also, please take the time to read this file in its entirety before starting to prepare your binary-kit. If the binary-kit you prepare doesn't conform to the guidelines herein, you will be kindly asked to redo it. If you have questions about anything, please ask on the mailing list. :::::::::::::: NEWS :::::::::::::: Several things about the XEmacs binary-kit preparation process have changed since the 20.4 release. For prior versions of the binary-kits, architecture-independent tar files containing the `lisp', `etc' and `info' directories were distributed along with the architecture-dependent tar file containing the executables. These "common" files have been done away with to allow for a simpler binary-kit installation in the face of the new package system. As of this release, core lisp, executables as well as the man, etc, and info directories will be distributed together in one tarball. This means one will only have to download at most a total of two or three tarballs to install a binary-kit. One tarball for the particular architecture, one tarball for the regular Sumo-lisp, and (optionally) one tarball for MULE. :::::::::::::: BUILDING :::::::::::::: The procedures for building a MULE-enabled and a non-mule-enabled XEmacs binary-kit differ slightly. Please take careful note of the differences. Latin-1 binary kits (non-MULE) ============================== Do your builds with: CONFIG=`./config.guess` % ./configure $CONFIG --prefix=/usr/local --bindir=/usr/local/bin/$CONFIG If you need to install somewhere other than /usr/local, set USRLOCAL to your preferred local installation directory and run: % make prefix=$USRLOCAL bindir=$USRLOCAL/bin/$CONFIG install The optimal Latin-1 binary kit would be built with at least the following options to configure: --with-menubars=lucid --with-scrollbars=lucid --with-dialogs=motif if you have Motif --with-xpm --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-tiff if you've got it --with-database=dbm if you've got it --with-cde if you've got it MULE binary kits ================ For MULE-enabled binary-kits, Do your builds with: CONFIG=`./config.guess` % ./configure $CONFIG --prefix=/usr/local --bindir=/usr/local/bin/$CONFIG-mule If you need to install somewhere other than /usr/local, set USRLOCAL to your preferred local installation directory and run: % make prefix=$USRLOCAL bindir=$USRLOCAL/bin/$CONFIG-mule install The optimal MULE binary kit would be built with the same options to configure as the Latin-1 binary kit options shown above, but _in addition_ add the following options: --with-mule=yes --with-cde=no --with-wnn if you've got it --with-canna if you've got it and possibly --with-wnn6 see below If you build with Motif you automatically get XIM. Wnn4 is somewhat of a pain to build so for this first go around if you can't get it built don't sweat it. If you build with Canna, make sure it is 3.2 and not 3.5beta as per the wishes of the developers. Wnn4 and Wnn6 are mutually exclusive -- you can't put both in the same XEmacs. There have been reports of running a MULE binary with Canna and Wnn4/Wnn6 for nearly a near without problems. The Wnn6 SDK is at ftp://ftp-sp.omronsoft.co.jp/pub/Wnn6/sdk/ This consists of a static library and header files. Canna and Wnn can safely coexist in one binary. Canna, Wnn4.2/Wnn6 and XIM=xlib have been tested in a single binary without difficulty. Note that on Linux the Wnn6 library from Omron definitely works when XEmacs is linked against glibc2. XIM=xlib has been tested with kinput2 as the XIM server and works. We recommend building `--with-xfs=yes' if either your C library supports localization, or your X11 libraries were built with X_LOCALE defined. ALL binary-kits (both MULE and non-MULE) ======================================== * Compile with the highest level of optimization you feel comfortable * with. * Please avoid the `-fast' SunPro compiler option on Solaris. * We recommend not using GCC if you don't have to. Better seems to be * EGCS, the successor to GCC. We have not tested pgcc built binaries * on anything other than a Pentium, nor are we aware of anyone else * who has. So we recommend avoiding pgcc even for ix86 Linux/BSD. * 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). * If you don't have Motif then build with Athena dialogs instead. Do * not change the menubar or scrollbar toolkit without mentioning * something first. * We are taking a harder stance on dynamic kits for this release. * They appear to have given us far more grief than benefit. Remember, * the idea on the kits is not that they are the preferred way to use * XEmacs, but that they are the path-of-least-effort and should work * everywhere. Think static!, static!, static! before building a * binary kit. At minimum, 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/z TIFF Canna/RKC Wnn4 Wnn6 * Also, ncurses and the db libraries should probably be statically linked. * If you do link dynamically, try VERY VERY hard to link against the * oldest possible versions of the libraries. * If you use something like Athena3d, that's fine, but make sure the * thing is statically linked. * Use the "ldd" command 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. :::::::::::::: READMEs :::::::::::::: Before you archive the contents of the install directory, you should add a README file to the top level directory. The README file that you include should be named: README.$CONFIG (for Latin-1 kits) README.$CONFIG-mule (for MULE kits) Two example READMEs are included in the same directory as this file: `README.i686-pc-linux' and `README.i686-pc-linux-mule'. Your README should look approximately like these, with appropriate query-replace results. However, do mention anything else you think needs to be mentioned. :::::::::::::: PACKAGING :::::::::::::: Now go ahead and package up your binary-kit. Your gzipped tar file should be named: xemacs-21.1.3-$CONFIG.tar.gz (for Latin-1 kits) xemacs-21.1.3-$CONFIG-mule.tar.gz (for MULE kits) For example, where $CONFIG is `i686-pc-linux': xemacs-21.1.3-i686-pc-linux.tar.gz xemacs-21.1.3-i686-pc-linux-mule.tar.gz Their top level directory structure should look similar to the following: README.$CONFIG (README.$CONFIG-mule for MULE kits) bin/$CONFIG (bin/$CONFIG-mule for MULE kits) lib/xemacs-21.1-p3/ lib/xemacs-21.1-p3/etc lib/xemacs-21.1-p3/lisp lib/xemacs-21.1-p3/info lib/xemacs-21.1-p3/$CONFIG lib/xemacs lib/xemacs/lock man/man1 This is essentially the directory setup that you will get when you do a "make install". :::::::::::::: TESTING :::::::::::::: Once you have created your packaged binary-kit, please attempt an installation as described in your README as if you were an end user. Please try this on a different different machine if at all possible to verify portability. :::::::::::::: UPLOADING :::::::::::::: When you're done, please upload the following THREE items into: ftp://ftp.xemacs.org/pub/xemacs/beta/incoming/binary-kits/ 1. Your tarred, gzipped binary kit. 2. The "Installation" file that was created during the build. 3. A copy of your README.$CONFIG (or README.$CONFIG-mule). NOTE: When uploading binary kits, you will need to login to ftp.xemacs.org with the FTP username `xemacs', password `zawinski' (not anonymous!) in order to write to the binary-kits directory. Once logged in, cd to /pub/xemacs/beta/incoming/binary-kits/ and start the upload. Finally, please send a message to letting me know what you dropped off so your kit can be processed. Thank-you for your contribution! -- kit-manager@xemacs.org