7. Building

7.1. Workbench Project Builder Commands

Workbench provides project build commands in two menus: the Project menu and a contextual menu on the Project Navigator. These commands are the standard project builder commands defined by Eclipse. Wind River provides additional build commands as well.

7.1.1. Project Menu

The Project menu on the menubar defines the standard Eclipse project build commands and adds a submenu with additional builder-oriented commands.

wrs menubar project builder menu

“Rebuild Project” and “Clean Project” are convenience commands that apply to the currently active Workbench project. The Clean Project command simply cleans the project, like the standard command, but does not offer the option to clean more than that one project, unlike the standard command. The Rebuild Project command first performs a Clean Project and then a build.

7.1.2. Contextual Menu

The contextual menu of the Workbench Project Navigator includes the standard project building commands, as shown below. Note that these commands will be enabled and disabled depending upon whether a build is considered necessary.

wrs contextual project builder menu

7.2. About “Build Automatically”...

The Project menu on the menubar defines the standard Eclipse project build commands with the standard semantics, including the semantics of “Build Automatically”. (See the figure below for the location within the menu.) Build Automatically is actually an option, not a command, and will have a check-mark next to it when it is enabled.

You will likely **not* want to enable Build Automatically when working with Wind River Workbench projects,* regardless of the programming language used, because it invokes a full, complete build whenever a project source file is changed.

wrs menubar project builder menu top level

7.3. Compiling Individual Files

The GNATbench Ada editor extends the contextual menu with an entry “Compile Ada File” that will compile the current file opened in the editor. The progress indicator at the lower right of Workbench will show the command as it runs.

wrs compile file editor menu

The compilation steps are displayed on the standard Eclipse Console in a subconsole specific to the command. Note this is not the Workbench Build Console, it is within the Eclipse Console view. You can show this view using the standard Eclipse Window -> Show View command if the Console is not already open.

You can also analyze the file so that browsing and navigation are supported, as well as indicating any syntax or semantic errors, without involving actual code generation. The Analyze Ada File will invoke the operation; the output will appear as for the Compile command.

For both the compilation and analysis file commands, the compiler actually invoked is determined by the project default toolchain. This toolchain need not be the the one invoked when building the entire project. For example, you might want to use a more recent version of the compiler for the sake of additional capabilities, or you might want to use a completely different compiler targeted to a different architecture (e.g., a “native” compiler). To apply multiple toolchains see Using Multiple Toolchains

7.4. Building Projects with Scenarios

GNAT project files have the concept of scenario variables that allow considerable flexibility in controlling how the tools build an executable. (See Scenario Variables for an the details of scenario variables, and GNAT Projects for the details of GNAT project files.) You can define, for example, different scenarios for debugging and releases, in which optimization and symbolic information are either present or not, respectively.

In the GNAT project file shown in the following figure, note the scenario variable named “Mode” declared on line 5. On that same line, note the use of the “external” function that references the name “BUILD” as the external name by which we can get values for Mode. That external name is used on the command line and in the Scenario Variables View as you will see shortly.

project file showing scenario var

The scenario variable Mode has two possible values because of its type: “Production” and “Debug”. (These values are case-sensitive because they are strings.) As you have guessed, these two values represent two different build scenarios. “Production” corresponds to the scenario in which you build for actual delivery. The “Debug” scenario is for development and testing. Therefore, these scenarios require different switches to be applied and this fact is reflected in the content of the packages in the project file.

The value of the variable Mode, then, controls how the executable is built so we must control the value of the variable. This control is accomplished using the Scenario Variables View. In the following figure we see the use of the external reference name “BUILD” and the corresponding value “Debug” in the view.

tutorial scenario var debug setting

When “BUILD” has the value “Debug”, the builder will apply the switches corresponding to that scenario. We can see them in the Build Console below. Look for the use of the switches (e.g., “-g”, “-gnato”) on the command line.

content of Build Console after successful build

We can change the value of “BUILD” to “Production” by double-clicking on the value to get a list of all possible values in a pull-down list, as shown below:

tutorial scenario var production setting

Changing the value of “BUILD” to “Production” and then rebuilding will apply the different switches:

content of Build Console after changing BUILD to Production

7.5. Using Multiple Toolchains

GNATbench projects are integrated with the Workbench project builder and therefore use the active build spec to select the toolchain used when building the Ada part of a project.

However, other commands, such as compilation of individual files, are driven by the GNAT project file, specifically the project default toolchain. This toolchain is the native compiler unless you select a different default. Both native and cross toolchains may be chosen for a given project and any one of them may be selected as the default.

To configure the project’s toolchain selections, invoke the Properties menu for a given project and then select the “GNATbench Properties” page. The figure below shows this page. Note that both a native and a cross toolchain are selected, and that the cross compiler will be used by default.

multiple toolchains selected in properties

When multiple toolchains are selected, the GNATbench wizard alters the GNAT Project file (the “gpr file”) so that a new scenario variable named “Target” is declared, with possible values representing each selected toolchain. The wizard also alters the IDE package within the project file so that the “Target” scenario variable controls which toolchain will be applied. The following figure illustrates these alterations:

gpr file with multiple toolchains available

The wizard makes the necessary additions and alternations to the gpr file. You use the Scenario Variables view to select which toolchain to apply, just as would be done for any other scenario variable.

toolchain selection scenario var view

7.6. Building With Multiple Languages

By default, the WRS builder will compile any C, C++, and Assembly language source files found in the source directories of a Workbench project. All directories are considered source directories, including those added after project creation, whenever the project builder is invoked.

By default, the Ada builder will only compile Ada files. It will not process any of those other languages’ source files. However, the Ada builder can be made to compile those files by changing the content of the GNAT project file (the “gpr file”). Specifically, you must specify those languages in the Languages attribute and, in addition, specify the containing source directories in the Source_Dirs attribute of the project file.

Having both builders process these source files is obviously not desirable. Therefore, when using the Ada builder to compile those other languages’ files, you should prevent the WRS builder from doing so. This processing can be prevented by controlling which directories are recognized as source directories by the WRS builder.

Users can control which directories are so recognized by editing the “Build Targets” content. By default, all directories are considered source directories because the Build Targets content specifies the root directory with the “recursive” flag enabled. Specific directories can instead be named as source directories by removing this default content and specifying the intended individual directories explicitly. Directory trees can be specified by enabling the “recursive” flag for those directory tree roots. See the Wind River documentation for editing the Build Targets.

Note that the Builder Targets content does not specify Ada source directories. These directories are to be specified in the GNAT project file, as usual.

7.6.2. Using GNATPRO C Compiler

The C code can be compiled using GNATPRO C Compiler instead of Wind River GNU/Diab Compilers.

It is currently limited to vxworks-6.x & vxworks-7.x platforms Please read GNAT User’s Guide Supplement for Cross Platforms to check if your installed GNATPRO toolchain supports it.

To activate, the “–config=c,,,,GCC_Pro” switch should replace existing config switch for C language.

See below a makefile example.

# To compile C code with GNATPRO C Compiler instead of Wind River GNU/Diab C Compilers
# uncomment the following line.

ifeq (True,$(USE_GNAT_C_COMPILER))

# Configure Ada and C tools for gprbuild.  We want to generate this file
# before each build in case the user makes a different build spec active.
# The RUNTIME value could not change in that case, but the PLATFORM value
# could change.
      @echo "building $(PROJECT_OBJ_DIR)/$(GPRBUILD_OBJECT_NAME)"
      $(TRACE_FLAG)if [ ! -d $(PROJECT_OBJ_DIR) ]; then mkdir -p $(PROJECT_OBJ_DIR); fi
      $(TRACE_FLAG)gprconfig $(QUIET) --target=$(PLATFORM) \
              --config=ada,,$(RUNTIME), \
              $(CONFIG_C) \
              --config=c++,,$(RUNTIME), \
              --config=asm,,, \
              --batch \
              -o $(CONFIG_FILE)


gnat.makefile generated by GNATbench-17.0 or later contains a commented USE_GNAT_C_COMPILER variable definition. Uncomment it to active GNATPRO C Compiler use.

GPR file generated by GNATbench-19.0 or later contains a USE_GNAT_C_COMPILER scenario variable. It can be changed by using “Scenario Variables” view.

7.7. Converting Existing GNATbench Projects To Use Flexible Builds

This part is applicable only on Wind River Workbench 3.x as Wind River “Standard” managed build projects are only supported by Wind River Workbench 3.x.

Existing GNATbench/Workbench projects can be converted from using the Wind River “Standard” managed builds to using “Flexible” managed builds instead. Conversion is not mandatory. If you do choose to convert your project, the conversion need only be done once. Note that conversion is irreversible.

Conversion is a two-step process: first apply the Wind River build type conversion wizard, then apply the GNATbench build type conversion wizard.

First apply the Wind River conversion wizard by invoking the contextual menu on the target project node and selecting “Build Options”, then selecting “Convert to Flexible Managed Build” as shown below:


You will be asked to confirm your intent to convert the project. Press Yes if you are sure, otherwise press No to abort the conversion.


Next, apply the GNATbench conversion wizard by again invoking the contextual menu on the target project node. This time select “New”, then “Other”, as shown below:


Then select “Convert Ada project to use Flexible Managed Builds” in the resulting wizard selection dialog (see figure below) and press Next.


The conversion wizard dialog will appear as shown in the next figure, explaining what will happen and giving you the opportunity to change your mind. Press Finish to apply the conversion, or Cancel to abort the process.


7.8. Troubleshooting build projects failures

7.8.1. Solving multiple definition errors

If you encounter multiple definition errors (see following errors examples) when linking a Wind River Workbench Real Time Process Application Project converted to an Ada Project, add “-r” and “-nostdlib” ada switches to the linker options to avoid linking with GNAT libraries.

multiple definition of `__argc'
multiple definition of `__argv'
multiple definition of `__copyArgcArgv'
multiple definition of `__copyEnvArr'
multiple definition of `__fini_atexit_nodep'
multiple definition of `__getAuxvPtr'
multiple definition of `__registerFini'
multiple definition of `__saveArgs'
multiple definition of `__setAuxvPtr'
multiple definition of `_crtSignalInit'
multiple definition of `_crtTaskInit'
multiple definition of `_start'
multiple definition of `environ'

To add “-r” and “-nostdlib” switches to the linker options, run the “GNAT Project > Edit GPR File” contextual menu on your GNAT project, and add “-r” and “-nostdlib” switches to ada default switches the Linker package.

package Linker is
   for Default_Switches ("Ada") use ("-r", "-nostdlib");
end Linker;

Note: If you forget to add “-r” ada switches to the linker options you may get the following errors.

undefined reference to `memcmp'
undefined reference to `memmove'

If you encounter multiple definition errors (see following errors examples) when linking a Wind River Workbench Downloadable Kernel Module Project converted to an Ada Project, add the “-noauto-register” Ada switch to the linker options to prevents conflicts with the OS-provided static constructors and destructors that are added into DKM projects by Workbench when it builds an application image.

multiple definition of `_dtors''
multiple definition of `_ctors'

To add the “-noauto-register” switch to the linker options, run the “GNAT Project > Edit GPR File” contextual menu on your GNAT project, and add “-noauto-register” switch to the Ada default switches the Linker package.

package Linker is
   for Default_Switches ("Ada") use ("-noauto-register");
end Linker;

If you encounter multiple definition of “__wrs_rtp_base” error when linking a Wind River Workbench Real Time Process Application Project converted to an Ada Project, add the following lines in the makefile of the project. (usually gnat.makefile file)

multiple definition of `__wrs_rtp_base'
  • At the beginning of the makefile, add the OBJCOPY definition.
# The name of objcopy tool (objcopypentium, objcopyarm or objcopyppc)
ifeq (sim,$(findstring sim,$(VX_CPU_FAMILY)))
  • At the end of the $(GPRBUILD_OBJECT) target (after gprbuild call), add the $(OBJCOPY) call.
# hide __wrs_rtp_base adacore definition
     $(OBJCOPY) -L __wrs_rtp_base $(GPRBUILD_OBJECT)

7.8.2. Solving multiple definition of ‘main’ errors

If your project contains a main C routine and defines a main package, you will get the following error,

multiple definition of `main'

remove the useless main routine.

7.8.3. Solving undefined reference errors

If you get the following error,

undefined reference to `rmdir'

add fsapiUsr library to the project libraries.

  • run “Properties” contextual menu of the Ada project to open its properties pages.
  • select the “Build Properties” property page.
  • select the “Libraries” tab.
  • click the Add... button to add the fsapiUsr library file.
  • enter “-l fsapiUsr” to add the fsapiUsr library file.

If building a VxWorks Cert 6.x Real Time Process (RTP) Application you encounter one the following errors,

undefined reference to `_Unwind_Resume'
undefined reference to `_Unwind_RaiseException'
undefined reference to `_Unwind_DeleteException'
undefined reference to `_Unwind_ForcedUnwind'

Set RUNTIME to zfp or ravenscar-cert-rtp and rebuild the application. Edit the makefile of the project (usually gnat.makefile file) and for $(PROJECT_TYPE)=RTP change RUNTIME default value to zfp or ravenscar-cert-rtp Depending on your GNAT project file (GPR) content, you may be able to change the RUNTIME value from the Scenario Variables view. (see menu Window > Show View)


7.8.4. Solving “No rule to make target ‘*-stubs.o’ errors

When building VxWorks 653 2.x application projects converted to Ada project with previous GNATbench versions, and when the application project files are not located inside the workspace, for example when they are located in a git repository, the project cannot be built because the generated $(SSL_NAME)-stubs.o file cannot be located.

Edit the makefile of the project (usually gnat.makefile file) and replace the occurrences of $(WS_ROOT_DIR) with $(PRJ_ROOT_DIR)/..

7.8.6. Solving unknown gcc_except_table input section ‘dld’ warning

Using diab build specs, sometimes RTP application link, reports the following ‘dld’ warning.

dld: warning: Don't know where to allocate input section:
dld: no matching input specification found in linker command file.
dld: Section name: .gcc_except_table

The workaround is to edit the linker scripts (e.g. diab-<version>/conf/rtp.dld and rtp7.dld) to add *(.gcc_except_table) to the list of sections to merge into the text section.

.text (=TEXT) : {
*(.rodata.cst8) *(.rodata.cst4) *(.rodata.cst16) *(.rodata.str1.1)
*(.rodata.str1.2) *(.rodata.str1.4) *(.rodata.str1.8) *(.rodata.str1.16)
*(.rodata.str1.32) *(.rodata.str1.64) *(.rodata.str1.128)