<HTML>
<HEAD>
<META NAME="copyright" CONTENT="Copyright 2001 by MandrakeSoft S.A.">
<META NAME="Author" CONTENT="Kevin Lawton">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<TITLE>Running ./configure</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#ececec" LINK="#3333cc" VLINK="#666666">
<CENTER><H1>Running ./configure</H1></CENTER>
This is a summary of all the possible options to ./configure.
Generally speaking, you can just take the defaults and run
configure without any options. If you need something
outside of the defaults, consult the following section.
<p>
Note that the configure script sets up the Makefiles to use
the compiler and compiler options from your environment.
You should set 4 environment variables, before calling configure.
For example, in bash:
<pre>
CC="egcs"
CXX="$CC"
CFLAGS="-Wall -O2 -m486 -fomit-frame-pointer -pipe"
CXXFLAGS="$CFLAGS"
export CC
export CXX
export CFLAGS
export CXXFLAGS
./configure
</pre>
I cheat and use script files to do this for me. You can look
in files such as ".conf.x86" to see what options I use, and how
I invoke configure.
<p>
This table is divided into the options that most users will need and the
more obscure options.
<CENTER><H1>Frequently Used Configure Options</H1></CENTER>
<table border>
<tr>
<th>Option</th>
<th>Defaults to</th>
<th>Comments</th>
<tr>
<td>--enable-cpu-level={3,4,5}</td>
<td>5
<td>Select which CPU level to emulate. Choices are 3,4,5 which
mean target 386, 486 or Pentium emulation.
</td>
<tr>
<td>--enable-processors={1,2,3,...,15}</td>
<td>1
<td>By changing to more than 1 processor, you enable SMP simulation. This allows you to boot Linux and maybe other OSes in SMP mode, and bochs will simulate all the different CPUs and communication between them. Do not expect this option to speed up your simulation! On the contrary, it has to spend extra time simulating the different CPUs (even if they're mostly idle) and the communication between them. Use it to try out an SMP OS if you don't have an SMP machine, or to debug your SMP OS drivers. Click <a href="smp-simulation.html">here</a> for more details on SMP in Bochs.
</td>
<tr>
<td>--enable-cdrom</td>
<td>no
<td>Enable use of a real CDROM. The cdrom emulation is always
present, and emulates a drive without media by default.
You can use this option to compile in support for accessing
the media in your workstation's cdrom drive. The supported
platforms are Linux, Solaris, OpenBSD, and Windows.
For other platforms, a small amount of code specific to
your platform must be written. The module
iodev/cdrom.cc is the place to add more support. For the
most part, you need to figure out the right set of ioctl()
calls.
</td>
<tr>
<td>--enable-sb16={<i>dummy, win, linux</i>}</td>
<td>no
<td>Enable Sound Blaster emulation.
SB16 output is only supported for Windows or Linux. The <i>dummy</i>
option means to support an SB16, but don't use
an output device. So for example, you might use
'--enable-sb16=linux'. Check out <a href="sound.html">sound.html</a>
for more info.
</td>
<tr>
<td>--enable-cpp</td>
<td>no
<td>Use .cpp as C++ suffix. Moves all the .cc files to .cpp for
use with compilers which want that, like MS C++ compilers.
Don't use this option unless you know you need it.</td>
<tr>
<td>--enable-debugger</td>
<td>no
<td>Compile in support for Bochs internal command-line debugger.
This has nothing to do with x86 hardware debug support. It
is a more powerful and non-intrusive native debugger.
Enabling this will of course slow down the emulation.
You only need this option if you know you need it. After
you have run ./configure, you may want to edit 'config.h'
to customize the debugger further. Look at the section
entitled 'OPTIONAL DEBUGGER SECTION'.</td>
<tr>
<td>--enable-disasm</td>
<td>no
<td>Compile in support for built-in disassembler. Bochs has
a built-in disassembler, which is useful if you either
run the built-in debugger (--enable-debugger), or want
disassembly of the current instruction when there is a
panic in bochs. You don't need this option.</td>
<tr>
<td>--enable-vga</td>
<td>yes
<td>Use VGA emulation. VGA is the only supported option and
since it's the default, you don't need to include this option.</td>
<tr>
<td>--enable-fpu</td>
<td>no before bugfix2<br>yes for bugfix3 (5/16/2001) and after
<td>If you want to compile bochs to make use of the FPU emulator
written by Bill Metzenthen (the one used by the Linux kernel),
use this option.
</td>
<tr>
<td>--enable-x86-debugger</td>
<td>no
<td>X86 debugger support. If the software you run in bochs
needs to use the x86 hardware debugging facilities such as
DR0..DR8, instruction and data breakpoints etc., then you
should use this option. Otherwise don't use it, as it
will slow down the emulation.</td>
<tr>
<td>--with-x11</td>
<td>yes
<td>Use X11 GUI. This is the default and you don't need
this option if you are using X11.</td>
<tr>
<td>--with-rfb</td>
<td>no
<td>Use RFB protocol to talk to AT&T's <a href="http://www.uk.research.att.com/vnc/">VNC Viewer</a>. The RFB code was written by <a href="mailto:x-odus@iname.com">Don Becker</a>, who has a Bochs-RFB web page on his site, <a href="http://www.psyon.org/bochs-rfb/">http://www.psyon.org/bochs-rfb</a>.</td>
<tr>
<td>--with-beos</td>
<td>no
<td>Use BeOS GUI. The configure script will run natively
on BeOS and use this option when doing so.</td>
<tr>
<td>--with-win32-vcpp</td>
<td>no
<td>Use Win32 GUI/Visual C++ environment. This is for running
configure on a platform which supports running configure, so
that you may then transfer the configured code over to
an MS Win32/Visual C++ environment.</td>
<tr>
<td>--with-macos</td>
<td>no
<td>Use Macintosh/CodeWarrior environment</td>
<tr>
<td>--with-nogui</td>
<td>no
<td>No native GUI, just use blank stubs. This is if you don't
care about having video output, but are just running tests.
This option may not be up-to-date, but can be made so
easily.</td>
</table>
<CENTER><H1>Other Configure Options</H1></CENTER>
<table border>
<tr>
<th>Option</th>
<th>Defaults to</th>
<th>Comments</th>
<tr>
<td>--enable-ne2000</td>
<td>no
<td>Enable limited ne2000 support. This requires a low-level
component to be written for each OS. One is written only
for FreeBSD so far. Not complete yet. Don't use this option yet.</td>
<tr>
<td>--enable-pci</td>
<td>no
<td>Enable limited i440FX PCI support. This is not complete.
Don't use this option.</td>
<tr>
<td>--enable-port-e9-hack</td>
<td>no
<td>Writes to port e9 go to console. Unless you know you want
this option, you don't.</td>
<tr>
<td>--enable-loader</td>
<td>no
<td>Support calling external loader from debugger. This
is an unsupported option. Don't use it.</td>
<tr>
<td>--enable-instrumentation</td>
<td>no
<td>Compile in support for instrumentation. This allows
you to collect instrumentation data from bochs as
it executes code. You have to create your own
instrumentation library and define the instrumentation
macros (hooks in bochs) to either call your library
functions or not, depending upon whether you want
to collect each piece of data. [Kevin wrote: I broke
some of the hooks when I recoded the fetch/decode loop.
Contact me if you need this option.]</td>
<tr>
<td>--enable-simid={0, 1}</td>
<td>0
<td>CPU simulator ID. You likely don't need this
option. If you are using bochs to cosimulate, that
is to run multiple simulators in parallel so that you
can compare results and check for divergence, each
simulator needs an ID. When you only have one CPU
simulator (as usual) the default of 0 is fine. I
use this option occasionally to run 2 versions of
bochs against each other and check for divergence,
to find bugs etc. This option gets broken more than
not due to architectural changes, and I usually end of fixing
it each time I use it. </td>
<tr>
<td>--enable-num-sim={1, 2}</td>
<td>1
<td>Number of CPU simulators. The default of 1 is likely what
you want, so don't use this option. It is for assigning
an ID to the simulator, for cosimulation described above.</td>
<tr>
<td>--enable-time0=n</td>
<td>no
<td>Start CMOS clock at at time0 of n instead of using time().
You likely don't want this
option. When debugging, it is very helpful to have
deterministic execution, and the clock is something that
can skew determinism. If you supply this option, pass
it a value returned by the time(NULL) call, relating to
the time you want bochs to start the CMOS clock from. For
instance, '--enable-time0=917385580'. If you use this option
but don't provide a value, configure uses a default value.
Note that the time0 option in .bochsrc will override this value.
Without this option, the CMOS clock uses a time0 based on
the value of time(NULL), which is probably what you want.
</td>
<tr>
<td>--enable-hga-dumps=Nmicroseconds</td>
<td>no
<td>Copy memory to HGA video buffer every N useconds. A
deprecated option, don't use.</td>
<tr>
<td>--with-win32</td>
<td>no
<td>Use Win32 GUI. I think this option was similar to
--with-win32-vcpp, but for targeting a Win32/gcc
environment. Deprecated option.</td>
</table>
</BODY>
</HTML>
