diff --git a/handbook/authors.sgml b/handbook/authors.sgml index a8f9b5b001..cbaea268f2 100644 --- a/handbook/authors.sgml +++ b/handbook/authors.sgml @@ -1,424 +1,424 @@ "> "> "> "> "> "> "> "> "> -"> -"> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> diff --git a/handbook/contrib.sgml b/handbook/contrib.sgml index 6c4c5badc3..85837cfeb5 100644 --- a/handbook/contrib.sgml +++ b/handbook/contrib.sgml @@ -1,497 +1,497 @@ FreeBSD Project Staff

The FreeBSD Project is managed and operated by the following groups of people: The FreeBSD core team

The FreeBSD core team constitutes the project's ``Board of Directors'', responsible for deciding the project's overall goals and direction as well as managing of the FreeBSD project landscape.

(in alphabetical order by last name): &a.asami; &a.jmb; &a.ache; &a.dyson; &a.bde; &a.gibbs; &a.davidg; &a.jkh; &a.phk; &a.rich; &a.gpalmer; &a.jdp; &a.sos; &a.peter; &a.wollman; &a.joerg; The FreeBSD Developers

These are the people who have commit privileges and do the engineering work on the FreeBSD source tree. All core team members and most FreeBSD Documentation project personnel are also developers. &a.mbarkah; &a.torstenb; &a.gclarkii; &a.adam; &a.dufault; &a.uhclem; &a.sef; &a.julian; &a.se; &a.fenner; &a.jfieber; &a.jfitz; &a.lars; &a.scrappy; &a.tg; &a.graichen; &a.rgrimes; &a.jhay; &a.hsu; &a.ugen; &a.gj; &a.nsj; &a.ljo; &a.kato; &a.andreas; &a.erich; &a.imp; &a.smace; &a.mckay; &a.amurai; &a.markm; &a.max; &a.alex; &a.davidn; &a.obrien; &a.fsmp; &a.smpatel; &a.wpaul; &a.jmacd; &a.steve; &a.mpp; &a.dfr; &a.jraynard; &a.csgr; &a.martin; &a.paul; &a.roberto; &a.chuckr; &a.dima; &a.wosch; &a.ats; &a.msmith; - &a.briansomers; + &a.brian; &a.karl; &a.pst; &a.guido; &a.swallace; &a.nate; &a.jmz; The FreeBSD Documentation Project

The is responsible for a number of different services, each service being run by an individual and his deputies (if any):

Deputy: &a.paul Deputy: &a.dave Deputy: &a.john Deputy: &a.nsj; Deputy: &a.cawimm Deputy: &a.opsys Deputy: &a.cracauer Who is responsible for what

FreeBSD contributor list Derived software contributors

This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially re-implemented from the 4.4BSD-Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD for their work. Despite some occasionally rocky moments in relations between the two groups, we both want essentially the same thing: More BSD based operating systems on people's computers! We wish the NetBSD group every success in their endeavors. Hardware contributors

A special thank-you to Walnut Creek CDROM for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. It would have been impossible to do this release without their support. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. They also keep a couple of FreeBSD hackers alive and busy. Thanks! Thanks also to Dermot McDonnell for his donation of a Toshiba XM3401B CDROM drive. It has been most useful! Thanks to &a.chuck; who contributed his floppy tape streamer for experimental work. Thanks to Larry Altneu <larry@ALR.COM>, and to &a.wilko;, for providing us with a Wangtek and an Archive QIC-02 tape drive, in order to give us the hardware to improve the wt driver. Thanks go to Ernst Winter <ewinter@lobo.muc.de>, for contributing a 2.88 MB floppy drive to the project. Hopefully, this will increase the pressure for rewriting the floppy disk driver. ;-) Also see for a list of people who have donated funding or services to the FreeBSD Project. Additional FreeBSD contributors

(in alphabetical order by first name): A JOSEPH KOSHY <koshy@india.hp.com> ABURAYA Ryushirou <pcs51674@asciinet.or.jp> Adam Glass <glass@postgres.berkeley.edu> Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu> Akito Fujita <fujita@zoo.ncl.omron.co.jp> Alain Kalker <A.C.P.M.Kalker@student.utwente.nl> Alan Cox <alc@cs.rice.edu> Andreas Kohout <shanee@rabbit.augusta.de> Andreas Lohr <andreas@marvin.RoBIN.de> Andrew Gordon <andrew.gordon@net-tel.co.uk> Andrew Herbert <andrew@werple.apana.org.au> Andrew McRae <amcrae@cisco.com> Andrew Moore <alm@FreeBSD.org> Andrew Stevenson <andrew@ugh.net.au> Andrew V. Stesin <stesin@elvisti.kiev.ua> Andrey Zakhvatov <andy@cgu.chel.su> Andy Whitcroft <andy@sarc.city.ac.uk> Anthony Yee-Hang Chan <yeehang@netcom.com> Bernd Rosauer <br@schiele-ct.de> Bill Kish <kish@osf.org> &a.wlloyd Bob Wilcox <bob@obiwan.uucp> Boyd Faulkner <faulkner@mpd.tandem.com> Brent J. Nordquist <nordquist@platinum.com> Brian Clapper <bmc@willscreek.com> Brian Tao <taob@risc.org> Charles Hannum <mycroft@ai.mit.edu> Charles Mott <cmott@srv.net> Chet Ramey <chet@odin.INS.CWRU.Edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Stenton <jacs@gnome.co.uk> Chris Timmons <skynyrd@opus.cts.cwu.edu> Chris Torek <torek@ee.lbl.gov> Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> Christian Haury <Christian.Haury@sagem.fr> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Chuck Hein <chein@cisco.com> Conrad Sabatier <conrads@neosoft.com> Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> Craig Struble <cstruble@vt.edu> Cristian Ferretti <cfs@riemann.mat.puc.cl> Curt Mayer <curt@toad.com> Daniel Baker <dbaker@crash.ops.neosoft.com> Daniel M. Eischen <deischen@iworks.InterWorks.org> Danny J. Zerkel <dzerkel@feephi.phofarm.com> Dave Bodenstab <imdave@synet.net> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Chapeskie <dchapes@zeus.leitch.com> Dave Edmondson <davided@sco.com> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Leonard <d@scry.dstc.edu.au> Dean Huxley <dean@fsa.ca> Dirk Froemberg <dirk@hal.in-berlin.de> Dmitry Kohmanyuk <dk@farm.org> &a.whiteside; Don Yuniskis <dgy@rtd.com> Donald Burr <d_burr@ix.netcom.com> Doug Ambrisko <ambrisko@ambrisko.roble.com> Eric Blood <eblood@cs.unr.edu> Frank Bartels <knarf@camelot.de> Frank Maclachlan <fpm@crash.cts.com> Frank Nobis <fn@trinity.radio-do.de> FURUSAWA Kazuhisa <furusawa@com.cs.osakafu-u.ac.jp> Gary A. Browning <gab10@griffcd.amdahl.com> Gene Stark <stark@cs.sunysb.edu> Greg Ungerer <gerg@stallion.oz.au> Harlan Stenn <Harlan.Stenn@pfcs.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Hideaki Ohmon <ohmon@tom.sfc.keio.ac.jp> Hidekazu Kuroki <hidekazu@cs.titech.ac.jp> Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Holger Veit <Holger.Veit@gmd.de> Igor Vinokurov <igor@zynaps.ru> Ikuo Nakagawa <ikuo@isl.intec.co.jp> IMAMURA Tomoaki <tomoak-i@is.aist-nara.ac.jp> Ishii Masahiro <?> J.T. Conklin <jtc@cygnus.com> James Clark <jjc@jclark.com> James da Silva <jds@cs.umd.edu> et al Janusz Kokot <janek@gaja.ipan.lublin.pl> Jason Thorpe <thorpej@nas.nasa.gov> Javier Martin Rueda <jmrueda@diatel.upm.es> Jian-Da Li <jdli@csie.NCTU.edu.tw> Jim Lowe <james@cs.uwm.edu> Jim Wilson <wilson@moria.cygnus.com> Johann Tonsing <jtonsing@mikom.csir.co.za> John Capo <jc@irbs.com> John Perry <perry@vishnu.alias.net> John-Mark Gurney <gurney_j@efn.org> Juergen Lock <nox@jelal.hb.north.de> Juha Inkari <inkari@cc.hut.fi> Julian Assange <proff@suburbia.net> Julian Jenkins <kaveman@magna.com.au> Julian Stacey <jhs@freebsd.org> Kazuhiko Kiriyama <kiri@kiri.toba-cmt.ac.jp> Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Keith Moore <?> Kirk McKusick <mckusick@mckusick.com> Koichi Sato <copan@ppp.fastnet.or.jp> Kostya Lukin <lukin@okbmei.msk.su> Kurt Olsen <kurto@tiny.mcs.usu.edu> Lars Koeller <Lars_Koeller@odie.physik2.uni-rostock.de> Lucas James <Lucas.James@ldjpc.apana.org.au> Luigi Rizzo <luigi@iet.unipi.it> Manu Iyengar <iyengar@grunthos.pscwa.psca.com> Marc Frajola <marc@dev.com> Marc Ramirez <mrami@mramirez.sy.yale.edu Marc van Kempen <wmbfmk@urc.tue.nl> Mark Huizer <xaa@stack.nl> Mark J. Taylor <mtaylor@cybernet.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Birgmeier Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp> Mats Lofkvist <mal@algonet.se> Matt Bartley <mbartley@lear35.cytex.com> Matt Thomas <thomas@lkg.dec.com> Matt White <mwhite+@CMU.EDU> Matthew N. Dodd <winter@jurai.net> Matthew Stein <matt@bdd.net> Michael Butschky <butsch@computi.erols.com> Michael Elbel <me@FreeBSD.ORG> Michael Searle <searle@longacre.demon.co.uk> Miguel Angel Sagreras <msagre@cactus.fi.uba.ar> Mikael Hybsch <micke@dynas.se> Mikhail Teterin <mi@aldan.ziplink.net> Mike McGaughey <mmcg@cs.monash.edu.au> Mike Peck <mike@binghamton.edu> MITA Yoshio <mita@jp.FreeBSD.ORG> MOROHOSHI Akihiko <moro@race.u-tokyo.ac.jp> Naoki Hamada <nao@tom-yam.or.jp> NIIMI Satoshi <sa2c@and.or.jp> Nick Sayer <nsayer@quack.kfu.com> Nisha Talagala <nisha@cs.berkeley.edu> Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> Noritaka Ishizumi <graphite@taurus.bekkoame.or.jp> Oliver Oberdorf <oly@world.std.com> Paul Fox <pgf@foxharp.boston.ma.us> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Pedro Giffuni <pgiffuni@fps.biblos.unal.edu.co> Peter Stubbs <PETERS@staidan.qld.edu.au> Philippe Charnier <charnier@lirmm.fr> R. Kym Horsell <?> Randall Hopper <rhh@stealth.ct.picker.com> Richard Stallman <rms@gnu.ai.mit.edu> Richard Wiwatowski <rjwiwat@adelaide.on.neti> Rob Mallory <rmallory@csusb.edu> Rob Shady <rls@id.net> Rob Snow <rsnow@txdirect.net> Robert Sanders <rsanders@mindspring.com> Robert Withrow <witr@rwwa.com> Ronald Kuehn <kuehn@rz.tu-clausthal.de> Sander Vesik <sander@haldjas.folklore.ee> Sandro Sigala <ssigala@globalnet.it> Sascha Blank <blank@fox.uni-trier.de> Sascha Wildner <swildner@channelz.GUN.de> Scott Blachowicz <scott@sabami.seaslug.org> Serge V. Vakulenko <vak@zebub.msk.su> Simon Marlow <simonm@dcs.gla.ac.uk> Soren Dayton <csdayton@midway.uchicago.edu> Stefan Moeding <moeding@bn.DeTeMobil.de> Steve Gerakines <steve2@genesis.tiac.net> Suzuki Yoshiaki <zensyo@ann.tama.kawasaki.jp> Tadashi Kumano <kumano@strl.nhk.or.jp> Taguchi Takeshi <taguchi@tohoku.iij.ad.jp> Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> Terry Lambert <terry@lambert.org> Terry Lee <terry@uivlsi.csl.uiuc.edu> Theo Deraadt <deraadt@fsa.ca> Thomas König <Thomas.Koenig@ciw.uni-karlsruhe.de> Tim Kientzle <kientzle@netcom.com> Tim Vanderhoek <ac199@freenet.hamilton.on.ca> Tom Samplonius <tom@misery.sdf.com> Torbjorn Granlund <tege@matematik.su.se> Tor Egge <tegge@itea.ntnu.no> Toshihiro Kanda <candy@fct.kgc.co.jp> Ville Eerola <ve@sci.fi> Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> Wes Santee <wsantee@wsantee.oz.net> Wolfgang Stanglmeier <wolf@kintaro.cologne.de> Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp> Yukihiro Nakai <nakai@mlab.t.u-tokyo.ac.jp> Yuval Yarom <yval@cs.huji.ac.il> Yves Fonk <yves@cpcoup5.tn.tudelft.nl> 386BSD Patch kit patch contributors

(in alphabetical order by first name): Adam Glass <glass@postgres.berkeley.edu> Adrian Hall <adrian@ibmpcug.co.uk> Andrey A. Chernov <ache@astral.msk.su> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@netcom.com> Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> Arne Henrik Juul <arnej@Lise.Unit.NO> Bakul Shah <bvs@bitblocks.com> Barry Lustig <barry@ictv.com> Bob Wilcox <bob@obiwan.uucp> Branko Lankester Brett Lymn <blymn@mulga.awadi.com.AU> Charles Hannum <mycroft@ai.mit.edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Torek <torek@ee.lbl.gov> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Daniel Poirot <poirot@aio.jsc.nasa.gov> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Greenman <davidg@Root.COM> Eric J. Haug <ejh@slustl.slu.edu> Felix Gaehtgens <felix@escape.vsse.in-berlin.de> Frank Maclachlan <fpm@crash.cts.com> Gary A. Browning <gab10@griffcd.amdahl.com> Geoff Rehmet <csgr@alpha.ru.ac.za> Goran Hammarback <goran@astro.uu.se> Guido van Rooij <guido@gvr.win.tue.nl> Guy Harris <guy@auspex.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Herb Peyerl <hpeyerl@novatel.cuc.ab.ca Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@cygnus.com> Jagane D Sundar < jagane@netcom.com > James Clark <jjc@jclark.com> James Jegers <jimj@miller.cs.uwm.edu> James W. Dolter James da Silva <jds@cs.umd.edu> et al Jay Fenlason <hack@datacube.com> Jim Wilson <wilson@moria.cygnus.com> Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de> Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> John Dyson - <formerly dyson@ref.tfs.com> John Polstra <jdp@polstra.com> John Woods <jfw@eddie.mit.edu> Jordan K. Hubbard <jkh@whisker.hubbard.ie> Julian Elischer <julian@dialix.oz.au> Julian Stacey <jhs@freebsd.org> Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Ken Hughes Kent Talarico <kent@shipwreck.tsoft.net> Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu> Marc Frajola <marc@dev.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Renters <martin@tdc.on.ca> Michael Clay <mclay@weareb.org> Michael Galassi <nerd@percival.rain.com> Mike Durkin <mdurkin@tsoft.sf-bay.org> Naoki Hamada <nao@tom-yam.or.jp> Nate Williams <nate@bsd.coe.montana.edu> Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> Pace Willisson <pace@blitz.com> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Popelka <paulp@uts.amdahl.com> Peter da Silva <peter@NeoSoft.com> Phil Sutherland <philsuth@mycroft.dialix.oz.au> Poul-Henning Kamp<phk@FreeBSD.ORG> Ralf Friedl <friedl@informatik.uni-kl.de> Rick Macklem <root@snowhite.cis.uoguelph.ca> Robert D. Thrush <rd@phoenix.aii.com> Rodney W. Grimes <rgrimes@cdrom.com> Rog Egge <?> Sascha Wildner <swildner@channelz.GUN.de> Scott Burris <scott@pita.cns.ucla.edu> Scott Reynolds <scott@clmqt.marquette.mi.us> Sean Eric Fagan <sef@kithrup.com> Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au> Stephen McKay <syssgm@devetir.qld.gov.au> Terry Lambert <terry@icarus.weber.edu> Terry Lee <terry@uivlsi.csl.uiuc.edu> Warren Toomey <wkt@csadfa.cs.adfa.oz.au> Wiljo Heinen <wiljo@freeside.ki.open.de> William Jolitz <withheld> Wolfgang Solfrank <ws@tools.de> Wolfgang Stanglmeier <wolf@dentaro.GUN.de> Yuval Yarom <yval@cs.huji.ac.il> diff --git a/handbook/linuxemu.sgml b/handbook/linuxemu.sgml index b7306673ff..543f9a9694 100644 --- a/handbook/linuxemu.sgml +++ b/handbook/linuxemu.sgml @@ -1,700 +1,700 @@ Linux Emulation -

Contributed by &a.brian and &a.rich; +

Contributed by &a.handy and &a.rich; How to install the Linux emulator

Linux emulation in FreeBSD has reached a point where it is possible to run a large fraction of Linux binaries in both a.out and ELF format. The linux emulation in the -STABLE branch is capable of running Linux DOOM and Mathematica; the version present in FreeBSD-CURRENT is vastly more capable and runs all these as well as Quake, Abuse, IDL, netrek for Linux and a whole host of other programs. There are some Linux-specific operating system features that are not supported on FreeBSD. Linux binaries will not work on FreeBSD if they use the Linux /proc filesystem (which is different from the optional FreeBSD /proc filesystem) or i386-specific calls, such as enabling virtual 8086 mode.

To tell whether your kernel is configured for Linux compatibility simply run any Linux binary. If it prints the error message linux-executable: Exec format error. Wrong Architecture. then you do not have linux compatibility support and you need to configure and install a new kernel. Depending on which version of FreeBSD you are running, how you get Linux-emulation up will vary slightly: Installing Linux Emulation in 2.1-STABLE

The GENERIC kernel in 2.1-stable is not configured for linux compatibility so you must reconfigure your kernel for it. There are two ways to do this: 1. linking the emulator statically in the kernel itself and 2. configuring your kernel to dynamically load the linux loadable kernel module (LKM).

To enable the emulator, add the following to your configuration file (c.f. /sys/i386/conf/LINT): options COMPAT_LINUX If you want to run doom or other applications that need shared memory also add the following. options SYSVSHM The linux system calls require 4.3BSD system call compatibility. So make sure you have the following. options "COMPAT_43" If you prefer to statically link the emulator in the kernel rather than use the loadable kernel module (LKM), then add options LINUX Then run config and install the new kernel as described in the section. If you decide to use the LKM you must also install the loadable module. A mismatch of versions between the kernel and loadable module can cause the kernel to crash, so the safest thing to do is to reinstall the LKM when you install the kernel. % cd /usr/src/lkm/linux % make all install Once you have installed the kernel and the LKM, you can invoke `linux' as root to load the LKM. % linux Linux emulator installed Module loaded as ID 0 % To see whether the LKM is loaded, run `modstat'. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator % You can cause the LKM to be loaded when the system boots in either of two ways. On FreeBSD-CURRENT and FreeBSD-STABLE enable it in /etc/sysconfig linux=YES by changing it from NO to YES. FreeBSD 2.1 RELEASE and earlier do not have such a line and on those you will need to edit /etc/rc.local to add the following line. linux Installing Linux Emulation in 2.2-CURRENT

In -current it is no longer necessary to specify ``options LINUX'' or ``options COMPAT_LINUX''. Linux emulation is done with an LKM (``Loadable Kernel Module'') so it can be installed on the fly without having to reboot. You will need the following things in your startup files, however: In /etc/sysconfig, you need the following line: linux=YES This, in turn, triggers the following action in /etc/rc.i386: # Start the Linux binary emulation if requested. if [ "X${linux}" = X"YES" ]; then echo -n ' '; linux # XXX BOGUS - Linux script shouldn't make any output on success fi

If you want to verify it is running, modstat will do that: % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod % However, there have been reports that this fails on some FreeBSD-current systems. If for some reason you cannot load the linux LKM, then statically link the emulator in the kernel by adding options LINUX to your kernel config file. Then run config and install the new kernel as described in the section. Installing Linux Runtime Libraries Installing using the linux_lib port

Most linux applications use shared libraries, so you are still not done until you install the shared libraries. It is possible to do this by hand, however, it is vastly simpler to just grab the linux_lib port: % cd /usr/ports-current/emulators/linux_lib % make all install and you should have a working linux emulator. Legend (and the mail archives :-) seems to hold that Linux emulation works best with linux binaries linked against the ZMAGIC libraries; QMAGIC libraries (such as those used in Slackware V2.0) may tend to give the Linuxulator heartburn. As of this writing (March 1996) ELF emulation is still in the formulative stages but seems to work pretty well. Also, expect some programs to complain about incorrect minor versions. In general this does not seem to be a problem. Installing libraries manually

If you do not have the ``ports'' distribution, you can install the libraries by hand instead. You will need the Linux shared libraries that the program depends on and the runtime linker. Also, you will need to create a "shadow root" directory, /compat/linux, for Linux libraries on your FreeBSD system. Any shared libraries opened by Linux programs run under FreeBSD will look in this tree first. So, if a Linux program loads, for example, /lib/libc.so, FreeBSD will first try to open /compat/linux/lib/libc.so, and if that does not exist then it will try /lib/libc.so. Shared libraries should be installed in the shadow tree /compat/linux/lib rather than the paths that the Linux ld.so reports. FreeBSD-current works slightly differently with respect to /compat/linux. On -current, all files, not just libraries, are searched for from the ``shadow root'' /compat/linux. Generally, you will need to look for the shared libraries that Linux binaries depend on only the first few times that you install a Linux program on your FreeBSD system. After a while, you will have a sufficient set of Linux shared libraries on your system to be able to run newly imported Linux binaries without any extra work. How to install additional shared libraries

What if you install the linux_lib port and your application still complains about missing shared libraries? How do you know which shared libraries Linux binaries need, and where to get them? Basically, there are 2 possibilities (when following these instructions: you will need to be root on your FreeBSD system to do the necessary installation steps).

If you have access to a Linux system, see what shared libraries it needs, and copy them to your FreeBSD system. Example: you have just ftp'ed the Linux binary of Doom. Put it on the Linux system you have access to, and check which shared libraries it needs by running `ldd linuxxdoom': % ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

You would need go get all the files from the last column, and put them under /compat/linux, with the names in the first column as symbolic links pointing to them. This means you eventually have these files on your FreeBSD system: /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29

Note that if you already have a Linux shared library with a matching major revision number to the first column of the 'ldd' output, you will not need to copy the file named in the last column to your system, the one you already have should work. It is advisable to copy the shared library anyway if it is a newer version, though. You can remove the old one, as long as you make the symbolic link point to the new one. So, if you have these libraries on your system: /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 and you find a new binary that claims to require a later version according to the output of ldd: libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 If it is only one or two versions out of date in the in the trailing digit then do not worry about copying /lib/libc.so.4.6.29 too, because the program should work fine with the slightly older version. However, if you like you can decide to replace the libc.so anyway, and that should leave you with: /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29

Please note that the symbolic link mechanism is only needed for Linux binaries, the FreeBSD runtime linker takes care of looking for matching major revision numbers itself, you do not need to worry about that. Configuring the ld.so -- for FreeBSD-current only

This section applies only to FreeBSD-current only. Those running FreeBSD-stable should skip this section.

Finally, if you run FreeBSD-current you must make sure that you have the Linux runtime linker and its config files on your system. You should copy these files from the Linux system to their appropriate place on your FreeBSD system (to the /compat/linux tree): /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config

If you do not have access to a Linux system, you should get the extra files you need from various ftp sites. Information on where to look for the various files is appended below. For now, let us assume you know where to get the files.

Retrieve the following files (all from the same ftp site to avoid any version mismatches), and install them under /compat/linux (i.e. /foo/bar is installed as /compat/linux/foo/bar): /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so

ldconfig and ldd do not necessarily need to be under /compat/linux, you can install them elsewhere in the system too. Just make sure they do not conflict with their FreeBSD counterparts. A good idea would be to install them in /usr/local/bin as ldconfig-linux and ldd-linux.

Create the file /compat/linux/etc/ld.so.conf, containing the directories in which the Linux runtime linker should look for shared libs. It is a plain text file, containing a directory name on each line. /lib and /usr/lib are standard, you could add the following: /usr/X11/lib /usr/local/lib

When a linux binary opens a library such as /lib/libc.so the emulator maps the name to /compat/linux/lib/libc.so internally. All linux libraries should be installed under /compat/linux (e.g. /compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so, etc.) in order for the emulator to find them.

Those running FreeBSD-current should run the Linux ldconfig program. % cd /compat/linux/lib % /compat/linux/sbin/ldconfig

Ldconfig is statically linked, so it does not need any shared libraries to run. It creates the file /compat/linux/etc/ld.so.cache which contains the names of all the shared libraries. It should rerun to recreate this file whenever you install additional shared libraries. On FreeBSD-stable do not install /compat/linux/etc/ld.so.cache or run ldconfig because in FreeBSD-stable the syscalls are implemented differently and ldconfig is not needed or used.

You should now be set up for Linux binaries which only need a shared libc. You can test this by running the Linux ldd on itself. Suppose that you have it installed as ldd-linux, it should produce something like: % ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

This being done, you are ready to install new Linux binaries. Whenever you install a new Linux program, you should check if it needs shared libraries, and if so, whether you have them installed in the /compat/linux tree. To do this, you run the Linux version ldd on the new program, and watch its output. ldd (see also the manual page for ldd(1)) will print a list of shared libraries that the program depends on, in the form majorname (jumpversion) => fullname.

If it prints "not found" instead of fullname it means that you need an extra library. Which library this is, is shown in majorname, which will be of the form libXXXX.so.N You will need to find a libXXXX.so.N.mm on a Linux ftp site, and install it on your system. The XXXX (name) and N (major revision number) should match; the minor number(s) mm are less important, though it is advised to take the most recent version. Configuring the host name resolver

If DNS does not work or you get the messages resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword then you need to configure a /compat/linux/etc/host.conf file containing: order hosts, bind multi on where the order here specifies that /etc/hosts is searched first and DNS is searched second. When /compat/linux/etc/host.conf is not installed linux applications find FreeBSD's /etc/host.conf and complain about the incompatible FreeBSD syntax. You should remove `bind,' if you have not configured a name-server using the /etc/resolv.conf file.

Lastly, those who run FreeBSD-stable need to set an the RESOLV_HOST_CONF environment variable so that applications will know how to search the host tables. If you run FreeBSD-current you can skip this. For the /bin/csh shell use: setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf For /bin/sh use: RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF Finding the necessary files

Note: the information below is valid as of the time this document was written, but certain details such as names of ftp sites, directories and distribution names may have changed by the time you read this.

Linux is distributed by several groups that make their own set of binaries that they distribute. Each distribution has its own name, like ``Slackware'' or ``Yggdrasil''. The distributions are available on a lot of ftp sites. Sometimes the files are unpacked, and you can get the individual files you need, but mostly they are stored in distribution sets, usually consisting of subdirectories with gzipped tar files in them. The primary ftp sites for the distributions are: sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions

Some European mirrors: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/linux/distributions src.doc.ic.ac.uk:/packages/linux/distributions

For simplicity, let us concentrate on Slackware here. This distribution consists of a number of subdirectories, containing separate packages. Normally, they are controlled by an install program, but you can retrieve files "by hand" too. First of all, you will need to look in the "contents" subdir of the distribution. You will find a lot of small text files here describing the contents of the separate packages. The fastest way to look something up is to retrieve all the files in the contents subdirectory, and grep through them for the file you need. Here is an example of a list of files that you might need, and in which contents-file you will find it by grepping through them: Library Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs

So, in this case, you will need the packages ldso, shlibs, xf_lib and oldlibs. In each of the contents-files for these packages, look for a line saying ``PACKAGE LOCATION'', it will tell you on which `disk' the package is, in our case it will tell us in which subdirectory we need to look. For our example, we would find the following locations: Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9

The locations called ``diskXX'' refer to the ``slakware/XX'' subdirectories of the distribution, others may be found in the ``contrib'' subdirectory. In this case, we could now retrieve the packages we need by retrieving the following files (relative to the root of the Slackware distribution tree): slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf_lib.tgz

Extract the files from these gzipped tarfiles in your /compat/linux directory (possibly omitting or afterwards removing files you do not need), and you are done.

See also: ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README /usr/src/sys/i386/ibcs2/README.iBCS2 How to Install Mathematica on FreeBSD

Contributed by &a.rich and &a.chuck This document shows how to install the Linux binary distribution of Mathematica 2.2 on FreeBSD 2.1.

Mathematica supports Linux but not FreeBSD as it stands. So once you have configured your system for Linux compatibility you have most of what you need to run Mathematica.

For those who already have the student edition of Mathematica for DOS the cost of upgrading to the Linux version at the time this was written, March 1996, was $45.00. It can be ordered directly from Wolfram at (217) 398-6500 and paid for by credit card. Unpacking the Mathematica distribution

The binaries are currently distributed by Wolfram on CDROM. The CDROM has about a dozen tar files, each of which is a binary distribution for one of the supported architectures. The one for Linux is named LINUX.TAR. You can, for example, unpack this into /usr/local/Mathematica: % cd /usr/local % mkdir Mathematica % cd Mathematica % tar -xvf /cdrom/LINUX.TAR Obtaining your Mathematica Password

Before you can run Mathematica you will have to obtain a password from Wolfram that corresponds to your `machine ID.'

Once you have installed the linux compatibility runtime libraries and unpacked the mathematica you can obtain the `machine ID' by running the program `mathinfo' in the Install directory. % cd /usr/local/Mathematica/Install % mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 % So, for example, the `machine ID' of `richc' is `9845-03452-90255'. You can ignore the message about the ioctl that is not implemented. It will not prevent Mathematica from running in any way and you can safely ignore it, though you will see the message every time you run Mathematica.

When you register with Wolfram, either by email, phone or fax, you will give them the 'machine ID' and they will respond with a corresponding password consisting of groups of numbers. You need to add them both along with the machine name and license number in your mathpass file. You can do this by invoking: % cd /usr/local/Mathematica/Install % math.install It will ask you to enter your license number and the Wolfram supplied password. If you get them mixed up or for some reason the math.install fails, That is OK, because you can simply edit the file 'mathpass' in this same directory to correct the info manually.

After getting past the password, math.install will ask you if you accept their canned install defaults, or if you want to use your own. If you are like us and distrust all install programs, you probably want to specify the actual directories. Beware. Although the math.install program asks you to specify directories, it will not create them for you, so you should perhaps have a second window open with another shell so that you can create them before you give them to the install program. Or, if it fails, you can create the directories and then restart the math.install program. The directories we chose to create beforehand and specify to math.install were: /usr/local/Mathematica/bin for binaries /usr/local/Mathematica/man/man1 for man pages /usr/local/Mathematica/lib/X11 for the XKeysymb file You can also tell it to use /tmp/math.record for the system record file, where it puts logs of sessions. After this math.install will continue on to unpacking things and placing everything where it should go.

The Mathematica Notebook feature is included separately, as the X Front End, and you have to install it separately. To get the X Front End stuff correctly installed, cd into the /usr/local/Mathematica/FrontEnd directory and executed the ./xfe.install shell script. You will have to tell it where to put things, but you do not have to create any directories because it uses all the same directories that had been created for math.install. When it finished, there should be a new shell script in /usr/local/Mathematica/bin called "mathematica".

Lastly, you need to modify each of the shell scripts that Mathematica has installed. At the beginning of every shell script in /usr/local/Mathematica/bin add the following line: XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB This tells Mathematica were to find its own version of the key mapping file XKeysymDB. Without this you will get pages of error messages about missing key mappings. On FreeBSD-stable you need to add the following as well: RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF This tells Mathematica to use the linux version of host.conf. This file has a different syntax from FreeBSD's host.conf, so you will get an error message about /etc/host.conf if you leave this out.

You might want to also modify your /etc/manpath.config file to read the new man directory, and you may need to edit your ~/.cshrc file to add /usr/local/Mathematica/bin to your path.

That is about all it takes, With this you should be able to type "mathematica" and get a really slick looking Mathematica Notebook screen up. Mathematica has included the Motif user interfaces, but it is compiled in statically, so you do not need the Motif libraries. Good luck doing this yourself! Bugs

The Notebook front end is known to hang sometimes when reading notebook files with an error messages similar to: File .../Untitled-1.mb appears to be broken for OMPR.257.0 We have not found the cause for this, but it only affects the Notebook's X Window front end, not the mathematica engine itself. So the command line interface invoked by 'math' is unaffected by this bug. Acknowledgments

A well-deserved thanks should go to &a.sos; and &a.peter; who made linux emulation what it is today, and Michael Smith who drove these two guys like dogs to get it to the point where it runs Linux binaries better than linux! :-)