To link to libraries whose build instructions aren't given in a Jamfile, you need to create lib targets with an appropriate file property. Target alternatives can be used to associate multiple library files with a single conceptual target. For example:

# util/lib2/Jamfile
lib lib2
    :
    : <file>lib2_release.a <variant>release
    ;

lib lib2
    :
    : <file>lib2_debug.a <variant>debug
    ;

This example defines two alternatives for lib2, and for each one names a prebuilt file. Naturally, there are no sources. Instead, the <file> feature is used to specify the file name.

Once a prebuilt target has been declared, it can be used just like any other target:

exe app : app.cpp ../util/lib2//lib2 ;

As with any target, the alternative selected depends on the properties propagated from lib2's dependents. If we build the release and debug versions of app it will be linked with lib2_release.a and lib2_debug.a , respectively.

System libraries—those that are automatically found by the toolset by searching through some set of predetermined paths—should be declared almost like regular ones:

lib pythonlib : : <name>python22 ;

We again don't specify any sources, but give a name that should be passed to the compiler. If the gcc toolset were used to link an executable target to pythonlib, -lpython22 would appear in the command line (other compilers may use different options).

We can also specify where the toolset should look for the library:

lib pythonlib : : <name>python22 <search>/opt/lib ;

And, of course, target alternatives can be used in the usual way:

lib pythonlib : : <name>python22 <variant>release ;
lib pythonlib : : <name>python22_d <variant>debug ;

A more advanced use of prebuilt targets is described in the section called “Targets in site-config.jam”.