Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
VxWorks
®
6.7
Copyright © 2008 Wind River Systems, Inc.
All rights reserved. No part of this publication may be reproduced or transmitted in any
form or by any means without the prior written permission of Wind River Systems, Inc.
Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc.
The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party
trademarks referenced are the property of their respective owners. For further information
regarding Wind River trademarks, please see:
http://www.windriver.com/company/terms/trademark.html
This product may include software licensed to Wind River by third parties. Relevant
notices (if any) are provided in your product installation at the following location:
installDir/product_name/3rd_party_licensor_notice.pdf.
Wind River may refer to third-party documentation by listing publications or providing
links to third-party Web sites for informational purposes. Wind River accepts no
responsibility for the information provided in such third-party documentation.
Corporate Headquarters
Wind River Systems, Inc.
500 Wind River Way
Alameda, CA 94501-1153
U.S.A.
For additional contact information, please visit the Wind River URL:
http://www.windriver.com
For information on how to contact Customer Support, please visit the following URL:
http://www.windriver.com/support
2 Dec 08
Part #: DOC-16305-ND-00
Contents
1 Overview ............................................................................................... 1
iii
VxWorks
Command-Line Tools User's Guide, 6.7
iv
Contents
4.7 Building Kernel Applications for UP, SMP, and VSB Variants .................... 45
4.7.1 Building Applications With Default VxWorks UP Libraries ............ 45
v
VxWorks
Command-Line Tools User's Guide, 6.7
vi
Contents
5.11 Compiler Options for Shared Objects and Dynamic RTP Applications .... 64
5.11.1 Options for Shared Objects ..................................................................... 64
5.11.2 Options for Dynamic RTP Application Executables ........................... 65
Identifying the Run-time Paths of Shared Libraries ........................... 65
Index .............................................................................................................. 81
vii
VxWorks
Command-Line Tools User's Guide, 6.7
viii
1
Overview
1.1 Introduction 1
1.2 Related Documentation 2
1.1 Introduction
This guide describes how to use the command-line build environment provided
with VxWorks. It complements the Wind River Workbench by Example guide for
programmers who prefer to do development tasks outside of the Workbench
graphical interface or who need to create scripted build environments.
The Workbench IDE includes many features, such as code browsing, host-target
communication, and multicore debugging, that are not available from the
command line. For a complete description of the Workbench environment, see the
Wind River Workbench by Example guide, which also provides information about
setting up the host-target development environment.
For information about the VxWorks operating system and developing applications
that run under it, see the VxWorks Kernel Programmer’s Guide and VxWorks
Application Programmer’s Guide.
VxWorks ships with two compilers and associated toolchains: the Wind River
Compiler (sometimes called the Diab compiler) and GCC (part of the GNU
project). Both toolchains use the GNU make utility for VxWorks application
development. To the largest extent possible, these toolchains have been designed
1
VxWorks
Command-Line Tools User's Guide, 6.7
for interoperability, but it is not always safe to assume that code written for one set
of tools will work perfectly with the other. While examples in this guide may use
either or both compilers, it is best to select one compiler and toolchain before
starting a project.
The Wind River Compiler and tools are documented in a separate user’s guide for
each supported target architecture. For example, information about the PowerPC
compiler is in the Wind River Compiler for PowerPC User’s Guide. GCC and the other
GNU tools are documented in a series of manuals from the Free Software
Foundation, which are provided with this release.
NOTE: Throughout this guide, UNIX refers to both Solaris and Linux host
development environments. Windows refers to all supported versions of Microsoft
Windows. Examples in this guide include both UNIX and Windows command
lines. It is assumed that the reader can make appropriate modifications—such as
changing forward slashes (/) to backward slashes (\)—depending on the
environment.
NOTE: For information about building the VxWorks networking and middleware
products that are delivered only in source code format, see the Wind River VxWorks
Platforms User’s Guide.
2
1 Overview
1.2 Related Documentation
■
VxWorks Device Driver Developer’s Guide
1
3
VxWorks
Command-Line Tools User's Guide, 6.7
4
2
Setting Environment Variables
2.1 Introduction 5
2.2 Setting Environment Variables With wrenv 6
2.3 How wrenv Works 7
2.4 wrenv Command Options 8
2.1 Introduction
To use the command-line development environment for VxWorks, you need to
configure environment variables and other settings. The best way to do this is with
the Wind River environment utility, wrenv. The utility guarantees a consistent,
portable execution environment for tools (such as make) that are launched from
Wind River Workbench or from a command-line automation environment such as
the VxWorks Development Shell. The wrenv utility also provides services that
other tools can use to query environment settings that are set by wrenv.
Throughout this guide, whenever host operating system commands are shown or
described, it is assumed that you are working from a properly configured shell
created with wrenv.
5
VxWorks
Command-Line Tools User's Guide, 6.7
On Solaris and Linux, you must set the environment variables whether you use
Workbench or the command line. In your installation directory, run the following
command in a shell:
% ./wrenv.sh -p vxworks-6.x
NOTE: If your shell configuration file (.profile, .cshrc, .tcshrc, and so forth)
overwrites the environment each time a new shell is created, the above command
may not work. To test whether the environment variables have been set
successfully, start Workbench. If you find that you cannot start the Workbench
tools after running the above command, use the following command:
% eval `installDir/wrenv.sh -p platform -o print_env -f shell`
where shell is sh or csh, depending on the current shell program. For example:
% eval `./wrenv.sh -p vxworks-6.x -o print_env -f sh`
Windows
If you use the VxWorks Development Shell, environment variables are set
automatically. To start the shell, select
Start > All Programs > Wind River > VxWorks 6.x and
General Purpose Technologies > VxWorks Development Shell.
You can also invoke wrenv from the command prompt, as follows:
C:\> installDir\wrenv.exe -p vxworks-6.x
In some cases, it is not desirable to start a shell—for example, when you are using
scripting to set the environment on a host, or when you cannot start a shell because
your .cshrc or .profile file overrides PATH or other variables whenever a shell is
started.
6
2 Setting Environment Variables
2.3 How wrenv Works
In these cases, the following command can be used to output the environment
variables to standard out:
2
On Linux and Solaris hosts:
% wrenv.sh –p vxworks-6.x –o print_env –f format
On Windows hosts:
C:\> wrenv.exe -p vxworks-6.x print_env -f format
In this example, format specifies the output format or shell type, which can be set
to plain, sh, csh, bat, or tcl.
For example, to set the environment in csh on a Linux or Solaris host without
starting a sub-shell, use the following command:
% eval 'wrenv.sh –p vxworks-6.x –o print_env –f csh'
Or, to set the environment in tcl on a Windows host without starting a sub-shell,
use the following command:
For example, to set the environment in tcl without starting a sub-shell, use the
following command:
C:\> eval 'wrenv.exe –p vxworks-6.x –o print_env –f tcl'
7
VxWorks
Command-Line Tools User's Guide, 6.7
On Windows hosts:
C:\> wrenv.exe options env=value command [args]
-f format Select format for print_env or print_vars (see -o): C:\> wrenv -p vxworks-6.x -o
print_vars -f sh
plain (the default)
sh
csh
bat
tcl
8
2 Setting Environment Variables
2.4 wrenv Command Options
9
VxWorks
Command-Line Tools User's Guide, 6.7
-r root Specify the root path for a package. (Overrides the C:\> wrenv -p vxworks-6.x -r
default method of finding packages.) Usually, the directory
root path is a directory under installDir that has the
same name as the package.
env=value Set the specified variable in addition to other C:\> wrenv -p vxworks-6.x
PATH=directory
environment settings. Overrides
install.properties.b env=value must be the last item
on the command line, except for command [args] (see
below).
command Execute the specified command in the new shell % wrenv.sh -p vxworks-6.x ls
[args] environment. (Does not open a new shell.) Must be *.sh
the last item on the command line.
a. These operations are primarily for internal use and may change in later releases.
b. Once a setting has been overridden with this option, wrenv maintains the override on subsequent
executions—even if the option is omitted from the command line—as long as the new shell is running. A
list of overridden settings is stored in a temporary variable called WIND_PROTECTED_ENV that
disappears when the shell terminates.
10
3
Configuring and Building
VxWorks
3.1 Introduction 11
3.2 Working With VxWorks Image Projects: VIPs 12
3.3 Working With VxWorks Source Build Projects: VSBs 26
3.4 Building Customized VxWorks Source Code 36
3.1 Introduction
VxWorks is a highly scalable operating system that can be configured and
customized in a variety of ways. VxWorks image projects (VIPs) allow for
configuring a system with selected standard components that provide default
libraries. VIPs also provide configuration parameters for modifying the behavior
of individual components. VxWorks Source Build projects (VSBs) provide options
that allow for creating systems based on variants of standard libraries and other
optimizations. In addition, VxWorks source code itself can be directly customized
(edited), and the libraries rebuilt. The vxprj tool and the VxWorks build
environment provide the means for most of the configuration and build activities
involved with these approaches to configuring and customizing operating system.
NOTE: For information about building the VxWorks networking and middleware
products that are delivered only in source code format, see the Wind River VxWorks
Platforms User’s Guide.
11
VxWorks
Command-Line Tools User's Guide, 6.7
NOTE: This section provides an overview of the vxprj functionality that you use to
create and work with VIPs.
For a complete description of vxprj and all of its options, see the vxprj reference
entry in the Wind River Project Configuration Command-Line API Reference. In
addition you may use the help provided by the tool itself, with the following
syntax:
vxprj help
vxprj featureName help
where help for featureName is available for certain elements, such as build,
buildmacro, component, and so on.
Environment variables are set automatically if you are using the VxWorks
Development Shell on Windows. Otherwise you must use the wrenv utility to set
them. For more information, see 2.2 Setting Environment Variables With wrenv, p.6.
The command-line vxprj utility creates a project based on an existing board support
package (BSP).1 The syntax for creating a VIP is as follows:
vxprj create [-smp] [-profile profile] [-vsb vsbdir] BSP tool [projectFile|projectDirectory]
For example:
C:\>vxprj create -profile PROFILE_DEVELOPMENT mv5100 diab c:\mv5100VIP
1. For information about BSPs, see the VxWorks BSP Developer’s Guide.
12
3 Configuring and Building VxWorks
3.2 Working With VxWorks Image Projects: VIPs
Note that if the VIP is based on an SMP VxWorks source build (VSB) project
(see -vsb vsbdir, p.13), and -smp is not specified when the VIP is created, the
VIP inherits the SMP specification from the VSB project anyway. For
information about VSB projects, see 3.3 Working With VxWorks Source Build
Projects: VSBs, p.26 and the VxWorks Kernel Programmer’s Guide: Kernel Facilities
and Kernel Configuration.
-profile profile
An optional argument to specify the kernel profile type to be built. If you do
not specify a profile, the project is built according to the default profile that is
defined for your BSP. For information on profiles, see Using Profiles, p.15, and
the VxWorks Kernel Programmer’s Guide.
-vsb vsbdir
An optional argument that specifies a VxWorks source build (VSB) project on
which to base the VIP. Essentially, it points to a variant set of libraries instead
of the default VxWorks libraries provided in the VxWorks installation. For
detailed information about VSBs, see 3.3 Working With VxWorks Source Build
Projects: VSBs, p.26 and the VxWorks Kernel Programmer’s Guide: Kernel Facilities
and Kernel Configuration.
BSP
The name or location of a BSP.
tool
A supported compiler (usually diab or gnu). See Checking the Toolchain, p.14
for information about determining valid compilers for a given BSP.
projectFile|projectDirectory
An optional argument to specify the name of the project file to create, or the
name of its parent directory. If no filename or directory is specified, vxprj
generates a name based on the other input arguments and stores the resulting
project in a new directory under installDir/vxworks-6.x/target/proj.
13
VxWorks
Command-Line Tools User's Guide, 6.7
If you do not have a target board for your application, the easiest way to
experiment with vxprj is to create projects for the VxWorks Simulator. For
example:
C:\> vxprj create simpc diab C:\myProj\myproj.wpj
This command creates a kernel configuration project to be built with the Wind
River compiler (diab) and run on the VxWorks Simulator for Windows (simpc).
The project file (myproj.wpj), source files, and makefile are stored in C:\myProj.
To generate a similar project for Solaris or Linux hosts, specify solaris or linux as
the BSP, type the following:
% vxprj create solaris diab /myProj/myproj.wpj
(For more information about the VxWorks Simulator, see the Wind River VxWorks
Simulator User’s Guide.)
The following command creates a project in the default location using the
wrSbcPowerQuiccII (PowerPC) board support package:
% vxprj create wrSbcPowerQuiccII diab
When you execute this command, vxprj creates a subdirectory for the new project
and reports the location of directory.
You can use vxprj to check the valid toolchains for a BSP using the following
syntax:
vxprj tccheck list bspName
For example:
% C:\WindRiver>vxprj tccheck list mv5100
diab gnu
Copying VIPs
If no source file is specified, vxprj looks for a .wpj file in the current directory. If a
destination directory—but no destination filename—is specified, vxprj creates a
project file with the same name as the directory it resides in. For example:
14
3 Configuring and Building VxWorks
3.2 Working With VxWorks Image Projects: VIPs
3
Using Profiles
The profile affects only the components used to create the project: after creation,
the project does not retain any information about the profile used to create it.
For a description of profiles, see the VxWorks Kernel Programmer’s Guide.
where projectFile is the .wpj file associated with the project. The delete command
permanently deletes the directory in which projectFile resides and all of its contents
and subdirectories. (Do not run the command from the project directory you are
trying to remove.) For example:
% vxprj delete /myProj/myproj.wpj
! CAUTION: vxprj delete removes any file passed to it, regardless of the file’s name
or extension, along with the entire directory in which the file resides. It does not
verify that the specified file is a Workbench project file, nor does it attempt to save
user-generated files.
15
VxWorks
Command-Line Tools User's Guide, 6.7
Adding Components
If no project file is specified, vxprj looks for a .wpj file in the current directory and
adds the specified components to that file. Components are identified by the
names used in .wpj and .cdf files, which have the form INCLUDE_xxx. For
example:
% cd MyProject
% vxprj component add INCLUDE_MMU_BASIC INCLUDE_ROMFS
This command adds support for a memory management unit and the ROMFS
target file system to MyProject.wpj.
For information about listing components, see Listing Components, p.18.
Adding Bundles
Some components are grouped into bundles that provide related or complementary
functionality. Adding components in bundles is convenient and avoids unresolved
dependencies.
To add a bundle to a project, type the following:
vxprj bundle add [projectFile] bundle [bundle ... ]
For example:
% cd MyProject
% vxprj bundle add BUNDLE_RTP_DEVELOP
This command adds process (RTP) support to the VIP in the current working
directory.
% vxprj bundle add MyProject.wpj BUNDLE_RTP_DEVELOP
BUNDLE_STANDALONE_SHELL BUNDLE_POSIX BUNDLE_EDR
This command adds support for processes, the kernel shell, POSIX, and error
detection and reporting to MyProject.wpj.
For information about listing bundles, see Listing Bundles, p.19.
16
3 Configuring and Building VxWorks
3.2 Working With VxWorks Image Projects: VIPs
Removing Components
This command removes the specified components as well as any components that are
dependent on them.
Removing Bundles
If no project file is specified, vxprj looks for a .wpj file in the current directory. For
example:
% vxprj parameter set MyProject.wpj VM_PAGE_SIZE 0x10000
17
VxWorks
Command-Line Tools User's Guide, 6.7
If no project file is specified, vxprj looks for a .wpj file in the current directory. For
example:
% vxprj makefile make.rules
This command changes the name of the makefile (for the project in the current
working directory) from the default Makefile to make.rules.
To link a kernel application with the VxWorks kernel image, the source file must
be added to the project. To add a specific source code file to a VIP, type the
following:
vxprj file add [projectFile] sourceFile
If no project file is specified, vxprj looks for a .wpj file in the current directory.
When the project is built, the specified source file is compiled and linked into the
resulting kernel image.
To remove a file from a project, type the following:
vxprj file remove [projectFile] sourceFile
Listing Components
18
3 Configuring and Building VxWorks
3.2 Working With VxWorks Image Projects: VIPs
If no project file is specified, vxprj looks for a .wpj file in the current directory. If
pattern is specified, vxprj lists only components whose names contain pattern as a
substring; if pattern is omitted, all components are listed.
The type argument can be all, included, excluded, or unavailable. The default is 3
included, which lists components included in the project. Specify excluded to list
installed components that are not included in the project; all to list all installed
components; or unavailable to list components that are installed but not available
for the project. (An available component is one that is installed, with all its
dependent components, under the VxWorks directory.)
For example:
% vxprj component list MyProject.wpj SHELL
This command returns all available components with names containing “VM”
that are not included in MyProject.wpj.
Listing Bundles
Listing Profiles
19
VxWorks
Command-Line Tools User's Guide, 6.7
Comparing Projects
If only one project file or directory is specified, vxprj looks for a .wpj file in the
current directory and compares it to the specified project. For example:
% vxprj component diff /Apps/SomeProject.wpj
Checking a Component
If no project file is specified, vxprj looks for a .wpj file in the current directory. If
no component is specified, vxprj checks every component in the project. For
example:
% vxprj component check MyProject.wpj
This command invokes the cmpTest routine, which tests for syntactical and
semantic errors.
If no project file is specified, vxprj looks for a .wpj file in the current directory. For
example:
% vxprj component dependencies INCLUDE_OBJ_LIB
20
3 Configuring and Building VxWorks
3.2 Working With VxWorks Image Projects: VIPs
If no project file is specified, vxprj looks for a .wpj file in the current directory. If
pattern is specified, vxprj lists only parameters whose names contain pattern as a
substring; if pattern is omitted, all parameters are listed. For example: 3
% vxprj parameter list MyProject.wpj TCP
The first command lists all parameters and values for the project in the current
directory. The second lists only parameters whose names contain “USER” and
whose values contain “TRUE”.
If only one project file or directory is specified, vxprj looks for a .wpj file in the
current directory and compares it to the specified project. For example:
% vxprj parameter diff /MyProject/MyProject.wpj /Apps/SomeProject.wpj
21
VxWorks
Command-Line Tools User's Guide, 6.7
If no project file is specified, vxprj looks for a .wpj file in the current directory. If
pattern is specified, vxprj lists only files whose names contain pattern as a substring;
otherwise, all files are listed.
To see build information for a source code file, type the following:
vxprj file get [projectFile] sourceFile
A VxWorks image project includes build rules based on the format used in
makefiles. Projects also include build specifications, which organize and configure
build rules.
A build specification defines variables passed to make and flags passed to the
compiler. Each project has a current build specification, initially defined as default.
The build specifications that are available for a given project depend on the type of
project and BSP, but a typical project might have four build specifications: default,
default_rom, default_romCompress, and default_romResident.
You must use an appropriately paired build specification and build rule to create
a specific VxWorks image type (the names of the build rules and images are the
same).
! CAUTION: The build specification and build rule must match. If they do not match,
in most cases the build will simply fail; in other cases, linkage occurs but the build
output will be inconsistent.
The common build specifications, build rules, image types, and their association
are described in Table 3-1.
Table 3-1 VxWorks Build Specifications, Build Rules, and Image Types
22
3 Configuring and Building VxWorks
3.2 Working With VxWorks Image Projects: VIPs
Table 3-1 VxWorks Build Specifications, Build Rules, and Image Types (cont’d)
For more information about VxWorks image types, see the VxWorks Kernel
Programmer’s Guide.
To display the available build specifications, use the build list option for vxprj in the
project directory. For example:
C:\workspace\myVip>vxprj build list
default
default_rom
default_romCompress
default_romResident
To determine what build rules are available for your BSP, use the buildrule list
option for vxprj in the project directory. For example:
C:\workspace\myVip>vxprj buildrule list
vxWorks
linkSyms.o
prjConfig.o
romInit.o
romStart.o
sysALib.o
sysLib.o
vxWorks_rom
vxWorks_rom.bin
vxWorks_rom.hex
vxWorks_romCompress
vxWorks_romCompress.bin
vxWorks_romCompress.hex
vxWorks_romResident
vxWorks_romResident.bin
vxWorks_romResident.hex
For more on getting information about build specifications, see Examining Build
Specifications and Rules, p.24.
23
VxWorks
Command-Line Tools User's Guide, 6.7
Before you build VxWorks, you must first use the following command to set the
build specification if you are not going to use the default:
vxprj build set buildSpecification
For example:
vxprj build set default_rom
For more information about changing build settings, see Changing Build
Specifications, p.24.
To see the name of the current build specification, type the following:
vxprj build get [projectFile]
If no project file is specified, vxprj looks for a .wpj file in the current directory. To
see all available build specifications for a project, type the following:
vxprj build list [projectFile]
To see all the build rules in a project’s current build specification, type the
following:
vxprj buildrule list [projectFile]
For example:
% vxprj buildrule get prjConfig.o
If no project file is specified, vxprj looks for a .wpj file in the current directory. For
example, the following command changes the current build specification of
myproj.wpj to default_romCompress:
24
3 Configuring and Building VxWorks
3.2 Working With VxWorks Image Projects: VIPs
To reset a project’s current build specification to its default, type the following:
vxprj build reset [projectFile]
3
The set and reset commands update a project’s makefile as well as its .wpj file.
The commands documented below edit project makefiles and .wpj files.
To add a build rule to a project’s current build specification, type the following:
vxprj buildrule add [projectFile] buildRule value
If no project file is specified, vxprj looks for a .wpj file in the current directory. For
example:
% vxprj buildrule add default_new "$(CC) $(CFLAGS) ./prjConfig.c -o $@"
This command creates a build rule (if it doesn’t already exist) called default_new,
adds it to the current build specification, and sets its value to
$(CC) $(CFLAGS) ./prjConfig.c -o $@.
To create or edit a build rule without including it in the project’s current build
specification, type the following:
vxprj buildrule set [projectFile] buildRule value
Rules created with set are added to the list of available build rules for the current
build specification.
To remove a build rule from a project, type the following:
vxprj buildrule remove [projectFile] buildRule
To set the default build rule for the current build specification, type the following:
vxprj buildrule [projectFile] buildRule
For example:
% vxprj buildrule default_new
Building VxWorks
25
VxWorks
Command-Line Tools User's Guide, 6.7
If no project file is specified, vxprj looks for a .wpj file in the current directory. If
the second argument is omitted, vxprj uses the project’s current build
specification. Output from the compiler is saved in a subdirectory—with the same
name as the build specification—under the project’s source directory. Two
examples are as follows:
% vxprj build
The first command builds the project found in the current directory using the
project’s current build specification. The second command builds the project
defined in myproj.wpj using the default_rom build specification.
The following sample vxprj session creates an SMP kernel for the pcPentium4 BSP
using the diab compiler in the directory pcPentium4_diab (relative to the current
directory). In addition to the basic operations of creating and building the project,
this example demonstrates the addition of bundles, components, and build
macros.
% vxprj create -smp pcPentium4 diab pcPentium4_diab
% cd pcPentium4_diab
% vxprj bundle add pcPentium4_diab.wpj BUNDLE_STANDALONE_SHELL
% vxprj bundle add pcPentium4_diab.wpj BUNDLE_RTP_DEVELOP
% vxprj bundle add pcPentium4_diab.wpj BUNDLE_POSIX
% vxprj component add pcPentium4_diab.wpj INCLUDE_HRFS
% vxprj component add pcPentium4_diab.wpj INCLUDE_HRFS_FORMAT
% vxprj component add pcPentium4_diab.wpj INCLUDE_RAM_DISK
% vxprj parameter setstring RAM_DISK_DEV_NAME /hrfs0
% vxprj buildmacro add ROMFS_DIR
% vxprj buildmacro set ROMFS_DIR ./romfs
% vxprj build pcPentium4_diab.wpj
26
3 Configuring and Building VxWorks
3.3 Working With VxWorks Source Build Projects: VSBs
APIs provided with standard VxWorks components. In order to make use of the
variant libraries and optimizations in a VxWorks system, you must create a
VxWorks image project (VIP) and associate it with the VSB project. Then use the
VIP to configure the system itself.
3
For a general discussion of VSB projects, as well as the core OS VSB options, see the
VxWorks Kernel Programmer’s Guide. For information about other VSB options, see
the relevant programmer’s guides for the technology in question and the Platform
user’s guide. You can also use Workbench or vxprj to list the VSB options available
with your installation.
For basic tool commands, see the vxprj entry in the Wind River Project Configuration
Command-Line API Reference; and from the command-line, use the vxprj vsb help
command.
NOTE: VSB projects can only be used to create variants of kernel libraries. They
cannot be used to create variants of user (RTP) libraries.
NOTE: The standard VxWorks libraries are built using a VSB project with the
default options.
! CAUTION: Kernel applications that are intended for use with systems based on
VSB projects must be built specifically for those configurations of VxWorks. For
information in this regard, see 4.7 Building Kernel Applications for UP, SMP, and VSB
Variants, p.45.
Using VSB projects to configure and build VxWorks involves the following basic
steps:
1. Create a VSB project, select the desired VSB options, and then build the project
to create specialized variants of VxWorks libraries and utilize other
optimizations.
2. Create a VxWorks image project (VIP) based on the VSB project.
3. Using the VIP, configure VxWorks in the standard way with the desired
components, and then build the project to create a system image based on the
specialized library variants.
27
VxWorks
Command-Line Tools User's Guide, 6.7
The following sections describe how to perform the first two steps of this process.
For information about the third, see 3.2 Working With VxWorks Image Projects: VIPs,
p.12.
Environment variables are set automatically if you are using the VxWorks
Development Shell on Windows. Otherwise you must use the wrenv utility to set
them. For more information, see 2.2 Setting Environment Variables With wrenv, p.6.
VSB projects can be based on a BSP or CPU type. The advantage of basing a VSB
on a BSP is that the build is optimized for that BSP, providing better performance
and smaller code size. The advantage of basing a VSB on a CPU type is that the
project can be used for all BSPs that support that CPU.
To get a list of the CPU classes available for your project, use the following
command:
vxprj vsb listCpus
The first lists all available BSPs and the second lists only those that support the
specified CPU.
To get a list of BSPs that are supported by an existing project, use the following
command in the VSB project directory:
vxprj vsb listSupportedBsps
28
3 Configuring and Building VxWorks
3.3 Working With VxWorks Source Build Projects: VSBs
-force
Deletes the VSB project directory first, if it already exists. If you do not use this
option, and the project file exists, then a new project directory is created
automatically using the original project directory name with _2 appended (for
3
example, myVsb_2). Additional directories are created and the number
incremented if this process is repeated.
-bsp bsp|bspdir
The name or location of the BSP on which to base the project. Use either -bsp
or -cpu, not both. For example, pcPentium or
installDir/vxworks-6.x/target/config/pcPentium. See 3.3.3 Displaying BSP and
CPU Options for VSB Projects, p.28.
-cpu cpuName
The name of the CPU class on which to base the VSB. Use either -bsp or -cpu,
not both. See 3.3.3 Displaying BSP and CPU Options for VSB Projects, p.28.
vsbfile
A VSB project file name (for example, /home/xeno/myVsb/myVsb.wpj). If this
option is used without -force, and the project file exists, then a new project
directory is created using the original project directory name with _2
appended; for example, myVsb_2. Additional directories are created and the
number incremented if this process is repeated.
vsbdir
The directory path for the VSB project. If you do not specify a project directory
at creation time, the project directory is automatically created below the one in
which the command is executed. The name in this case is based on a prefix
vsb_ plus the BSP or CPU name, depending on which was used for project
creation (for example, vsb_PPC32). If you use this option with -force to remove
an existing project before creating one of the same name, use vsbdir to specify
a directory containing the VSB project file. For example, /home/xeno/myVsb/,
which would hold myVsb.wpj.
-D defFile
Create a VSB project based an existing VSB project configuration file (for
example, using /home/xeno/myVsb/vsb.config). (This option can also be used
to modify an existing project.)
-S
Sets all options to the defaults. The configuration tool runs silently. (This
option can also be used to set an existing project to the defaults.)
29
VxWorks
Command-Line Tools User's Guide, 6.7
Command Example
For example, the following command creates a VSB project based on the PowerPC
architecture:
% vxprj vsb create -bsp mv5100 /home/xeno/myVsb
After creating the project directory and files, vxprj automatically presents a series
of options that can be selected to create custom VxWorks libraries, to select
optimization features, and so on.
The following example illustrates a creation command and the first few VSB
options that are presented. The location of the VSB project is announced in the first
lines of output, which is useful to note if you did not specify the location with the
creation command.
C:\>vxprj vsb create -bsp mv5100 c:\workspace\myVsb
Creating VSB Project ...
{saving the VSB project...}
VSB Project created in : c:/workspace/myVsb
starting VSB configuration...
*
* VxWorks Source Build (VSB) Configuration
*
*
* BSP mv5100 Configuration Options
*
Set advanced options (ADVANCED_OPT) [N/y] (NEW) n
*
* mv5100_CPU = PPC32
*
*
* mv5100_FP = hard
*
*
* mv5100_TOOL = diab
*
*
* mv5100_TOOL2 = gnu
*
Applications TOOL [diab gnu ?] (mv5100_APP_TOOL) [diab] (NEW)
*
* VxWorks Kernel Configuration Options
*
Low-level arch code need not support inconsistent cache modes (PPC_CACHE_MODE_IS_CONSISTENT)
[N/y/?] (NEW)
Enable System Viewer Instrumentation Support (SV_INSTRUMENTATION) [Y/n/?] (NEW) n
Enable Real-Time Process (RTP) Support (RTP) [Y/n/?] (NEW) n
Enable WIND Object Management Support (OBJECT_MANAGEMENT) [Y/n/?] (NEW) n
30
3 Configuring and Building VxWorks
3.3 Working With VxWorks Source Build Projects: VSBs
Additional VSB options are presented after these; some depending on what
technologies have been installed and licensed.
3
VSB Option Selection Syntax
The options have the same meaning as when used to create a project (see
3. Configuring and Building VxWorks), with the additions and differences described
below.
Note that the reference to new VSB options below refers to VSB options that become
available to a project when additional features are installed after a project has been
created.
-d
Reconfigure a project based on a VSB configuration file called
default.vxconfig. The file must be located in the directory of the project that is
to be modified.
31
VxWorks
Command-Line Tools User's Guide, 6.7
-D defFile
Reconfigure a project based on another VSB project configuration file (for
example, using /home/xeno/myVsb/vsb.config). Any new VSB options are
added with the default settings.
-o
Run the configuration tool, but prompt only for any new VSB options that
have become available (through installation of other features) since the project
was created. This option provides the means for adding them to a project.
-s
Reconfigure a project based on an existing VSB project. The configuration tool
runs silently. A defFile is created in each VSB project directory (for example,
/home/xeno/myVsb/vsb.config). The user is, however, prompted for any new
VSB options that have become available (through installation of other features)
since the project was created.
-S
Reset a VSB project to the default options. The configuration tool runs silently.
To change the CPU on which a VSB project is based, use the following command
syntax:
vxprj vsb setCpu cpuName [vsbfile|vsbdir] [-d|-D defFile |-o |-s|-S]
Options in addition to CPU are available because changing the CPU causes the
interactive VSB option selection process to be restarted, and the vxprj vsb
command options provide various ways to manage selection.
Note that the reference to new VSB options below refers to VSB options that become
available to a project when additional features are installed after a project has been
created.
The options have the same meaning as when used to create a project (see
3. Configuring and Building VxWorks), with the following additions and differences:
-d
Reconfigure a project based on a VSB configuration file called
default.vxconfig. The file must be located in the directory of the project that is
to be modified.
32
3 Configuring and Building VxWorks
3.3 Working With VxWorks Source Build Projects: VSBs
-D defFile
Reconfigure a project based on another VSB project configuration file (for
example, using /home/xeno/myVsb/vsb.config). Any new VSB options are
added with the default settings.
3
-o
Run the configuration tool, but prompt only for any new VSB options that
have become available (through installation of other features) since the project
was created. This option provides the means for adding them to a project.
-s
Reconfigure a project based on an existing VSB project. The configuration tool
runs silently. A defFile is created in each VSB project directory (for example,
/home/xeno/myVsb/vsb.config). The user is, however, prompted for any new
VSB options that have become available (through installation of other features)
since the project was created.
-S
Reset a VSB project to the default options. The configuration tool runs silently.
To change (or set) the BSP on which a VSB project is based, use the following
command syntax:
vxprj vsb setBsp bsp|bspdir [vsbfile|vsbdir] [-d|-D defFile|-o |-s|-S]
Options in addition to BSP are available because changing the BSP causes the
interactive VSB option selection process to be restarted, and the vxprj vsb options
provide various ways to manage selection (for example, to only deal with new
items).
Note that the reference to new VSB options below refers to VSB options that become
available to a project when additional features are installed after a project has been
created.
The options have the same meaning as when used to create a project (see
3. Configuring and Building VxWorks), with the following additions and differences:
-d
Reconfigure a project based on a VSB configuration file called
default.vxconfig. The file must be located in the directory of the project that is
to be modified.
33
VxWorks
Command-Line Tools User's Guide, 6.7
-D defFile
Reconfigure a project based on another VSB project configuration file (for
example, using /home/xeno/myVsb/vsb.config). Any new VSB options are
added with the default settings.
-o
Run the configuration tool, but prompt only for new options. New options
may be available to a project if additional features are installed after a project
has been created, and this option provides the means for adding them to a
project.
-s
Reconfigure a project based on an existing VSB project. The configuration tool
runs silently. A defFile is created in each VSB project directory; for example,
/home/xeno/myVsb/vsb.config.
-S
Reset a VSB project to the default options. The configuration tool runs silently.
34
3 Configuring and Building VxWorks
3.3 Working With VxWorks Source Build Projects: VSBs
In order to use the customized libraries that you have created with a VSB project—
instead of the default libraries provided with the product installation—you must
associate a VxWorks image project (VIP) with the VSB project. You can make this
association when you create the VIP or afterwards.
To associate a VIP with a VSB when the VIP is created, use the -vsb option with
vxprj create. For example:
% vxprj create wrSbc8560 diab -vsb /home/xeno/myVsb /home/xeno/myVip
To associate a VIP with a VSB after the VIP is created, use the following command
syntax:
vxprj vsb set [prjfile|prjdir] [vsbfile|vsbdir|-default]
The -default option sets the VIP to use default libraries (in target/lib or
target/lib_smp) instead of VSB libraries. The selection of UP or SMP default
libraries is made automatically based on the selection for the VIP itself (that is,
without or with the -smp option).
For detailed information about VxWorks image projects, see 3.2 Working With
VxWorks Image Projects: VIPs, p.12.
To identify which VSB (if any) a VIP is associated with, use the following command
syntax:
vxprj vsb info [prjfile|prjdir]
For example:
C:\workspace\mv5100VIP>vxprj vsb info
VSB directory is set to ./../myPpc32Vsb
35
VxWorks
Command-Line Tools User's Guide, 6.7
If the VIP is not associated with a VSB, the output of the command indicates that
it is associated with the default installed libraries, as follows:
C:\workspace\mv5100VIP_3>vxprj vsb info
VSB directory is set to C:/WindRiver/vxworks-6.7/target/lib
To check that the association of a VSB and a VIP is valid, use the following
command syntax:
vxprj check
NOTE: You can rebuild kernel libraries (whether UP or SMP) with either the VSB
or direct make method. You must rebuild user-mode (RTP) libraries with the make
method—they cannot be rebuilt with VSB projects.
36
3 Configuring and Building VxWorks
3.4 Building Customized VxWorks Source Code
There are some limitations and restrictions you must be aware of when
recompiling the VxWorks source:
3
■
You must build the source code in the vxworks-6.x installation tree with the
host tools and makefiles provided with the VxWorks installation.
■ There may be certain portions of VxWorks object code for which source code
has not been provided. See 3.4.2 Third-Party Binary Files, p.37.
■ Modifications to the source code may not be covered by Wind River Customer
Support.
Due to licensing restrictions, the VxWorks source code does not include source files
licensed by Wind River from third parties. This code is instead distributed in the
form of binary (.o) files.
When you build the VxWorks source code, the third-party binaries are copied
automatically into the source build directory.
Third party binaries are located in installDir/vxworks-6.x/target/precomp. For a
complete list of the affected files and architectures, search this directory for files
with a .o extension.
The VxWorks library source code and archives are installed in the following
locations:
UP Kernel
installDir/vxworks-6.x/target/src
installDir/vxworks-6.x/target/lib
37
VxWorks
Command-Line Tools User's Guide, 6.7
SMP Kernel
installDir/vxworks-6.x/target/src
installDir/vxworks-6.x/target/lib_smp
User (RTP)
installDir/vxworks-6.x/target/usr/src
installDir/vxworks-6.x/target/usr/lib
Environment variables are set automatically if you are using the VxWorks
Development Shell on Windows. Otherwise you must use the wrenv utility to set
them. For more information, see 2.2 Setting Environment Variables With wrenv, p.6.
For information about using VSB projects, see 3.3 Working With VxWorks Source
Build Projects: VSBs, p.26.
To build VxWorks from source using the make command directly, execute the
make command with the appropriate CPU and TOOL variable assignments in the
appropriate source directory.
For information about the CPU and TOOL variables, see the VxWorks Architecture
Supplement.
38
3 Configuring and Building VxWorks
3.4 Building Customized VxWorks Source Code
NOTE: You can build a debug version of the source by providing a -g flag with
ADDED_CFLAGS and ADDED_C++FLAGS in the following file:
installDir/vxworks-6.x/target/src/Makefile
3
Or use the variables from the command-line as follows:
% make CPU=cpuVal TOOL=toolChain ADDED_CFLAGS+=-g ADDED_C++FLAGS+=-g
For SMP libraries, execute the make command using the following syntax:
make CPU=cpuName TOOL= toolchain VXBUILD=SMP
39
VxWorks
Command-Line Tools User's Guide, 6.7
40
4
Building Kernel Applications
and Libraries
4.1 Introduction 42
4.2 About Building Kernel Applications and Libraries 42
4.3 Setting Environment Variables 42
4.4 Using the VxWorks Build Environment 43
4.5 Example Makefile for a Kernel Application 43
4.6 Setting CPU and TOOL Make Variables 44
4.7 Building Kernel Applications for UP, SMP, and VSB Variants 45
4.8 Linking Kernel Application Modules 47
4.9 Linking Kernel Application Modules With VxWorks 47
4.10 make Variables for Kernel Applications and Libraries 48
4.11 Running Kernel Applications 49
41
VxWorks
Command-Line Tools User's Guide, 6.7
4.1 Introduction
This chapter explains how to build VxWorks kernel applications and associated
libraries using command-line build facilities. You can build applications and
libraries using a default set of makefile rules and make.
You can use kernel applications as downloadable modules or linked with the
VxWorks kernel itself. You can also create custom static libraries for use with
kernel applications.
For detailed information about writing code for kernel applications and libraries,
see the VxWorks Kernel Programmer’s Guide. For information about how to use
Wind River Workbench to build applications and libraries, see the Wind River
Workbench by Example guide.
42
4 Building Kernel Applications and Libraries
4.4 Using the VxWorks Build Environment
include $(WIND_BASE)/target/h/make/defs.vsbvars.mk
# project-specific macros
EXE = hello.out
OBJ = hello.o
SRC = hello.c
# libraries, includes
LIBS =
INCLUDES = -I$(WIND_BASE)/target/h \
-I$(WIND_BASE)/target/h/wrn/coreip
# See Wind River compiler guide for complete details on linker options
# -r retains relocation entries, so the file can be re-input to the linker
LFLAGS = $(TARGET_SPEC) -r
##############################
# generic build targets, rules
43
VxWorks
Command-Line Tools User's Guide, 6.7
# clean up
clean :
rm $(EXE) $(OBJ)
For information about the CPU and TOOL variables, see the VxWorks Architecture
Supplement.
44
4 Building Kernel Applications and Libraries
4.7 Building Kernel Applications for UP, SMP, and VSB Variants
4.7 Building Kernel Applications for UP, SMP, and VSB Variants
The VxWorks CLI build system provides make variables that you can use to build
kernel applications for the following types of VxWorks systems:
■
Uniprocessor (UP) or Symmetric multiprocessor (SMP) systems using the 4
default libraries provided with the VxWorks distribution. These systems are
configured simply using a VxWorks image project (VIP).
■ UP or SMP systems using variant (that is, non-default) libraries. These systems
use libraries you create with a VxWorks source build (VSB) project. In order to
make use of the variant libraries, you associate the VIP project for the system
with the VSB project when you configure the system is configured.
For information about configuring VxWorks with a VIP (using the default
libraries), see 3.2 Working With VxWorks Image Projects: VIPs, p.12. For information
about creating variant libraries using a VSB project, and associating a VIP project
with a VSB project, see 3.3 Working With VxWorks Source Build Projects: VSBs, p.26.
The build options described below ensure that the application is linked against the
libraries that are appropriate for the system on which the application will run. That
is, they specify whether an application is linked against UP libraries, SMP libraries,
or variant libraries of either a UP or an SMP variety.
! CAUTION: VxWorks kernel applications must be built specifically for the type of
system on which they will run. Applications built for uniprocessor (UP) VxWorks,
for symmetric multiprocessor (SMP) VxWorks, or for VxWorks systems based on
variant libraries created with a VxWorks source build (VSB) project (either UP or
SMP), are not binary compatible. Note that the loader does not generate an error if
a kernel module is incompatible with the system onto which it is loaded.
To generate a kernel application for use with a VxWorks UP kernel using default
libraries, use the following command syntax or add the variable assignments to the
application’s makefile:
make CPU=cpuType TOOL= toolchain
For information about the CPU and TOOL variables, see the VxWorks Architecture
Supplement.
45
VxWorks
Command-Line Tools User's Guide, 6.7
To build a kernel application for use with a VxWorks SMP kernel using default
libraries, use the following command syntax or add the variable assignments to the
application’s makefile:
make CPU=cpuType TOOL= toolchain VXBUILD=SMP
The VXBUILD=SMP ensures that the application will be linked against the default
SMP libraries.
For information about the CPU and TOOL variables, see the VxWorks Architecture
Supplement.
To build a kernel application for a VxWorks kernel (UP or SMP) using variant
libraries that you have created with a VSB project, the makefile must include
rules.dkm.mk.
Use the following command syntax or add the variable assignments to the
application’s makefile:
make CPU=cpuType TOOL= toolchain VSB_DIR=pathToVsbProjectDir
The VSB_DIR assignment ensures that the application will be linked against the
specified set of variant libraries. Whether these libraries are UP or SMP was
determined when the VSB project was created.
For information about the CPU and TOOL variables, see the VxWorks Architecture
Supplement.
46
4 Building Kernel Applications and Libraries
4.8 Linking Kernel Application Modules
In either case, the command creates the object module applic.o from the object
modules applic1.o, applic2.o, and applic3.o. The -r option is required, because the
object-module output must be left in relocatable form so that it can be downloaded
and linked to the target VxWorks image.
Any VxWorks facilities called by the kernel application modules are reported by
the linker as unresolved externals. These are resolved by the loader when the
module is loaded into VxWorks memory.
! WARNING: Do not link each kernel application module with the VxWorks libraries.
Doing this defeats the load-time linking feature of the loader, and wastes space by
adding multiple copies of VxWorks system modules to the target.
Note that the command must be issued in the VxWorks image project (VIP)
directory.
47
VxWorks
Command-Line Tools User's Guide, 6.7
To include your kernel application modules in the system image using a makefile,
identify the names of the application object modules with EXTRA_MODULES. For
example, to link the module myMod.o with the operating system, add a line like
the following:
EXTRA_MODULES = myMod.o
Building the system image with the module linked in is the final part of this step.
In the project directory, execute the following command:
c:\workspace\myVIP> make vxWorks
For information about how to have kernel applications start automatically at boot
time, see the VxWorks Kernel Programmer’s Guide.
For information about using vxprj to add link kernel applications with VxWorks
with a VxWorks image project (VIP), see Adding and Removing Individual Application
Files, p.18. The vxprj method has the advantage of making the application an
integral part of the VxWorks project (and it remains so even when the project is
cleaned).
! CAUTION: Specific make variables are required if you are building an application
for a symmetrical multiprocessing SMP configuration of VxWorks or for a system
based on variant libraries (created with a VxWorks source build project). For more
information, see 4.7 Building Kernel Applications for UP, SMP, and VSB Variants, p.45.
48
4 Building Kernel Applications and Libraries
4.11 Running Kernel Applications
49
VxWorks
Command-Line Tools User's Guide, 6.7
50
5
Building RTP Applications
and Libraries
5.1 Introduction 52
5.2 About Building RTP Applications and Libraries 52
5.3 Setting Environment Variables 53
5.4 Using the VxWorks Build Environment 53
5.5 Make Rules for RTP Applications and Libraries 54
5.6 Setting CPU and TOOL Make Variables 54
5.7 Top-Level Makefile for Applications and Libraries 54
5.8 Building RTP Libraries 55
5.9 Building RTP Applications 58
5.10 Using a Custom Build Environment 61
5.11 Compiler Options for Shared Objects and Dynamic RTP
Applications 64
5.12 Make Variables for RTP Applications and Libraries 66
5.13 Running RTP Applications 69
51
VxWorks
Command-Line Tools User's Guide, 6.7
5.1 Introduction
This chapter explains how to build VxWorks user-mode applications and libraries,
using command-line build facilities. You can build applications and libraries using
a default set of makefile rules and make, or with a custom build environment.
VxWorks user-mode applications are standalone executables. They are referred to
as real-time process (RTP) applications. You can use the default (or a custom) build
environment to build static libraries, shared libraries, and plug-ins for use with
RTP applications.
For detailed information writing code for applications and libraries, see the
VxWorks Application Programmer’s Guide. For information about how to use
Wind River Workbench to build applications and libraries, see the Wind River
Workbench by Example guide.
52
5 Building RTP Applications and Libraries
5.3 Setting Environment Variables
Top-level directory
If you do not use a top-level makefile for the whole project, and you build libraries
and applications separately, you must build libraries first.
53
VxWorks
Command-Line Tools User's Guide, 6.7
For information about the CPU and TOOL make variables, see the VxWorks
Architecture Supplement.
SUBDIRS
Indicates what subdirectories to build. In this case, there are two library
subdirectories (libA and libB) and an application subdirectory (app)
identified.
54
5 Building RTP Applications and Libraries
5.8 Building RTP Libraries
rules.rtp
The make fragment holding build rules for application (.vxe) files.
$(WIND_USR)
An environment variable pointing to the user-side of the target tree:
installDir/vxworks-6.x/target/usr.
Only four elements are required for a shared library (or plug-in) makefile. For
example:
LIB_BASE_NAME = MyFoo
OBJS = foo1.o foo2.o foo3.o
EXTRA_INCLUDE += -I/home/xeno/proj/h
include $(WIND_USR)/make/rules.library
LIB_BASE_NAME
Specifies the library’s basename. It takes a stripped version of the library name;
that is, without the lib prefix and without the filename extension. The
LIB_BASE_NAME variable is required for generating the shared object name
(soname) information, which is necessary for identifying the run-time location
of the shared library. For detailed information about shared object names, see
the VxWorks Application Programmer’s Guide.
OBJS
Identifies the object files that make up the library.
EXTRA_INCLUDE
Appends additional search paths for the include files (using the += operator).
rules.library
The make fragment holding build rules for libraries.
55
VxWorks
Command-Line Tools User's Guide, 6.7
$(WIND_USR)
An environment variable pointing to the user-side of the target tree:
installDir/vxworks-6.x/target/usr.
SL_INSTALL_DIR
Specifies a non-default location for the library file. It is often useful to keep
project work outside of the installation directory. Note that if you are
generating code for different processor architectures, you could use the $(CPU)
variable to define the architecture-specific subdirectory (which would then use
the Wind River naming conventions—PPC32 instead of ppc32, as in this case).
LIB_FORMAT
Specifies whether the library must be generated as a static library (the default
if not specified) or a shared library. It can be set to static, shared, or both. See
5.8.4 Library Build Commands, p.58.
LOCAL_CLEAN
Specifies what must be deleted when non-default directories are used.
OBJ_DIR
Specifies a non-default directory in which the object modules are generated.
LIBNAME
Specifies a non-default directory for the static library.
56
5 Building RTP Applications and Libraries
5.8 Building RTP Libraries
SL_VERSION
Creates a version number for a shared library. By default, the shared library
version number is 1 (libName.so.1), so the variable is not needed unless you
want to build an alternate version of the shared library. For detailed
information about shared object names and versions, see the VxWorks
Application Programmer’s Guide.
LIBDIR 5
Prevents the creation of an unused directory in
installDir/vxworks-6.x/target/usr/lib when set to $(OBJ_DIR), as it is in this
example. This variable must be the last one used; that is, it must be listed after
the inclusion of rules.library in order to take precedence.
57
VxWorks
Command-Line Tools User's Guide, 6.7
The first conditional statement in the example above allows for building both a
shared library and dynamic application using the top-level makefile. For example:
make EXE_FORMAT=dynamic
builds the dynamic executable and related shared libraries for the PPC32
architecture with the Wind River Compiler (the default architecture and compiler).
The following command is similar, but uses the GNU compiler to build for the
Pentium architecture:
make CPU=PPC32 TOOL=gnu EXE_FORMAT=dynamic
Static libraries are created by default, so the EXE_FORMAT variable need not be
used to create them. For information about the CPU and TOOL variables see
5.6 Setting CPU and TOOL Make Variables, p.54.
You can also build libraries by executing make in the directory containing the
library makefile. The LIB_FORMAT variable allows you to create static, shared, or
both sets of libraries. For example:
make LIB_FORMAT=static
make LIB_FORMAT=shared
make LIB_FORMAT=both
Static libraries are created by default, so that option is superfluous in this context.
Only four elements are required for an RTP application makefile when the
application is a dynamic executable that uses a shared library. For example:
EXE = myVxApp.vxe
OBJS = myVxApp.o
ADDED_LIBS += -L../lib/$(CPU)$(TOOL) –lMyFoo
include $(WIND_USR)/make/rules.rtp
58
5 Building RTP Applications and Libraries
5.9 Building RTP Applications
EXE
Defines the name of the application executable.
OBJS
Identifies the constituent object modules. If more than one is used, they are
listed in a space-separated string. For example:
OBJS = bar1.o bar2.0 bar3.0
5
ADDED_LIBS
Appends the search paths and stripped names of any custom libraries that the
application requires (with the += operator). This option can be used for
creating either static or dynamic applications. See 5.11 Compiler Options for
Shared Objects and Dynamic RTP Applications, p.64 for a discussion of the -l
option.
The include statement and $(WIND_USR) element are described in 5.7 Top-Level
Makefile for Applications and Libraries, p.54.
Additional makefile variables can (and often should) be used to specify a different
location for the application executable, the run-time location of the shared libraries
upon which it depends, conditional compilation of either a dynamic or static
application, and so on. A more useful makefile would look like the following:
EXE = myVxApp.vxe
OBJS = myVxApp.o
VXE_DIR = $(CPU)$(TOOL)/bin
LIB_DIR = ../lib/$(CPU)$(TOOL)
ADDED_LIBS += -L $(LIB_DIR) –lMyFoo
ifeq ($(EXE_FORMAT),dynamic)
ADDED_DYN_EXE_FLAGS += -Wl,-rpath /romfs/lib
else
ADDED_LIB_DEPS += $(LIB_DIR)/libMyFoo.a
endif
include $(WIND_USR)/make/rules.rtp
VXE_DIR
Identifies an alternative to the default directory in which the application
executable is created. It is often useful to keep project work outside of the
installation tree.
LIB_DIR
Is a local make variable that can be used conveniently to identify where a
library is located (if it is not in the default location) in the ADDED_LIBS and
ADDED_LIB_DEPS lines without repeating the literal path information.
59
VxWorks
Command-Line Tools User's Guide, 6.7
ADDED_DYN_EXE_FLAGS
Is used to pass additional compiler options specific to the generation of
dynamic executables. It is used here with the -Wl,-rpath option to specify the
run-time location of any shared libraries upon which the application depends
NOTE: The the usage for -rpath is different for the Wind River Compiler and the
Wind River GNU compiler. For the latter, an equal sign (=) must be used between
-rpath and the path name.
In this example, the location is in a lib subdirectory of the ROMFS file system
on the VxWorks target:
ADDED_DYN_EXE_FLAGS += -Wl,-rpath /romfs/lib
For information about the -Wl,-rpath option, see 5.11 Compiler Options for
Shared Objects and Dynamic RTP Applications, p.64.
Note that some types of connections between the target and host require
modifiers to the path name. NFS is transparent; FTP requires hostname: before
the path if it is not on the same system from which VxWorks was booted; the
VxWorks simulator requires a host: prefix; and so on.
ADDED_LIB_DEPS
Specifies the dependencies between the application and the application’s static
libraries (with the += operator). For static linkage, this variable forces a rebuild
of the application if the static library has been changed since the last build.
In the example provided in 5.9.2 More Complex Application Makefile, p.59, the
conditional ifeq/else/endif statement allows for generating either a static
60
5 Building RTP Applications and Libraries
5.10 Using a Custom Build Environment
61
VxWorks
Command-Line Tools User's Guide, 6.7
2. Generate the executable file based on the object modules. By convention, the
application is created with the .vxe filename extension.
! CAUTION: Combining PIC modules generated by the Wind River Compiler and
the GNU compiler is not supported and is not expected to work. Doing so may
lead to unpredictable results.
62
5 Building RTP Applications and Libraries
5.10 Using a Custom Build Environment
NOTE: The the usage for -rpath is different for the Wind River Compiler and the
Wind River GNU compiler. For the latter, an equal sign (=) must be used between
-rpath and the path name.
63
VxWorks
Command-Line Tools User's Guide, 6.7
To generate PIC suitable for use in a shared library or plug-in, use the following
options:
■
-Xpic with the Wind River Compiler
■
-fpic with the GNU Compiler
To link shared library PIC modules, use:
■
-Xshared with the Wind River Compiler
■
-shared with the GNU Compiler
To name a shared object (and optionally provide a version number), use:
■
-soname= sharedLibraryName with the Wind River Compiler
■
-Wl,-soname,sharedLibraryName with the GNU Compiler
Note that gcc does not recognize -soname so it must be passed to ld with -Wl.
The -soname option specifies a shared object name for a shared library. This
information is used both for locating shared libraries at run-time, as well as for
creating different versions of shared libraries. For detailed information about
shared object names, see the VxWorks Application Programmer’s Guide.
To force the object to use its own definitions for global functions and data even if
some other shared object, or the dynamic executable, would otherwise override
those definitions, use:
■
-Bsymbolic with either compiler
Note that the compilers do not recognize -Bsymbolic, so it must be passed to
their linker with -Wl.
64
5 Building RTP Applications and Libraries
5.11 Compiler Options for Shared Objects and Dynamic RTP Applications
Normally when the dynamic linker looks for a definition for a function or some
data, it chooses the first one that it sees, even if some later module has its own
definition.
To identify the run-time path to shared libraries, use the following when building
the application’s dynamic executable:
■ -Wl,-rpath sharedLibDirPath (with either compiler)
Provide a semicolon-separated list of directory names (the run path), which the
dynamic linker uses as one of the means to locate shared libraries at run time.
! CAUTION: The dynamic linker assumes that library files with the same name are
different if the path defined with -rpath is different. Care should therefore be taken
to ensure that multiple copies of identical libraries are not loaded.
For more information about run-time paths, as well as additional methods for
identifying them, see the VxWorks Application Programmer’s Guide.
The paths provided with the -Wl,-rpath linker option must, of course, be accessible
to the VxWorks target system. If the paths reference files on the host’s file system,
make sure that they are identified in a way that is appropriate for the host-target
connection. NFS is transparent; FTP requires hostname: before the path if it is not
on the same system from which VxWorks was booted; the VxWorks simulator
requires a host: prefix; and so on.
For example, the following example identifies a lib subdirectory in the ROMFS file
system in VxWorks, the c:\proj\lib on a Windows host system, and
/home/xeno/proj on an NFS file system as the locations for shared libraries:
-Wl,-rpath /romfs/lib;c:/proj/lib;/home/xeno/proj
65
VxWorks
Command-Line Tools User's Guide, 6.7
When using Wind River Workbench to create a dynamic executable, the linker
option for a dynamic executable must be selected. The -Wl,-rpath option can be
used to identify shared library locations, if necessary.
To indicate which shared libraries will be used by the dynamic application, use:
■
-l with either compiler
The -l option takes a stripped version of the library name. By convention,
libraries referred to by the -l option are named libname.so or libname.a. Both
the lib part of the name and the filename extension (.so or .a) are omitted when
specified with -l. For example, both libMyFoo.so and libMyFoo.a could be
identified with -l MyFoo. This facility is particularly useful for conditional
compilation of either static or dynamic applications (see 5.9.2 More Complex
Application Makefile, p.59).
66
5 Building RTP Applications and Libraries
5.12 Make Variables for RTP Applications and Libraries
ADDED_LIB_DEPS
Dependencies between the application and the application’s static libraries
(with the += operator). For static linkage, this variable forces a rebuild of the
application if the static library has been changed since the last build.
ADDED_SHARED_LIBS
A list of shared libraries dynamically linked to the application. Items in the list
are prefixed with lib and have the.so file extension added. For example, 5
ADDED_SHARED_LIBS="foo bar" causes the build system to try to link
libfoo.so and libbar.so.
CPU
The target instruction-set architecture to compile for. This is not necessarily the
exact microprocessor model.
DOC_FILES
A list of C and C++ source files that are specially parsed during the build to
generate online API documentation. Should be an empty list if there are no
files to generate documentation from.
-DTOOL_FAMILY
The compiler tool family (diab or gnu) for kernel applications.
-D_VX_TOOL_FAMILY
The compiler tool family (diab or gnu) for user applications. This macro is
analogous to the -DTOOL_FAMILY macro used for kernel applications.
EXCLUDE_SUBDIRS
A list of subdirectories excluded from the build. Generally, when make is
executed, the system tries to build the default target for every subdirectory of
the current directory that has a makefile in it. Use EXCLUDE_SUBDIRS to
override this behavior. See also SUBDIRS.
EXE
The output executable filename. Specify only one executable per makefile. Do
not include a directory path. See VXE_DIR.
EXE_FORMAT
The format of the output executable (static or dynamic). The default is static.
EXTRA_INCLUDE
Additional search paths for the include files. Uses the += operator.
LIBNAME
A non-default directory for the static library.
67
VxWorks
Command-Line Tools User's Guide, 6.7
LIB_BASE_NAME
The name of the archive that objects built in the directory are collected into. For
example, LIB_BASE_NAME=foo causes the build system to create a static
library called libfoo.a or a dynamic library called libfoo.so. See LIB_FORMAT.
(Library builds only.)
LIB_DIR
A local make variable that can be used conveniently to identify where a library
is located (if it is not in the default location) in the ADDED_LIBS and
ADDED_LIB_DEPS lines without repeating the literal path information.
LIB_FORMAT
The type of library to build. Can be static, shared (dynamic), or both; defaults
to both. (Library builds only.)
LOCAL_CLEAN
Additional files deleted when make clean is executed. By default, the clean
target deletes files listed in OBJS. Use LOCAL_CLEAN to specify additional files
to be deleted. Must be defined after rules.rtp or rules.library.
LOCAL_RCLEAN
Additional files deleted when make rclean is executed. The rclean target
recursively descends the directory tree starting from the current directory,
executing make clean in every subdirectory; if SUBDIRS is defined, only
directories listed in SUBDIRS are affected; directories listed in
EXCLUDE_SUBDIRS are not affected. Use LOCAL_RCLEAN to specify
additional files in the current directory to be deleted. Must be defined after
rules.rtp or rules.library.
OBJ_DIR
The output subdirectory for object files.
OBJS
A list of object files built; should include object files to be linked into the final
executable. Each item must end with the .o extension. If you specify an object
file that does not have a corresponding source file (.c for C, .cpp for C++, or .s
for assembly), there must be a build rule that determines how the object file is
generated. Do not include a directory path. See OBJ_DIR and LIBDIRBASE.
SL_INSTALL_DIR
A non-default location for the library file. It is often useful to keep project work
outside of the installation directory.
68
5 Building RTP Applications and Libraries
5.13 Running RTP Applications
SL_VERSION
A version number for a shared library. By default, the shared library version
number is one (libName.so.1), so this variable is not needed unless you want to
build an alternate version of the shared library.
SUBDIRS
A list of subdirectories of the current directory in which the build system looks
for a makefile and tries to build the default target. If SUBDIRS is not defined, 5
the system tries to build the default target for every subdirectory of the current
directory that has a makefile in it. EXCLUDE_SUBDIRS overrides SUBDIRS.
TOOL
The compiler and toolchain used. The Wind River (Diab) and GCC (GNU)
compilers are supported. TOOL can also specify compilation options for
endianness or floating-point support.
VXE_DIR
The output subdirectory for executable files and shared libraries. Defaults to
target/usr/root/CPUtool/bin/ (executables) or target/usr/root/CPUtool/lib/
(shared libraries); for example, target/usr/root/PPC32diab/bin/.
For further information on these make variables, see the VxWorks Application
Programmer’s Guide.
For information on the supported values for the CPU and TOOL make variables,
see the VxWorks Architecture Supplement: Building Applications.
69
VxWorks
Command-Line Tools User's Guide, 6.7
70
6
Configuring and Building
VxWorks Using config.h
6.1 Introduction 71
6.2 Using config.h to Configure VxWorks 72
6.3 Configuration Examples 73
6.4 Using make 74
6.1 Introduction
Wind River recommends using either Workbench or the vxprj command-line
facility to configure and build VxWorks. The legacy method using bspDir/config.h
to configure VxWorks and bspDir/make to build it has been deprecated for most
purposes, and you cannot use it for multiprocessor (SMP and AMP) development.
Note that the config.h/make method is often referred to simply as a BSP build.
However, you must still use the config.h method for the following:
■
Some middleware products (see the Platform release notes for further
information).
■
Boot loaders, when the BSP does not support the PROFILE_BOOTAPP
configuration profile.
71
VxWorks
Command-Line Tools User's Guide, 6.7
You can also use the config.h method for uniprocessor BSP development prior to
the CDF (configuration description file) development, which is required for
configuration with vxprj and Workbench.
! CAUTION: The config.h/make (BSP build) method does not work for SMP and
AMP systems, and does not work for most Platform products.
The configAll.h file provides the default VxWorks configuration for all BSPs. The
INCLUDED SOFTWARE FACILITIES section of this header file lists all components
that are included in the default configuration. The EXCLUDED FACILITIES section
lists those that are not. To add or remove components from a kernel configuration,
examine the configAll.h file to determine the default, then change the default for
a specific BSP by editing the config.h file for that BSP, defining or undefining the
appropriate components.
The config.h header file includes definitions for the following parameters:
■
Default boot parameter string for boot ROMs.
■
Interrupt vectors for system clock and parity errors.
■
Device controller I/O addresses, interrupt vectors, and interrupt levels.
■
Shared memory network parameters.
72
6 Configuring and Building VxWorks Using config.h
6.3 Configuration Examples
■
Miscellaneous memory addresses and constants.
The config.h file overrides any setting in the configAll.h file. You should never
edit the configAll.h file.
! CAUTION: Do not edit the configAll.h file. Any changes that you make will affect
all BSPs. You should only edit the config.h files in the individual BSP directories.
If you are creating a boot loader for a wrSbc8560 board that does not require
networking, you would add the following line to the config.h file in
installDir/vxworks-6.x/target/config/wrSbc8560:
#undef INCLUDE_NETWORK
RTP (real-time process) support is not included by default in BSP builds. Even
though the line
#define INCLUDE_RTP
73
VxWorks
Command-Line Tools User's Guide, 6.7
#ifdef INCLUDE_RTP
#define INCLUDE_SC_POSIX /* POSIX system calls */
#endif /* INCLUDE_RTP */
On Windows, the make utility, as configured by wrenv, executes the Z shell (zsh,
installed with the Workbench tools as sh.exe). On UNIX, the make utility executes
whatever shell program is invoked by the command sh.
For complete information about make, see the GNU Make manual.
Each BSP has a makefile for building VxWorks. This makefile, called Makefile, is
abbreviated to declare only the basic information needed to build VxWorks with
74
6 Configuring and Building VxWorks Using config.h
6.4 Using make
the BSP. The makefile includes other files to provide target and VxWorks specific
rules and dependencies. In particular, a file of the form depend.bspName is
included. The first time that make is run in the BSP directory, it creates the
depend.bspName file.
The Makefile in the BSP directory is used only when building from the traditional
command line. It is not used when building projects with vxprj or Wind River
Workbench. Each build option for a project has its own makefile that the tool uses
to build the project modules.
6
There are a number of different VxWorks image targets that can be created using
the Makefile, including vxWorks (a downloadable image that executes from
RAM), and vxWorks.st (a standalone image that includes a symbol table). In
addition, you can build VxWorks images that can be stored in ROM as well as
images that can be executed from ROM. In addition to VxWorks images, you can
build boot loader images that are VxWorks images configured with a boot loader
as the application. For details on VxWorks image types, see the Boot Sequence
section of the Wind River VxWorks BSP Developer’s Guide: Overview of a BSP.
When projects are created from a BSP, the BSP makefile is scanned once and the
make parameters are captured into the project. Any changes made to the BSP
makefile after a project has been created do not affect that project. Only projects
built from the BSP after the change is made are affected.
The BSP makefile provides several mechanisms for configuring the VxWorks
build. Although VxWorks configuration is more commonly controlled at
compile-time by macros in configAll.h and bspName/config.h.
Most of the makefile macros fall into two categories: macros intended for use by
the BSP developer, and macros intended for use by the end user. The needs of these
two audiences differ considerably. Maintaining two separate compile-time macro
sets lets the make separate the BSP-specific requirements from user-specific
requirements.
Macros containing EXTRA in their name are intended for use by the BSP developer
to specify additional object modules that must be compiled and linked with all
VxWorks images.
Macros containing ADDED in their name are intended for use by the end-user on
the make command line. This allows for easy compile time options to be specified
by the user, without having to repeat any BSP-specific options in the same macro
declaration.
75
VxWorks
Command-Line Tools User's Guide, 6.7
Of the many makefile macros, this document discusses only the most commonly
used.
MACH_EXTRA
You can add an object module to VxWorks by adding its name to the skeletal
makefile. To include fooLib.o, for example, add it to the MACH_EXTRA definition
in Makefile. This macro causes the linker to link it into the output object.
Finally, regenerate VxWorks with make. The module will now be included in all
future VxWorks builds. If necessary, the module will be made from fooLib.c or
fooLib.s using the .c.o or .s.o makefile rule.
MACH_EXTRA can be used for drivers that are not included in the VxWorks driver
library. BSPs do not usually include source code for device drivers; thus, when
preparing your system for distribution, omit the driver source file and change the
object file’s name from .o to .obj (update the makefiles, too). Now the end user can
build VxWorks without the driver source, and rm *.o will not remove the driver’s
object file.
LIB_EXTRA
EXTRA_INCLUDE
76
6 Configuring and Building VxWorks Using config.h
6.4 Using make
EXTRA_DEFINE 6
The makefile variable EXTRA_DEFINE is available for specifying compile time
macros required for building a specific BSP. In the following example the macro
BRD_TYPE is given the value MB934. This macro is defined on the command line
for all compiler operations.
EXTRA_DEFINE = -DBRD_TYPE=MB934
By default a minimum set of macro names are defined on the compiler command
line. This is primarily used to pass the same memory addresses used in both the
compiling and linking operations.
These default macro definitions include:
-DCPU=$(CPU)
ADDED_CFLAGS
When make is called normally, VxWorks supports the XYZ-75 with the Galaxy-A
module installed. To override the default and build VxWorks for the
XYZ-75/Galaxy-B configuration, do the following:
77
VxWorks
Command-Line Tools User's Guide, 6.7
For ease of use, you can encapsulate the lengthy command line within a shell script
or independent makefile.
To ensure that a module is incorporated in vxWorks, remove the module’s object
file and vxWorks before running make.
ADDED_MODULES
CONFIG_ALL
Under extreme circumstances, the files in the config/all directory might not be
flexible enough to support a complex BSP. In this case, copy all the config/all files
to the BSP directory (config/bspName) and edit the files as necessary. Then redefine
the CONFIG_ALL makefile variable in Makefile to direct the build to the altered
files. To do this, define CONFIG_ALL to equal the absolute path to the BSP’s
config/bspName directory as shown in the following example:
CONFIG_ALL = $(TGT_DIR)/config/bspName/
The procedure described above works well if you must modify all or nearly all the
files in config/all. However, if you know that only one or two files from config/all
need modification, you can copy just those files to the BSP’s config/bspName
directory. Then, instead of changing the CONFIG_ALL makefile macro, change one
or more of the following (which ever are appropriate).
USRCONFIG
The path to an alternate config/all/usrConfig.c file.
BOOTCONFIG
The path to an alternate config/all/bootConfig.c file.
78
6 Configuring and Building VxWorks Using config.h
6.4 Using make
BOOTINIT
The path to an alternate config/all/bootInit.c file.
DATASEGPAD
The path to an alternate config/all/dataSegPad.s file.
CONFIG_ALL_H
The path to an alternate config/all/configAll.h file.
TGT_DIR
The path to the target directory tree, normally $(WIND_BASE)/target. 6
COMPRESS
The path to the host’s compression program. This is the program that
compresses an executable image. The binary image is input through stdin,
and the output is placed on the stdout device. This macro can contain
command-line options for the program if necessary.
BINHEX
The path to the host’s object-format-to-hex program. This program is
called using HEX_FLAGS as command line options. See
target/h/make/rules.bsp for actual calling sequence.
HEX_FLAGS
Command line options for the $(BINHEX) program.
BOOT_EXTRA
Additional modules to be linked with compressed ROM images. These
modules are not linked with uncompressed or ROM-resident images, just
compressed images.
EXTRA_DOC_FLAGS
Additional preprocessor options for making man pages. The default
documentation options are -DDOC -DINCLUDE_SCSI. If
EXTRA_DOC_FLAGS is defined, these options are passed to the man page
generation routines in addition to the default options.
Once a boot loader is configured, you can build the custom boot loader by running
make bootrom in the BSP directory. There are a variety of boot loader image types,
including the compressed bootrom that executes from RAM, the uncompressed
bootrom_uncmp (which also executes from RAM), and the bootrom_res (which
executes from ROM). For more information, see the VxWorks Kernel Programmer’s
Guide.
79
VxWorks
Command-Line Tools User's Guide, 6.7
80
Index
Symbols B
symbols - see assignment operators, asterisk, at, backslashes 2
backslashes, quotation marks, slashes, BSP
spaces build method (deprecated) 71
defined 12
documentation 12
make variables 48
A build environment
custom, for RTP applications 61
ADDED_C++FLAGS 48, 66
kernel applications 43
ADDED_CFLAGS 66
RTP applications 53
ADDED_CFLAGS
build rules
modifying run-time 48
changing 25
ADDED_CLEAN_LIBS 66
defined 22
ADDED_DYN_EXE_FLAGS 66
examining 24
ADDED_LIB_DEPS 67
VxWorks 22
ADDED_LIBS 66
build specifications
ADDED_SHARED_LIBS 67
defined 22
application modules
examining 24
make variables 48
setting 24
makefiles 43
VxWorks 22
applications
building
kernel-mode, see kernel applications
customized VxWorks source code 36
user mode, see RTP applications
kernel applications 45
RTP applications 58
81
VxWorks
Command-Line Tools User's Guide, 6.7
82
Index
G L
GCC (GNU Compiler) 1 LIB_BASE_NAME 68
documentation 2 LIB_DIR 68
gnu LIB_FORMAT 68
specifying compiler with vxprj 13 LIBNAME 67
libraries
kernel-mode, building 42
linking to RTP applications 66
I user-mode (RTP), building 52
linking Index
-i 8
kernel application modules 47
image types, VxWorks 22
kernel application modules with VxWorks 47
include files, using 43
linux (simulator BSP) 14
LOCAL_CLEAN 68
LOCAL_RCLEAN 68
K
kernel applications
about building 42
M
build environment 43
make rules
building for default SMP system 46
RTP applications and libraries 54
building for default UP system 45
make utility 1
building for library variants 45
make variables 66
building for VSB-based system 46
for kernel applications and libraries 48
example makefile 43
for RTP applications and libraries 66
linking modules 47
setting CPU and TOOL 44, 54
linking modules with VxWorks 47
makefile
make variables for 48
kernel applications 43
running 49
RTP applications 54, 58, 59
kernel configuration projects
RTP libraries 54, 55, 56
building
makefiles
vxprj 22
changing name 18
creating
include files
vxprj 12
application modules, and 43
kernel libraries
variables, include file
about building 42
customizing run-time, for 47, 48
make variables for 48
vxprj-generated 14
kernel shell 16
make-rule files 54
kernel-mode applications, see kernel applications
O
-o 9
83
VxWorks
Command-Line Tools User's Guide, 6.7
84
Index
85
VxWorks
Command-Line Tools User's Guide, 6.7
W
Wind River Compiler 1
Windows
conventions 2
Workbench
documentation 1
.wpj files
components 16
wrenv
how it works 7
options 8
overview 5
setting environment variables 6
86