prc-tools.spec
or with the
prc-tools.build
script. While we make every effort to keep
these instructions up to date, those two files should be considered to
represent the canonical tested build procedures.
Problems encountered while building prc-tools are likely to be bugs in the
build scripts, makefiles, or procedures, and we would like to hear about them.
The prc-tools-devel
mailing list is the right place to report
difficulties in building prc-tools itself. (But it is not
the right place for difficulties encountered while using the tools.)
In this document, we use prc-tools-srcdir
to refer to the top
level source directory for prc-tools. If you are working from CVS, this
directory's name will be simply prc-tools
. If you have downloaded
a source tarball, it will be something like prc-tools-2.1
.
For a Palm OS application, these header files are provided by a Palm OS SDK. However, the audience for prc-tools is different: It is often built by people, such as system administrators and OS distributors, who may not themselves be Palm OS programmers. It is unreasonable to require such people to first obtain a separate non-redistributable SDK that they may not subsequently wish to use, just so that they can compile a small part of this package.
Hence prc-tools contains header files (in the bootstrap
subdirectory) which declare just enough Palm OS API functions and related
machinery to compile the run-time support code. Thus prc-tools itself can
be compiled by itself, without requiring any separate Palm OS SDK to be
installed on the build system. (Of course people later using
prc-tools will likely need to obtain an SDK themselves if they wish to
write non-trivial applications.)
See Debian bug #78745 and
bootstrap/Makefile
for further details of this arrangement.
gcc
or cc
is earlier than this but
you have a recent GCC installed as, e.g., gcc295
,
you can specify that the tools be built using the non-default compiler
by defining variables for the configure command:
~/build$ CC=gcc295 CXX=g++295 ../prc-tools-srcdir/configure ...etc...
Particularly if you are a maintainer working on prc-tools, you may also need the following:
bootstrap
headers.
A Palm OS SDK
and some Palm OS device (such as
Poser
and a ROM) are needed to do this, because the headers are generated by running
a Palm OS application, GenBootstrap.
At present only the C and C++ languages are supported, so you can download
and unpack only the gcc-core
and gcc-g++
packages
instead of the entire gcc
package if you wish.
(Note that the patches are in unified diff format and some
patch
implementations, notably on Solaris, do not handle
this format correctly. If you are thus afflicted, we recommend using
GNU patch
instead.)
Once you have downloaded the packages, you need to unpack them and apply the patches:
~$ tar xfz prc-tools-2.1.tar.gz ~$ tar xfz binutils-2.14.tar.gz ~$ tar xfz gdb-5.3.tar.gz ~$ tar xfz gcc-2.95.3.tar.gz ~$ tar xfz gcc-3.3.1.tar.gz ~$ cat prc-tools-srcdir/*.palmos.diff | patch -p0
Finally, you need to make the GNU packages available to prc-tools's configure script and top-level Makefile so that building all the packages can be integrated into just one build:
At present, the m68k compiler will be built from~$ cd prc-tools-srcdir ~/prc-tools-srcdir$ ln -s ../binutils-2.14 binutils ~/prc-tools-srcdir$ ln -s ../gdb-5.3 gdb ~/prc-tools-srcdir$ ln -s ../gcc-2.95.3 gcc295 ~/prc-tools-srcdir$ ln -s ../gcc-3.3.1 gcc ~/prc-tools-srcdir$ cd ..
gcc295
and the
ARM compiler from gcc
; if you are only building one of them, you
can omit the other directory. (In the future, the m68k patches will be
ported to GCC 3.x, and the gcc295
directory will disappear.)
(On Windows, if you use any non-Cygwin programs in your build, you should
use mv
instead of ln -s
since non-Cygwin programs
can't see through Cygwin's symlinks.)
You can optionally generate HTML versions of the documentation for
prc-tools, binutils, GDB, GCC, and also for
make.
To generate the make documentation, you'll also need to make
GNU Make source code available
similarly, as prc-tools-srcdir/make
.
(Due to recent rearrangements in the make package, this requires at least
version 3.80 of GNU Make.)
(Source tarballs contain the~$ mkdir build ~$ cd build ~/build$ mkdir empty ~/build$ ../prc-tools-srcdir/configure --target=m68k-palmos \ --enable-languages=c,c++ \ --with-headers=`pwd`/empty
configure
script, but CVS does not.
If you are building from CVS you'll have to use
autoconf -- 2.13,
not 2.5x -- to regenerate it from configure.in
first.)
The parameters shown above must be given, with whatever values are appropriate, because their defaults will cause problems. In addition to the standard configure options, the following options can be used:
--enable-targets=m68k-palmos,arm-palmos
tools
will be
configured for all of the given targets. You must use this or
--target
, but not both.
--target=m68k-palmos
m68k-palmos-coff
; dropping the
-coff
now will ease a potential future move to ELF, and
just plain makes more sense. But at the moment m68k-palmos
is merely an alias for m68k-palmos-coff
, so you can use
the full name for compatibility with prc-tools-0.5.0 for now if you like.
--enable-languages=c,c++
objc
won't work here.
--with-headers=`pwd`/empty
--with-palmdev-prefix=/opt/palmdev
/opt/palmdev
on Unix and /PalmDev
on Windows. By default, the tool chain will look in /opt/palmdev
.
--enable-html-docs[=/path]
/doc
will be used by default.
You may need to change user (e.g. to root) if you are installing to directories to which your usual user doesn't have write access.~/build$ make ~/build$ make install
In the past, building prc-tools was a tedious multistage process of
crt
subdirectory) needed both binutils
and GCC to be installed before it could be built.
The top-level prc-tools Makefile now tells the GCC build process to use an
uninstalled binutils from ~/build/binutils
, and tells the target
run-time build process to use an uninstalled GCC from ~/build/gcc
and the same uninstalled binutils. Thus later stages of the build use the
tools you have just built from the places in which you have built them,
instead of requiring the previous intertwined build/install process.
If you use one of the lower level makefiles directly, or if you have omitted
the binutils
or gcc
directories from your source
tree, the build processes will fall back to using the respective installed
utilities from your PATH
. The build will fail unless you have
previously installed such utilities.
There are further details in the GCC distribution's
install
directory
and also in the Cross-FAQ,
if you run into problems.