- Timestamp:
- 03/11/15 14:29:13 (9 years ago)
- Branches:
- 4.11, 5, master
- Children:
- bdf23b6c
- Parents:
- cf404563
- git-author:
- Gedare Bloom <gedare@…> (03/11/15 14:29:13)
- git-committer:
- Gedare Bloom <gedare@…> (03/11/15 17:39:29)
- Location:
- doc
- Files:
-
- 1 deleted
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/common/rtems.texi.in
rcf404563 rd84995d2 1 @set RTEMSHTTPSITE www.rtems.org 2 @set RTEMSUSERS rtems-users@@rtems.com 3 @set RTEMSUSERSSUBSCRIBE rtems-users-subscribe@@rtems.com 4 @set RTEMSBUGS http://www.rtems.org/bugzilla 5 @set RTEMSFTPURL ftp://www.rtems.org 1 @set RTEMSUSERS users@@rtems.org 2 @set RTEMSDEVEL devel@@rtems.org 6 3 @set RTEMSHTTPURL http://www.rtems.org 7 4 @set RTEMSPREFIX @RTEMSPREFIX@ -
doc/started/Makefile.am
rcf404563 rd84995d2 9 9 include $(top_srcdir)/main.am 10 10 11 GENERATED_FILES = b inaries.texi buildc.texi buildrt.texi intro.texi nt.texi \11 GENERATED_FILES = buildc.texi buildrt.texi intro.texi nt.texi \ 12 12 require.texi nextstep.texi sample.texi 13 13 … … 25 25 26 26 require.texi: require.t 27 $(BMENU2) -c -p " GCCMailing Lists" \27 $(BMENU2) -c -p "RTEMS Mailing Lists" \ 28 28 -u "Top" \ 29 -n "Prebuilt Toolset Executables" < $< > $@ 30 31 binaries.texi: binaries.t 32 $(BMENU2) -c \ 33 -p "GNU/Linux Distributions using Debian Packaging Format" \ 34 -u "Top" \ 35 -n "Building the GNU Cross Compiler Toolset" < $< > $@ 29 -n "Building the GNU Cross Compiler Toolset with RSB" < $< > $@ 36 30 37 31 buildc.texi: buildc.t 38 $(BMENU2) -c -p "Removing Zipped Tar Files" \ 32 $(BMENU2) -c \ 33 -p "Distribution Independent Potential GNU/Linux Issues" \ 39 34 -u "Top" \ 40 35 -n "Building RTEMS" < $< > $@ 41 36 42 37 buildrt.texi: buildrt.t 43 $(BMENU2) -c -p "Error Messages Indicating Configuration Problems" \ 38 $(BMENU2) -c \ 39 -p "Building the GNU Cross Compiler Toolset with RSB" \ 44 40 -u "Top" \ 45 41 -n "Building the Sample Applications" < $< > $@ … … 60 56 -n "" < $< > $@ 61 57 62 EXTRA_DIST = b inaries.t buildc.t buildrt.t intro.t nextstep.t nt.t require.t \58 EXTRA_DIST = buildc.t buildrt.t intro.t nextstep.t nt.t require.t \ 63 59 sample.t 64 60 -
doc/started/buildc.t
rcf404563 rd84995d2 4 4 @c All rights reserved. 5 5 6 @chapter Building the GNU Cross Compiler Toolset 6 @chapter Building the GNU Cross Compiler Toolset with RSB 7 7 8 @b{NOTE}: This chapter describes the steps required to build cross-compilation 9 toolset on Linux (and possibly Windows using Cygwin) systems. This chapter 10 does @b{NOT} apply if you installed prebuilt toolset executables for BINUTILS, 11 GCC, NEWLIB, and GDB. If you installed prebuilt executables for all of those, 12 proceed to @ref{Building RTEMS}. If you require a GDB with a special 13 configuration to connect to your target board, then proceed to 14 @ref{Installing GDB Without RPM} for some advice. 8 The RTEMS Projects recommends using the RTEMS Source Builder (RSB) 9 for building the toolset from source. RSB has evolved over time from 10 various instructions and scripts for building the toolset, and it removes 11 much of the frustration associated with building the toolset from source. 12 Although prebuilt binaries are much easier to install, they are harder 13 for the RTEMS Project to support. 15 14 16 This chapter describes the steps required to acquire the source code for 17 a GNU cross compiler toolset, apply any required RTEMS specific patches, 18 compile that toolset and install it. 15 Documentation for RSB is available from @uref{https://docs.rtems.org/rsb/,https://docs.rtems.org/rsb/}. 19 16 20 It is recommended that when toolset binaries are available for your21 particular host, that they be used. Prebuilt binaries are much easier22 to install. They are also much easier for the RTEMS Project to support.23 24 @c25 @c Preparation26 @c27 @section Preparation28 29 Before you can build an RTEMS toolset from source, there are some30 preparatory steps which must be performed. You will need to determine31 the various tool versions and patches required and download them You32 will also have to unarchive the source and apply any patches.33 34 @c35 @c Determining Tool Version and Patch Revision36 @c37 @subsection Determining Tool Version and Patch Revision38 39 The tool versions and patch revisions change on a fairly frequent basis.40 In addition, these may vary based upon the target architecture. In some41 cases, the RTEMS Project may have to stick with a particular version42 of a tool to provide a working version for a specific architecture.43 Because of this, it is impossible to provide this information in a44 complete and accurate manner in this manual. You will need to refer45 to the configuration files used by the RTEMS RPM specification files to46 determine the current versions and, if a patch is required, what version.47 This section describes how to locate the appropriate tool versions and48 patches for a particular target architecture.49 50 All patches and RPM specification files are kept under source code51 control. They are not included in release tarballs. You will have to52 access the CVS branch for RTEMS @value{RTEMSAPI}. For details on this,53 visit @uref{http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository,54 http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository} and look for55 instructions on accessing the RTEMS Source Code Repository in read-only56 mode.57 58 In the checked out source code, you will need to look in the subdirectory59 @code{contrib/crossrpms/autotools} to determine the versions of AUTOCONF60 and AUTOMAKE as well as any patches required. In this directory are61 a few files you will need to look at. The first is @code{Makefile.am}62 which defines the versions of AUTOCONF and AUTOMAKE required for this63 RTEMS Release Series. Make a note of the version numbers required for64 AUTOCONF and AUTOMAKE (AUTOCONF_VERS and AUTOMAKE_VERS respectively). Then65 examine the following files to determine the master location for the source66 tarballs and to determine if a patch is required for each tool version cited in67 the @code{Makefile.am}.68 69 @example70 autoconf-sources.add71 automake-sources.add72 @end example73 74 If any patches are required, they will be in the75 @code{contrib/crossrpms/patches} subdirectory of your checked out RTEMS76 source tree.77 78 If no patches are required, you can use a package manager provided by your79 Linux distribution to install AUTOMAKE and AUTOCONF to avoid building them from80 source.81 82 In the checked out source code, you will need to look in the subdirectory83 @code{contrib/crossrpms/rtems@value{RTEMSAPI}} to determine the target84 specific tool versions and patches required. In this directory, you85 will find a number of subdirectories with many named after target86 architectures supported by RTEMS. Descend into the directory for the87 architecture you plan to build tools for. Again, the @code{Makefile.am}88 defines the tool versions for this architecture and RTEMS Release Series.89 Make a note of the version numbers required for BINUTILS, GCC, NEWLIB,90 and GDB. Then examine the following files to determine the master91 location for the source tarballs and to determine if a patch is required92 for each tool version cited in the @code{Makefile.am}.93 94 @itemize95 @item binutils-sources.add96 @item gcc-sources.add97 @item gdb-sources.add98 @end itemize99 100 If any patches are required, they will be in the101 @code{contrib/crossrpms/patches} subdirectory of your checked out RTEMS102 source tree.103 104 This is the entire set of source tarballs and patches required for a105 toolset targeting the selected architecture. In many cases, this will be106 the same versions required by other targets on this RTEMS Release Series.107 108 @c109 @c Obtain Source and Patches110 @c111 @subsection Obtain Source and Patches112 113 You will need to download the sources for the various packages from114 their master locations as identified in the previous section.115 116 Any patches needed should be in the @code{contrib/crossrpms/patches}117 directory of your RTEMS source.118 119 @c120 @c Installing the Tools Without RPM121 @c122 @section Installing the Tools Without RPM123 124 This section describes the procedure for building and installing an RTEMS125 cross toolset from source code without using the RPM build infrastructure.126 127 Direct invocation of @code{configure} and @code{make} provides more control128 and easier recovery from problems when building.129 130 @c131 @c Archive and Build Directory Format132 @c133 @subsection Archive and Build Directory Format134 135 When no packaging format requirements are present, the root directory for136 the storage of source archives and patches as well as for building the137 tools is up to the user. The only concern is that there be enough138 disk space to complete the build. In this document, the following139 organization will be used.140 141 Make an @code{archive} directory to contain the downloaded source code142 and pataches. Additionally, a @code{tools} directory to be used as a143 build directory. The command sequence to do this is shown below:144 145 @example146 mkdir archive147 mkdir tools148 @end example149 150 This will result in an initial directory structure similar to the151 one shown in the following figure:152 153 @example154 @group155 /whatever/prefix/you/choose/156 archive/157 tools/158 159 @end group160 @end example161 162 The RTEMS Project tries to submit all of our patches upstream to the163 parent projects. In the event there are patches, the master copy of them164 is located in the appropriate branch of the RTEMS source module in CVS.165 Patches are in the @code{contrib/crossrpms/patches}.166 167 @c168 @c Unarchiving the Tools169 @c170 @subsection Unarchiving the Tools171 172 @b{NOTE}: This step is required if building any of the tools without using RPM.173 It is @b{NOT} required if using the procedure described in @ref{Using RPM174 to Build Tools}. This section describes the process of unarchiving the175 tools that comprise an RTEMS toolset.176 177 GNU source distributions are archived using @code{tar} and178 compressed using either @code{gzip} or @code{bzip}.179 If compressed with @code{gzip}, the extension @code{.gz} is used.180 If compressed with @code{bzip}, the extension @code{.bz2} is used.181 182 While in the @code{tools} directory, unpack the compressed tar files183 using the appropriate command based upon the compression program used.184 185 @example186 cd tools187 tar xzf ../archive/TOOLNAME.tar.gz # for gzip'ed tools188 tar xjf ../archive/TOOLNAME.tar.bz2 # for bzip'ed tools189 @end example190 191 Assuming you are building a complete toolset, after all of the the192 compressed tar files have been unpacked using the appropriate commands,193 the following directories will have been created under @code{tools}.194 195 @itemize @bullet196 @item autoconf-<VERSION>197 @item automake-<VERSION>198 @item binutils-<VERSION>199 @item gcc-<VERSION>200 @item newlib-<VERSION>201 @item gdb-<VERSION>202 @end itemize203 204 The tree should look something like the following figure:205 206 @example207 @group208 /whatever/prefix/you/choose/209 archive/210 variable tarballs211 variable patches212 tools/213 various tool source trees214 @end group215 @end example216 217 @c218 @c Applying RTEMS Project Tool Patches219 @c220 221 @subsection Applying RTEMS Project Tool Patches222 223 @b{NOTE}: This step is required if building any of the tools IF they have a224 patch currently required and you are building the tools without using RPM.225 is @b{NOT} required if using the procedure described in @ref{Using RPM226 to Build Tools}. This section describes the process of applying the227 RTEMS patches to any of the tools.228 229 If a patch is required for a particular tool source tree, it is placed in the230 @code{contrib/crossrpms/patches} directory in the CVS tree. Make sure the231 patch version is the same as of the tool you are building. You will perform a232 command similar to the following to apply the patch. In this example, <TOOL>233 should be replaced by the appropriate tool directory and <TOOL_PATCH> with the234 appropriate patch file.235 236 @example237 cd tools/<TOOL>238 cat ../../archive/<TOOL_PATCH> | patch -p1239 @end example240 241 @b{NOTE}: If you add the @code{--dry-run} option to the @code{patch} command242 in the above commands, it will attempt to apply the patch and report243 any issues without actually modifying any files.244 245 If the patch was compressed with the @code{gzip} program, it will246 have a suffix of @code{.gz} and you should use @code{zcat} instead247 of @code{cat} as shown above. If the patch was compressed with248 the @code{gzip} program, it will have a suffix of @code{.bz2} and249 you should use @code{bzcat} instead of @code{cat} as shown above.250 251 Check to see if any of these patches have been rejected using the following252 sequence:253 254 @example255 cd tools/<TOOL>256 find . -name "*.rej" -print257 @end example258 259 If any files are found with the .rej extension, a patch has been rejected.260 This should not happen with a good patch file which is properly applied.261 262 @c263 @c Installing AUTOCONF From Source264 @c265 266 @subsection Installing AUTOCONF From Source267 268 The following example illustrates the invocation of @code{configure}269 and @code{make} to build and install autoconf-<version>. This tool is270 installed as a native utility and is independent of any RTEMS target.271 272 @b{NOTE}: If no patch is required for Autoconf and Automake, you can use the273 standard package manager provided by your Linux distribution to install them.274 Of course, the versions provided by your package manager should be the same275 that specified in Makefile.am or better.276 277 @example278 mkdir b-autoconf279 cd b-autoconf280 ../autoconf-<VERSION>/configure --prefix=@value{RTEMSPREFIX}281 make282 make install283 @end example284 285 After autoconf-<VERSION> is built and installed the build directory286 @code{b-autoconf} may be removed.287 288 For more information on the invocation of @code{configure}, please289 refer to the documentation for autoconf-<VERSION> or invoke the290 autoconf-VERSION> @code{configure} command with the @code{--help} option.291 292 @c293 @c Installing AUTOMAKE From Source294 @c295 296 @subsection Installing AUTOMAKE From Source297 298 The following example illustrates the invocation of @code{configure}299 and @code{make} to build and install automake-<version>. This tool is300 installed as a native utility and is independent of any RTEMS target.301 302 @example303 mkdir b-automake304 cd b-automake305 ../automake-<VERSION>/configure --prefix=@value{RTEMSPREFIX}306 make all307 make info308 make install309 @end example310 311 After automake-<VERSION> is built and installed the build directory312 @code{b-automake} may be removed.313 314 For more information on the invocation of @code{configure}, please315 refer to the documentation for automake-<VERSION> or invoke the316 automake-VERSION> @code{configure} command with the @code{--help} option.317 318 @c319 @c Installing BINUTILS From Source320 @c321 @subsection Installing BINUTILS From Source322 323 The following example illustrates the invocation of @code{configure}324 and @code{make} to build and install binutils-<version>325 sparc-rtems@value{RTEMSAPI} target:326 327 @example328 mkdir b-binutils329 cd b-binutils330 ../binutils-<VERSION>/configure --target=sparc-rtems@value{RTEMSAPI} \331 --prefix=@value{RTEMSPREFIX}332 make all333 make info334 make install335 @end example336 337 After binutils-<VERSION> is built and installed the build directory338 @code{b-binutils} may be removed.339 340 For more information on the invocation of @code{configure}, please341 refer to the documentation for binutils-<VERSION> or invoke the342 binutils-VERSION> @code{configure} command with the @code{--help} option.343 344 NOTE: The shell PATH variable needs to be updated to include the path345 the binutils user executables have been installed in. The directory346 containing the executables is the prefix used above with347 @file{bin} post-fixed.348 349 @example350 export PATH=@value{RTEMSPREFIX}/bin:$@{PATH@}351 @end example352 353 As you will need to frequently run various commands in the354 @value{RTEMSPREFIX}/bin, you can update your @code{~/.bashrc} to include this355 line. After doing that, don't forget to run356 @example357 source ~/.bashrc358 @end example359 for the changes to take place.360 361 Failure to have the binutils in the path will cause the GCC and NEWLIB362 build to fail with an error message similar to:363 364 @example365 sparc-rtems@value{RTEMSAPI}-ar: command not found366 @end example367 368 @c369 @c Installing GCC and NEWLIB Without RPM370 @c371 @subsection Installing GCC and NEWLIB Without RPM372 373 Before building gcc-<VERSION> and newlib-<VERSION>,374 binutils-<VERSION> must be installed and the directory375 containing those executables must be in your PATH.376 377 The C Library is built as a subordinate component of378 gcc-<VERSION>. Because of this, the newlib-<VERSION>379 directory source must be available inside the gcc-<VERSION>380 source tree. This is normally accomplished using a symbolic381 link as shown in this example:382 383 @example384 cd gcc-<VERSION>385 ln -s ../newlib-<VERSION>/newlib .386 @end example387 388 The following example illustrates the invocation of389 @code{configure} and @code{make}390 to build and install gcc-<VERSION> with only391 C and C++ support for the sparc-rtems@value{RTEMSAPI} target:392 393 @example394 mkdir b-gcc395 cd b-gcc396 ../gcc-<VERSION>/configure --target=sparc-rtems@value{RTEMSAPI} \397 --with-gnu-as --with-gnu-ld --with-newlib --verbose \398 --enable-threads --enable-languages="c,c++" \399 --prefix=@value{RTEMSPREFIX}400 make all401 make info402 make install403 @end example404 405 After gcc-<VERSION> is built and installed the406 build directory @code{b-gcc} may be removed.407 408 For more information on the invocation of @code{configure}, please409 refer to the documentation for gcc-<VERSION> or410 invoke the gcc-<VERSION> @code{configure} command with the411 @code{--help} option.412 413 @c414 @c Building GCC with Ada Support415 @c416 @subsection Building GCC with Ada Support417 418 If you want a GCC toolset that includes support for Ada419 (e.g. GNAT), there are some additional requirements on420 the host environment and additional build steps to perform.421 It is critical that you use the same version of GCC/GNAT as422 the native compiler. GNAT must be compiled with an Ada compiler423 and when building a GNAT cross-compiler, it should be424 the same version of GNAT itself.425 426 It is also important to verify whether there is an RTEMS specific427 Ada patch required for GCC. These can be found in428 @uref{http://www.rtems.org/ftp/pub/rtems/people/joel/ada,429 http://www.rtems.org/ftp/pub/rtems/people/joel/ada}. The patch is430 often a minor version or two behind GCC but will usually apply cleanly.431 This patch must be applied.432 433 After this, it is critical to perform these steps in the correct order.434 GNAT requires that the C Library and RTEMS itself be installed before435 the language run-time can be built.436 437 @itemize @bullet438 @item install native GCC with GNAT439 @item place new native GNAT at head of PATH440 @item install BINUTILS441 @item place RTEMS prefix at head of PATH442 @item install C toolset (C++ is optional)443 @item install RTEMS built multilib444 @item install RTEMS built for your BSP445 @end itemize446 447 The build procedure is the same until the Ada configure step. A GCC448 toolset with GNAT enabled requires that @code{ada} be included in the set449 of enabled languages. The following example illustrates the invocation of450 @code{configure} and @code{make} to build and install gcc-<VERSION> with451 only C, C++, and Ada support for the sparc-rtems@value{RTEMSAPI} target:452 453 @example454 mkdir b-gcc455 cd b-gcc456 ../gcc-<VERSION>/configure --target=sparc-rtems@value{RTEMSAPI} \457 --with-gnu-as --with-gnu-ld --with-newlib --verbose \458 --enable-threads --enable-languages="c,c++,ada" \459 --prefix=@value{RTEMSPREFIX}460 make all461 make info462 make install463 @end example464 465 After gcc-<VERSION> is built and installed the build directory466 @code{b-gcc} may be removed.467 468 @c469 @c Installing GDB Without RPM470 @c471 @subsection Installing GDB Without RPM472 473 @b{NOTE}: This step is NOT required if prebuilt executables for the474 GDB were installed and they meet your target interface475 requirements.476 477 GDB supports many configurations but requires some means of communicating478 between the host computer and target board. This communication can be via479 a serial port, Ethernet, BDM, or ROM emulator. The communication protocol480 can be the GDB remote protocol or GDB can talk directly to a ROM monitor.481 This setup is target board specific. Some of the configurations that have482 been successfully used with RTEMS applications are:483 484 @itemize @bullet485 @item BDM with ColdFire, 683xx, MPC860 CPUs486 @item Motorola Mxxxbug found on M68xxx VME boards487 @item Motorola PPCbug found on PowerPC VME, CompactPCI, and MTX boards488 @item ARM based Cogent EDB7312489 @item PC's using various Intel and AMD CPUs including i386,490 i486, Pentium and above, and Athlon491 @item PowerPC Instruction Simulator in GDB (PSIM)492 @item MIPS Instruction Simulator in GDB (JMR3904)493 @item Sparc Instruction Simulator in GDB (SIS)494 @item Sparc Instruction Simulator (TSIM)495 @end itemize496 497 GDB is currently RTEMS thread/task aware only if you are using the498 remote debugging support via Ethernet. These are configured499 using gdb targets of the form CPU-RTEMS. Note the capital RTEMS.500 501 It is recommended that when toolset binaries are available for502 your particular host, that they be used. Prebuilt binaries503 are much easier to install but in the case of gdb may or may504 not include support for your particular target board.505 506 The following example illustrates the invocation of @code{configure}507 and @code{make} to build and install gdb-<VERSION> for the508 m68k-rtems@value{RTEMSAPI} target:509 510 @example511 mkdir b-gdb512 cd b-gdb513 ../gdb-<VERSION>/configure --target=m68k-rtems@value{RTEMSAPI} \514 --prefix=@value{RTEMSPREFIX}515 make all516 make info517 make install518 @end example519 520 For some configurations, it is necessary to specify extra options521 to @code{configure} to enable and configure option components522 such as a processor simulator. The following is a list of523 configurations for which there are extra options:524 525 @table @b526 @item powerpc-rtems@value{RTEMSAPI}527 @code{--enable-sim --enable-sim-powerpc --enable-sim-timebase --enable-sim-hardware}528 529 @item sparc-rtems@value{RTEMSAPI}530 @code{--enable-sim}531 532 @end table533 534 After gdb-<VERSION> is built and installed the535 build directory @code{b-gdb} may be removed.536 537 For more information on the invocation of @code{configure}, please538 refer to the documentation for gdb-<VERSION> or539 invoke the gdb-<VERSION> @code{configure} command with the540 @code{--help} option.541 542 543 @c544 @c Using RPM to Build Tools545 @c546 547 @section Using RPM to Build Tools548 549 RPM is a packaging format which can be used to distribute binary files as550 well as to capture the procedure and source code used to produce those551 binary files. For RPM, it is assumed that the following subdirectories552 are under a root directory such as @code{/usr/src/redhat} or553 @code{/usr/local/src/redhat}) on your machine.554 555 @example556 BUILD557 RPMS558 SOURCES559 SPECS560 SRPMS561 @end example562 563 For the purposes of this document, the RPM @code{SOURCES} directory is the564 directory into which all tool source and patches are assumed to reside.565 The @code{BUILD} directory is where the actual build is performed when566 building binaries from a source RPM.567 568 RPM automatically unarchives the source and applies any needed patches569 so you do @b{NOT} have to manually perform the procedures described570 @ref{Unarchiving the Tools} and @ref{Applying RTEMS Project Tool Patches}.571 But you are responsible for placing all source tarballs572 and patches in the @code{SOURCES} directory per the instructions in573 @ref{Obtain Source and Patches}574 575 This procedure starts by installing the source (e.g. @code{.src.rpm}576 extension) RPMs. The RTEMS tool source RPMS are called "nosrc" to577 indicate that one or more source files required to produce the RPMs578 are not present. The RTEMS source RPMs typically include all required579 patches, but do not include the large @code{.tar.gz} or @code{.tgz} files580 for each component such as BINUTILS, GCC, or NEWLIB. These are shared581 by all RTEMS RPMs regardless of target CPU and there was no reason to582 duplicate them. You will have to get the required source archive files583 by hand and place them in the @code{SOURCES} directory before attempting584 to build. If you forget to do this, RPM is smart -- it will tell you585 what is missing. You can fetch any missing files and try again.586 587 @c588 @c Building AUTOCONF using RPM589 @c590 @subsection Building AUTOCONF using RPM591 592 This section illustrates the invocation of RPM to build a new, locally593 compiled, AUTOCONF binary RPM that matches the installed source RPM.594 This example assumes that all of the required source is installed.595 596 @example597 rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-autoconf-<VERSION>-<RPM_RELEASE>.src.rpm598 @end example599 600 @example601 cd <RPM_ROOT_DIRECTORY>/SPECS602 rpm -bb i386-rtems@value{RTEMSAPI}-autoconf-<VERSION>.spec603 @end example604 605 If the build completes successfully, RPMS like the following will be606 generated in a build-host architecture specific subdirectory of the RPMs607 directory under the RPM root directory.608 609 @example610 @value{RTEMSRPMPREFIX}rtems@value{RTEMSAPI}-autoconf-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm611 @end example612 613 @b{NOTE}: It may be necessary to remove the build tree in the @code{BUILD}614 directory under the RPM root directory.615 616 @c617 @c Building AUTOMAKE using RPM618 @c619 @subsection Building AUTOMAKE using RPM620 621 This section illustrates the invocation of RPM to build a new, locally622 compiled, AUTOMAKE binary RPM that matches the installed source RPM.623 This example assumes that all of the required source is installed.624 625 @example626 rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-automake-<VERSION>-<RPM_RELEASE>.src.rpm627 @end example628 629 @example630 cd <RPM_ROOT_DIRECTORY>/SPECS631 rpm -bb i386-rtems@value{RTEMSAPI}-automake-<VERSION>.spec632 @end example633 634 If the build completes successfully, RPMS like the following will be635 generated in a build-host architecture specific subdirectory of the RPMs636 directory under the RPM root directory.637 638 @example639 @value{RTEMSRPMPREFIX}rtems@value{RTEMSAPI}-automake-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm640 @end example641 642 @b{NOTE}: It may be necessary to remove the build tree in the @code{BUILD}643 directory under the RPM root directory.644 645 646 @c647 @c Building BINUTILS using RPM648 @c649 @subsection Building BINUTILS using RPM650 651 This section illustrates the invocation of RPM to build a new, locally652 compiled, binutils binary RPM that matches the installed source RPM.653 This example assumes that all of the required source is installed.654 655 @example656 rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-binutils-<VERSION>-<RPM_RELEASE>.src.rpm657 @end example658 659 @example660 cd <RPM_ROOT_DIRECTORY>/SPECS661 rpm -bb i386-rtems@value{RTEMSAPI}-binutils-<VERSION>.spec662 @end example663 664 If the build completes successfully, RPMS like the following will be665 generated in a build-host architecture specific subdirectory of the RPMS666 directory under the RPM root directory.667 668 @example669 @value{RTEMSRPMPREFIX}binutils-common-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm670 @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-binutils-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm671 @end example672 673 NOTE: It may be necessary to remove the build tree in the @code{BUILD}674 directory under the RPM root directory.675 676 @c677 @c Building GCC and NEWLIB using RPM678 @c679 @subsection Building GCC and NEWLIB using RPM680 681 This section illustrates the invocation of RPM to build a new,682 locally compiled, set of GCC and NEWLIB binary RPMs that match the683 installed source RPM. It is also necessary to install the BINUTILS684 RPMs and place them in your PATH. This example assumes that all of685 the required source is installed.686 687 @example688 cd <RPM_ROOT_DIRECTORY>/SPECS689 rpm -bb i386-rtems@value{RTEMSAPI}-gcc-<VERSION>.spec690 @end example691 692 If the build completes successfully, a set of RPMS like the following will693 be generated in a build-host architecture specific subdirectory694 of the RPMS directory under the RPM root directory.695 696 @example697 @value{RTEMSRPMPREFIX}gcc-common-<VERSION>-<RPM>.<DIST>.noarch.rpm \698 @value{RTEMSRPMPREFIX}newlib-common-<VERSION>-<RPM>.<DIST>.noarch.rpm \699 @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gcc-<VERSION>-<RPM>.<ARCH>.rpm \700 @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-newlib-<VERSION>-<RPM>.<ARCH>.rpm \701 @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-libgcc-<VERSION>-<RPM>.<ARCH>.rpm \702 @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gcc-c++-<VERSION>-<RPM>.<ARCH>.rpm \703 @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-libstd++-<VERSION>-<RPM>.<ARCH>.rpm704 @end example705 706 @b{NOTE}: Some targets do not support building all languages.707 708 @b{NOTE}: It may be necessary to remove the build tree in the709 @code{BUILD} directory under the RPM root directory.710 711 @c712 @c Building the GDB using RPM713 @c714 @subsection Building the GDB using RPM715 716 The following example illustrates the invocation of RPM to build a new,717 locally compiled, binutils binary RPM that matches the installed source718 RPM. This example assumes that all of the required source is installed.719 720 721 @example722 rpm -U @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gdb-<VERSION>-<RPM_RELEASE>.src.rpm723 @end example724 725 @example726 cd <RPM_ROOT_DIRECTORY>/SPECS727 rpm -bb i386-rtems@value{RTEMSAPI}-gdb-<VERSION>.spec728 @end example729 730 If the build completes successfully, RPMS like the following will731 be generated in a build-host architecture specific subdirectory732 of the RPMS directory under the RPM root directory.733 734 @example735 @value{RTEMSRPMPREFIX}gdb-common-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm736 @value{RTEMSRPMPREFIX}i386-rtems@value{RTEMSAPI}-gdb-<VERSION>-<RPM_RELEASE>.<ARCH>.rpm737 @end example738 739 @b{NOTE}: It may be necessary to remove the build tree in the740 @code{BUILD} directory under the RPM root directory.741 742 @c743 @c Common Problems744 @c745 746 @section Common Problems747 748 @subsection Error Message Indicates Invalid Option to Assembler749 750 If a message like this is printed then the new cross compiler751 is most likely using the native assembler instead of the cross752 assembler or vice-versa (native compiler using new cross assembler).753 This can occur for one of the following reasons:754 755 @itemize @bullet756 757 @item Binutils Patch Improperly Applied758 @item Binutils Not Built759 @item Current Directory is in Your PATH760 761 @end itemize762 763 If you are using binutils 2.9.1 or newer with certain older versions of764 gcc, they do not agree on what the name of the newly765 generated cross assembler is. Older binutils called it @code{as.new}766 which became @code{as.new.exe} under Windows. This is not a valid767 file name, so @code{as.new} is now called @code{as-new}. By using the latest768 released tool versions and RTEMS patches, this problem will be avoided.769 770 If binutils did not successfully build the cross assembler, then771 the new cross gcc (@code{xgcc}) used to build the libraries can not772 find it. Make sure the build of the binutils succeeded.773 774 If you include the current directory in your PATH, then there775 is a chance that the native compiler will accidentally use776 the new cross assembler instead of the native one. This usually777 indicates that "." is before the standard system directories778 in your PATH. As a general rule, including "." in your PATH779 is a security risk and should be avoided. Remove "." from780 your PATH.781 782 @b{NOTE}: In some environments, it may be difficult to remove "."783 completely from your PATH. In this case, make sure that "."784 is after the system directories containing "as" and "ld".785 786 @subsection Error Messages Indicating Configuration Problems787 788 If you see error messages like the following,789 790 @itemize @bullet791 792 @item cannot configure libiberty793 @item coff-emulation not found794 @item etc.795 796 @end itemize797 798 Then it is likely that one or more of your gnu tools is799 already configured locally in its source tree. You can check800 for this by searching for the @code{config.status} file801 in the various tool source trees. The following command802 does this for the binutils source:803 804 @example805 find binutils-<VERSION> -name config.status -print806 @end example807 808 The solution for this is to execute the command809 @code{make distclean} in each of the GNU tools810 root source directory. This should remove all811 generated files including Makefiles.812 813 This situation usually occurs when you have previously814 built the tool source for some non-RTEMS target. The815 generated configuration specific files are still in816 the source tree and the include path specified during817 the RTEMS build accidentally picks up the previous818 configuration. The include path used is something like819 this:820 821 @example822 -I../../binutils-<VERSION>/gcc -I/binutils-<VERSION>/gcc/include -I.823 @end example824 825 Note that the tool source directory is searched before the826 build directory.827 828 This situation can be avoided entirely by never using829 the source tree as the build directory. -
doc/started/buildrt.t
rcf404563 rd84995d2 5 5 6 6 @chapter Building RTEMS 7 8 @b{NOTE}: If you built your toolset with RSB, by default the RSB also 9 builds RTEMS while building the compiler toolset. You may already have 10 a built and installed RTEMS in this case, and if not you should check 11 the RSB documentation at @uref{https://docs.rtems.org/rsb/,https://docs.rtems.org/rsb/}. 7 12 8 13 @section Obtain the RTEMS Source Code … … 15 20 16 21 @itemize @bullet 17 @item @uref{http:// www.rtems.org/ftp/pub/rtems,http://www.rtems.org/ftp/pub/rtems}18 @item @uref{ftp:// www.rtems.org/pub/rtems,ftp://www.rtems.org/pub/rtems}22 @item @uref{http://ftp.rtems.org/pub/rtems,http://ftp.rtems.org/pub/rtems} 23 @item @uref{ftp://ftp.rtems.org/pub/rtems,ftp://ftp.rtems.org/pub/rtems} 19 24 @end itemize 20 25 … … 48 53 accessing the RTEMS source repository consult: 49 54 50 @uref{http ://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository, http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository}.55 @uref{https://devel.rtems.org/wiki/Developer/Git,https://devel.rtems.org/wiki/Developer/Git}. 51 56 52 57 @section Add <INSTALL_POINT>/bin to Executable PATH … … 57 62 tools. The following command prepends the directory where 58 63 the tools were installed in a previous step. If you are using 59 binaries provided by the RTEMS Project, the <INSTALL_POINT> will be60 @code{/opt/rtems-@value{RTEMSAPI}}64 binaries installed to @code{/opt/rtems-@value{RTEMSAPI}}, then the 65 <INSTALL_POINT> will be @code{/opt/rtems-@value{RTEMSAPI}} 61 66 62 67 @example … … 107 112 108 113 If this produces messages that indicate the assembly code is not valid, 109 then it is likely that you have fallen victim to one of the problems 110 described in @ref{Error Message Indicates Invalid Option to Assembler} 111 Please do not feel bad about this and do not give up, one of the most 112 common installation errors is for the cross-compiler not to be able 113 to find the cross assembler and default to using the native @code{as}. 114 then it is likely that you have fallen victim to one of the most 115 common installation errors and the cross-compiler is not able 116 to find the cross assembler and defaults to using the native @code{as}. 114 117 This can result in very confusing error messages. 115 118 … … 163 166 mkdir build-rtems 164 167 cd build-rtems 165 ../rtems-@value{RTEMSAPI}.VERSION/configure --target=<TARGET_CONFIGURATION> \ 166 --disable-posix --disable-networking --disable-cxx \ 168 ../rtems-@value{RTEMSAPI}.VERSION/configure \ 169 --target=<TARGET_CONFIGURATION> \ 170 --disable-networking \ 167 171 --enable-rtemsbsp=<BSP>\ 168 172 --prefix=<INSTALL_POINT> -
doc/started/intro.t
rcf404563 rd84995d2 137 137 NEWLIB, and GDB with the pre-built versions of those tools. 138 138 139 Much of the documentation is available at other sites on the Internet .140 The following is a list of URLs where one can find HTML versions of 141 the GNU manuals: 139 Much of the documentation is available at other sites on the Internet, 140 for example the GNU manuals are hosted by the Free Software Foundation 141 at @uref{http://www.gnu.org/manual/manual.html, http://www.gnu.org/manual/manual.html}. 142 142 143 @table @b 144 145 @item Free Software Foundation 146 @uref{http://www.gnu.org/manual/manual.html, 147 http://www.gnu.org/manual/manual.html} 148 149 @item Delorie Software 150 @uref{http://www.delorie.com/gnu/docs, http://www.delorie.com/gnu/docs} 151 152 @end table 153 154 155 @subsection RTEMS Mailing List 143 @subsection RTEMS Mailing Lists 156 144 157 145 @uref{mailto:@value{RTEMSUSERS},@value{RTEMSUSERS}} 158 146 159 This is the primary mailing list for the discussion of issues 160 related to RTEMS, including GNAT/RTEMS. If you have questions 161 about RTEMS, wish to make suggestions, track development efforts, 162 or just want to pick up hints, this is a good list to monitor. 147 The users mailing list is for any and all questions about RTEMS, especially 148 those focusing on how to use RTEMS. 163 149 If you would like to browse the thousands of messages in the fifteen 164 150 year archive of the mailing list or subscribe to it, please visit 165 @uref{http ://www.rtems.org/mailman,http://www.rtems.org/mailman} for151 @uref{https://lists.rtems.org/mailman/listinfo/users,https://lists.rtems.org/mailman/listinfo/users} for 166 152 more information, 167 153 168 @ subsection GCC Mailing Lists154 @uref{mailto:@value{RTEMSDEVEL},@value{RTEMSDEVEL}} 169 155 170 The GCC Project is hosted at @uref{http://gcc.gnu.org,http://gcc.gnu.org}. 171 They maintain multiple mailing lists that are described at the web site 172 along with subscription information. 156 The devel mailing list is the place to track ongoing RTEMS development 157 and to discuss changes to RTEMS. This list is also where patches are 158 submitted. 159 -
doc/started/require.t
rcf404563 rd84995d2 153 153 @end itemize 154 154 155 @subsection GNU/Linux Distributions using Debian Packaging Format156 157 The RTEMS Project does not currently provide prebuilt toolsets in the Debian packaging format used by the Debian and Ubuntu distributions. If you are using a distribution using this packaging format, then you have two options for installing the RTEMS toolset.158 159 The first option is to build the toolset from source following the instructions in the @ref{Building the GNU Cross Compiler Toolset}. This is an approach taken by many users.160 161 Alternatively, it is often possible to extract the contents of the RPM files which contain the portions of the toolset you require. In this case, you will follow the instructions in @ref{Locating the RPMs for your GNU/Linux Distribution} but assume your distribution is the RedHat Enterprise Linux version which is closest to yours from a shared library perspective. As of December 2010, this is usually RedHat Enterprise Linux version 5. As time passes, it is expected that version 6 will be appropriate in more cases. You will extract the contents of these RPM files using either @code{rpm2cpio} and install them or you may be able to use the @code{alien} tool to convert them to Debian packaging. -
doc/started/started.texi
rcf404563 rd84995d2 65 65 * Introduction:: 66 66 * Requirements:: 67 * Prebuilt Toolset Executables:: 68 * Building the GNU Cross Compiler Toolset:: 67 * Building the GNU Cross Compiler Toolset with RSB:: 69 68 * Building RTEMS:: 70 69 * Building the Sample Applications:: … … 78 77 @include intro.texi 79 78 @include require.texi 80 @include binaries.texi81 79 @include buildc.texi 82 80 @include buildrt.texi
Note: See TracChangeset
for help on using the changeset viewer.