Как установить boost ubuntu
Обновлено: 03.07.2024
The most reliable way to get a copy of Boost is to download a distribution from SourceForge:
In the directory where you want to put the Boost installation, execute
RedHat, Debian, and other distribution packagers supply Boost library packages, however you may need to adapt these instructions if you use third-party packages, because their creators usually choose to break Boost up into several packages, reorganize the directory structure of the Boost distribution, and/or rename the library binaries. 1 If you have any trouble, we suggest using an official Boost distribution from SourceForge.
The organization of Boost library headers isn't entirely uniform, but most libraries follow a few patterns:
Some older libraries and most very small libraries place all public headers directly into boost/.
Most libraries' public headers live in a subdirectory of boost/, named after the library. For example, you'll find the Python library's def.hpp header in
Most libraries place private headers in a subdirectory called detail/, or aux_/. Don't expect to find anything you can use in these directories.
It's important to note the following:
The path to the boost root directory (often /usr/local/boost_1_67_0) is sometimes referred to as $BOOST_ROOT in documentation and mailing lists .
depending on your preference regarding the use of angle bracket includes.
Don't be distracted by the doc/ subdirectory; it only contains a subset of the Boost documentation. Start with libs/index.html if you're looking for the whole enchilada.
The first thing many people want to know is, “how do I build Boost?” The good news is that often, there's nothing to build.
Nothing to Build?
Most Boost libraries are header-only: they consist entirely of header files containing templates and inline functions, and require no separately-compiled library binaries or special treatment when linking.
A few libraries have optional separately-compiled binaries:
To keep things simple, let's start by using a header-only library. The following program reads a sequence of integers from standard input, uses Boost.Lambda to multiply each number by three, and writes them to standard output:
Copy the text of this program into a file called example.cpp.
Now, in the directory where you saved example.cpp, issue the following command:
To test the result, type:
4.1 Errors and Warnings
Don't be alarmed if you see compiler warnings originating in Boost headers. We try to eliminate them, but doing so isn't always practical. 3 Errors are another matter. If you're seeing compilation errors at this point in the tutorial, check to be sure you've copied the example program correctly and that you've correctly identified the Boost root directory.
If you want to use any of the separately-compiled Boost libraries, you'll need to acquire library binaries.
5.1 Easy Build and Install
Issue the following commands in the shell (don't type $; that represents the shell's prompt):
Select your configuration options and invoke ./bootstrap.sh again without the --help option. Unless you have write permission in your system's /usr/local/ directory, you'll probably want to at least use
to install somewhere else. Also, consider using the --show-libraries and --with-libraries= library-name-list options to limit the long wait you'll experience if you build everything. Finally,
5.2 Or, Build Custom Binaries
If you're using a compiler other than your system's default, you'll need to use Boost.Build to create binaries.
You'll also use this method if you need a nonstandard build variant (see the Boost.Build documentation for more details).
5.2.1 Install Boost.Build
Boost.Build is a text-based system for developing, testing, and installing software. First, you'll need to build and install it. To do this:
- Go to the directory tools/build/.
- Run bootstrap.sh
- Run b2 install --prefix=PREFIX where PREFIX is the directory where you want Boost.Build to be installed
- Add PREFIX/bin to your PATH environment variable.
5.2.2 Identify Your Toolset
First, find the toolset corresponding to your compiler in the following table (an up-to-date list is always available in the Boost.Build documentation).
If you previously chose a toolset for the purposes of building b2, you should assume it won't work and instead choose newly from the table below.
| Toolset Name | Vendor | Notes |
|---|---|---|
| acc | Hewlett Packard | Only very recent versions are known to work well with Boost |
| borland | Borland | |
| como | Comeau Computing | Using this toolset may require configuring another toolset to act as its backend. |
| darwin | Apple Computer | Apple's version of the GCC toolchain with support for Darwin and MacOS X features such as frameworks. |
| gcc | The Gnu Project | Includes support for Cygwin and MinGW compilers. |
| hp_cxx | Hewlett Packard | Targeted at the Tru64 operating system. |
| intel | Intel | |
| msvc | Microsoft | |
| sun | Oracle | Only very recent versions are known to work well with Boost. Note that the Oracle/Sun compiler has a large number of options which effect binary compatibility: it is vital that the libraries are built with the same options that your appliction will use. In particular be aware that the default standard library may not work well with Boost, unless you are building for C++11. The particular compiler options you need can be injected with the b2 command line options cxxflags=``and ``linkflags=. For example to build with the Apache standard library in C++03 mode use b2 cxxflags=-library=stdcxx4 linkflags=-library=stdcxx4 . |
| vacpp | IBM | The VisualAge C++ compiler. |
If you have multiple versions of a particular compiler installed, you can append the version number to the toolset name, preceded by a hyphen, e.g. intel-9.0 or borland-5.4.3 .
5.2.3 Select a Build Directory
Boost.Build will place all intermediate files it generates while building into the build directory. If your Boost root directory is writable, this step isn't strictly necessary: by default Boost.Build will create a bin.v2/ subdirectory for that purpose in your current working directory.
5.2.4 Invoke b2
Change your current directory to the Boost root directory and invoke b2 as follows:
For a complete description of these and other invocation options, please see the Boost.Build documentation.
For example, your session might look like this:
That will build static and shared non-debug multi-threaded variants of the libraries. To build all variants, pass the additional option, “ --build-type=complete ”.
Building the special stage target places Boost library binaries in the stage/lib/ subdirectory of the Boost tree. To use a different directory pass the --stagedir= directory option to b2.
b2 is case-sensitive; it is important that all the parts shown in bold type above be entirely lower-case.
For a description of other options you can pass when invoking b2, type:
In particular, to limit the amount of time spent building, you may be interested in:
- reviewing the list of library names with --show-libraries
- limiting which libraries get built with the --with-library-name or --without-library-name options
- choosing a specific build variant by adding release or debug to the command line.
Boost.Build can produce a great deal of output, which can make it easy to miss problems. If you want to make sure everything is went well, you might redirect the output into a file by appending “>build.log 2>&1 ” to your command line.
5.3 Expected Build Output
During the process of building Boost libraries, you can expect to see some messages printed on the console. These may include
Notices about Boost library configuration—for example, the Regex library outputs a message about ICU when built without Unicode support, and the Python library may be skipped without error (but with a notice) if you don't have Python installed.
Messages from the build tool that report the number of targets that were built or skipped. Don't be surprised if those numbers don't make any sense to you; there are many targets per library.
Build action messages describing what the tool is doing, which look something like:
5.4 In Case of Build Errors
The only error messages you see when building Boost—if any—should be related to the IOStreams library's support of zip and bzip2 formats as described here. Install the relevant development packages for libz and libbz2 if you need those features. Other errors when building Boost libraries are cause for concern.
If it seems like the build system can't find your compiler and/or linker, consider setting up a user-config.jam file as described here. If that isn't your problem or the user-config.jam file doesn't work for you, please address questions about configuring Boost for your compiler to the Boost.Build mailing list.
To demonstrate linking with a Boost binary library, we'll use the following simple program that extracts the subject lines from emails. It uses the Boost.Regex library, which has a separately-compiled binary component.
There are two main challenges associated with linking:
- Tool configuration, e.g. choosing command-line options or IDE build settings.
- Identifying the library binary, among all the build variants, whose compile configuration is compatible with the rest of your project.
There are two main ways to link to libraries:
You can specify the full path to each library:
You can separately specify a directory to search (with -L directory) and a library name to search for (with -l library, 2 dropping the filename's leading lib and trailing suffix (.a in this case):
As you can see, this method is just as terse as method A for one library; it really pays off when you're using multiple libraries from the same directory. Note, however, that if you use this method with a library that has both static (.a) and dynamic (.so) builds, the system may choose one automatically for you unless you pass a special option such as -static on the command line.
In both cases above, the bold text is what you'd add to the command lines we explored earlier.
6.1 Library Naming
In order to choose the right binary for your build configuration you need to know how Boost binaries are named. Each library filename is composed of a common sequence of elements that describe how it was built. For example, libboost_regex-vc71-mt-d-x86-1_34.lib can be broken down into the following elements:
lib Prefix: except on Microsoft Windows, every Boost library name begins with this string. On Windows, only ordinary static libraries use the lib prefix; import libraries and DLLs do not. 4 boost_regex Library name: all boost library filenames begin with boost_. -vc71 Toolset tag: identifies the toolset and version used to build the binary. -mt Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt . -d
ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key Use this library when: Boost.Build option s linking statically to the C++ standard library and compiler runtime support libraries. runtime-link=static g using debug versions of the standard and runtime support libraries. runtime-debugging=on y using a special debug build of Python. python-debugging=on d building a debug version of your code. 5 variant=debug p using the STLPort standard library rather than the default one supplied with your compiler. stdlib=stlport
For example, if you build a debug version of your code for use with debug versions of the static runtime library and the STLPort standard library, the tag would be: -sgdp . If none of the above apply, the ABI tag is ommitted.
Architecture and address model tag: in the first letter, encodes the architecture as follows:
Key Architecture Boost.Build option x x86-32, x86-64 architecture=x86 a ARM architecture=arm i IA-64 architecture=ia64 s Sparc architecture=sparc m MIPS/SGI architecture=mips* p RS/6000 & PowerPC architecture=power
The two digits following the letter encode the address model as follows:
-1_34 Version tag: the full Boost release number, with periods replaced by underscores. For example, version 1.31.1 would be tagged as "-1_31_1". .lib Extension: determined according to the operating system's usual convention. On most unix-style platforms the extensions are .a and .so for static libraries (archives) and shared libraries, respectively. On Windows, .dll indicates a shared library and .lib indicates a static or import library. Where supported by toolsets on unix variants, a full version extension is added (e.g. ".so.1.34") and a symbolic link to the library file, named without the trailing version number, will also be created.
Key Address model Boost.Build option 32 32 bit address-model=32 64 64 bit address-model=64
6.2 Test Your Program
To test our subject extraction, we'll filter the following text file. Copy it out of your browser and save it as jayne.txt:
If you linked to a shared library, you may need to prepare some platform-specific settings so that the system will be able to find and load it when your program is run. Most platforms have an environment variable to which you can add the directory containing the library. On many platforms (Linux, FreeBSD) that variable is LD_LIBRARY_PATH, but on MacOS it's DYLD_LIBRARY_PATH, and on Cygwin it's simply PATH. In most shells other than csh and tcsh, you can adjust the variable as follows (again, don't type the $—that represents the shell prompt):
Once the necessary variable (if any) is set, you can run your program as follows:
The program should respond with the email subject, “Will Success Spoil Rock Hunter?”
This concludes your introduction to Boost and to integrating it with your programs. As you start using Boost in earnest, there are surely a few additional points you'll wish we had covered. One day we may have a “Book 2 in the Getting Started series” that addresses them. Until then, we suggest you pursue the following resources. If you can't find what you need, or there's anything we can do to make this document clearer, please post it to the Boost Users' mailing list.
Good luck, and have fun!
—the Boost Developers
I am trying to build the Boost library (1.68) from sources on Ubuntu 18.04.
Questions:
1) For a same version, is it equivalent to a sudo apt-get install libboost-all-dev ? . which basically will install all theses deps:
2) I basically followed the instructions:
running ./bootstrap.sh from where I downloaded (i.e. in /opt/boost_18_0/bootstrap.sh )
and then ./b2
at the end of the b2 process, it showed:
I wonder why it's not located in /usr/local where it should according to the bootstrap.sh default setting for the --prefix option?
1 Answer 1
1) Is it equivalent to a sudo apt-get install libboost-all-dev
No. sudo apt-get install libboost-all-dev will install whatever x.y.z version of the boost libraries your distro (Debian, Ubuntu . ) has packaged as libboost-all-dev in the latest package updates that you have applied to your system. On my Ubuntu 18.04 system that happens to be 1.65.1 right now. Building and installing the tarball boost_1_68_0.tar.bz2 that you downloaded will of course give you version 1.68.0.
If your package manager provides a libboost-all-dev at version 1.68.0 (or the same version that your download as source), then building and installing from the source tarball will provide your boost client projects with exactly the same boost resources via compilation and linkage as installing the libboost-all-dev package.
But installing that package will not create the same directories and files in your filesystem as building and installing the source tarball unless with ./bootstrap.sh you configure the same installation paths ( --prefix , --includedir , --libdir . ) as are used by the apt package installation. So, e.g. My apt installation of libboost-all-dev installs the boost headers under /usr/include/boost and the boost library binaries under /usr/lib/x86_64-linux-gnu . But by default the source tarball installation will place the headers under /usr/local/include/boost and the library binaries under /usr/local/lib .
For a given version of boost, the only other difference between apt install libboost-all-dev and a source build and install with the default install prefix ( /usr/local ) is that after a source build and install, if you wish to link and run your programs with the boost shared (not static) libraries, you will need to run $ sudo ldconfig (in any directory) to update the OS loader's dynamic linkage cache. apt install libboost-all-dev will update the ldconfig cache automatically.
I wonder why it's not located in /usr/local where it should according to the bootstrap.sh default setting for the --prefix option?
That is because you have just built boost, but not installed it. You ran
in /opt/boost_1_68_0 , and when it finished it told you (amoung other things)
So then, as you say, you ran ./b2 . That is, to build. And when building had finished, you saw the output you've posted. It tells you that your successful boost build can now be used in client projects by specifying the compiler search option -I/opt/boost_1_68_0 and the linker search option -L/opt/boost_1_68_0/stage/lib . You can your use boost libraries like that, from the build directory /opt/boost_1_68_0 , without installing them. This would be what you'd have to do if you didn't have root privilege on your system.
But if you look again at the instructions you linked to, you'll find:
5.1 Easy Build and Install
Issue the following commands in the shell (don't type $; that represents the shell's prompt):
Select your configuration options and invoke ./bootstrap.sh again without the --help option. Unless you have write permission in your system's /usr/local/ directory, you'll probably want to at least use
to install somewhere else. Also, consider using the --show-libraries and --with-libraries=library-name-list options to limit the long wait you'll experience if you build everything. Finally,
You haven't run ./b2 install , and if your specified or default installation --prefix requires root privilege to write - which is the case for the default /usr/local - then you need to run
After that, you'll see the boost headers and libraries under /usr/local/include/boost and /usr/local/lib respectively, and you will not need to specify any explicit -I or -L options to compile boost headers or link boost libraries, because /usr/local/include is a default search path for the compiler and /usr/local/lib is a default search path for the linker.
This post will guide you how to install Boost libraries on Ubunt 16.04/18.04 Linux server. How do I install Boost C++ libraries 1.64 from a PPA in Ubuntu. How to install Boost from the default repositories on Ubuntu 16.04/18.04 Linux. How to install the latest version of Boost libraries from source package on Ubuntu Linux server.
What is Boost?
Boost is a set of libraries for the C++ programming language that provide support for tasks and structures such as linear algebra, pseudorandom number generation, multithreading, image processing, regular expressions, and unit testing. It contains over eighty individual libraries.
Install Boost C++ libraries via Default Repository
Boost is available on the default Ubuntu repositories, so you can install it with apt command directly, type the following commmand:
Verify the installed Boost Version
Once completed the installation process of Boost on your Ubuntu server, you can verify the installed boost version to check if the Boost is installed properly. Type one of the following commands to check version of boost:
Install Boost C++ libraries From PPA
You can also install Boost from a PPA on Ubuntu Linux, just type the following command:
This PPA can be added to your system manually by copying the lines below and adding them to your system’s software sources.
For Ubuntu 18.04:
For Ubuntu 18.10:
For Ubuntu 16.04:
Then you can try to install the Boost on your Ubuntu Linux, and the latest version of this PPA is 1.68, type the following command to install it:
Then the latest version 1.68 of boost would be installed on your Ubuntu Linux server.
Install Boost C++ libraries From Source Package
If you want to install the latest version of Boost( the current release version is 1.69) on your Ubuntu server, you have to install it from source package. And you need to download the latest archive package of boost from its official site firstly. . then execute the installation script. Just do the following steps:
Conclusion
You should know that how to install Boost C++ Libraries on your Ubuntu 16.04 or 18.04 Linux from this guide. And if you want to learn more about the Boost, you can go the below official web site to checking the getting started guide directly.
The most reliable way to get a copy of Boost is to download a distribution from SourceForge:
In the directory where you want to put the Boost installation, execute
RedHat, Debian, and other distribution packagers supply Boost library packages, however you may need to adapt these instructions if you use third-party packages, because their creators usually choose to break Boost up into several packages, reorganize the directory structure of the Boost distribution, and/or rename the library binaries. 1 If you have any trouble, we suggest using an official Boost distribution from SourceForge.
The organization of Boost library headers isn't entirely uniform, but most libraries follow a few patterns:
Some older libraries and most very small libraries place all public headers directly into boost/.
Most libraries' public headers live in a subdirectory of boost/, named after the library. For example, you'll find the Python library's def.hpp header in
Most libraries place private headers in a subdirectory called detail/, or aux_/. Don't expect to find anything you can use in these directories.
It's important to note the following:
The path to the boost root directory (often /usr/local/boost_1_61_0) is sometimes referred to as $BOOST_ROOT in documentation and mailing lists .
depending on your preference regarding the use of angle bracket includes.
Don't be distracted by the doc/ subdirectory; it only contains a subset of the Boost documentation. Start with libs/index.html if you're looking for the whole enchilada.
The first thing many people want to know is, “how do I build Boost?” The good news is that often, there's nothing to build.
Nothing to Build?
Most Boost libraries are header-only: they consist entirely of header files containing templates and inline functions, and require no separately-compiled library binaries or special treatment when linking.
A few libraries have optional separately-compiled binaries:
To keep things simple, let's start by using a header-only library. The following program reads a sequence of integers from standard input, uses Boost.Lambda to multiply each number by three, and writes them to standard output:
Copy the text of this program into a file called example.cpp.
Now, in the directory where you saved example.cpp, issue the following command:
To test the result, type:
4.1 Errors and Warnings
Don't be alarmed if you see compiler warnings originating in Boost headers. We try to eliminate them, but doing so isn't always practical. 3 Errors are another matter. If you're seeing compilation errors at this point in the tutorial, check to be sure you've copied the example program correctly and that you've correctly identified the Boost root directory.
If you want to use any of the separately-compiled Boost libraries, you'll need to acquire library binaries.
5.1 Easy Build and Install
Issue the following commands in the shell (don't type $; that represents the shell's prompt):
Select your configuration options and invoke ./bootstrap.sh again without the --help option. Unless you have write permission in your system's /usr/local/ directory, you'll probably want to at least use
to install somewhere else. Also, consider using the --show-libraries and --with-libraries= library-name-list options to limit the long wait you'll experience if you build everything. Finally,
5.2 Or, Build Custom Binaries
If you're using a compiler other than your system's default, you'll need to use Boost.Build to create binaries.
You'll also use this method if you need a nonstandard build variant (see the Boost.Build documentation for more details).
5.2.1 Install Boost.Build
Boost.Build is a text-based system for developing, testing, and installing software. First, you'll need to build and install it. To do this:
- Go to the directory tools/build/.
- Run bootstrap.sh
- Run b2 install --prefix=PREFIX where PREFIX is the directory where you want Boost.Build to be installed
- Add PREFIX/bin to your PATH environment variable.
5.2.2 Identify Your Toolset
First, find the toolset corresponding to your compiler in the following table (an up-to-date list is always available in the Boost.Build documentation).
If you previously chose a toolset for the purposes of building b2, you should assume it won't work and instead choose newly from the table below.
| Toolset Name | Vendor | Notes |
|---|---|---|
| acc | Hewlett Packard | Only very recent versions are known to work well with Boost |
| borland | Borland | |
| como | Comeau Computing | Using this toolset may require configuring another toolset to act as its backend. |
| darwin | Apple Computer | Apple's version of the GCC toolchain with support for Darwin and MacOS X features such as frameworks. |
| gcc | The Gnu Project | Includes support for Cygwin and MinGW compilers. |
| hp_cxx | Hewlett Packard | Targeted at the Tru64 operating system. |
| intel | Intel | |
| msvc | Microsoft | |
| sun | Oracle | Only very recent versions are known to work well with Boost. Note that the Oracle/Sun compiler has a large number of options which effect binary compatibility: it is vital that the libraries are built with the same options that your appliction will use. In particular be aware that the default standard library may not work well with Boost, unless you are building for C++11. The particular compiler options you need can be injected with the b2 command line options cxxflags=``and ``linkflags=. For example to build with the Apache standard library in C++03 mode use b2 cxxflags=-library=stdcxx4 linkflags=-library=stdcxx4 . |
| vacpp | IBM | The VisualAge C++ compiler. |
If you have multiple versions of a particular compiler installed, you can append the version number to the toolset name, preceded by a hyphen, e.g. intel-9.0 or borland-5.4.3 .
5.2.3 Select a Build Directory
Boost.Build will place all intermediate files it generates while building into the build directory. If your Boost root directory is writable, this step isn't strictly necessary: by default Boost.Build will create a bin.v2/ subdirectory for that purpose in your current working directory.
5.2.4 Invoke b2
Change your current directory to the Boost root directory and invoke b2 as follows:
For a complete description of these and other invocation options, please see the Boost.Build documentation.
For example, your session might look like this:
That will build static and shared non-debug multi-threaded variants of the libraries. To build all variants, pass the additional option, “ --build-type=complete ”.
Building the special stage target places Boost library binaries in the stage/lib/ subdirectory of the Boost tree. To use a different directory pass the --stagedir= directory option to b2.
b2 is case-sensitive; it is important that all the parts shown in bold type above be entirely lower-case.
For a description of other options you can pass when invoking b2, type:
In particular, to limit the amount of time spent building, you may be interested in:
- reviewing the list of library names with --show-libraries
- limiting which libraries get built with the --with-library-name or --without-library-name options
- choosing a specific build variant by adding release or debug to the command line.
Boost.Build can produce a great deal of output, which can make it easy to miss problems. If you want to make sure everything is went well, you might redirect the output into a file by appending “>build.log 2>&1 ” to your command line.
5.3 Expected Build Output
During the process of building Boost libraries, you can expect to see some messages printed on the console. These may include
Notices about Boost library configuration—for example, the Regex library outputs a message about ICU when built without Unicode support, and the Python library may be skipped without error (but with a notice) if you don't have Python installed.
Messages from the build tool that report the number of targets that were built or skipped. Don't be surprised if those numbers don't make any sense to you; there are many targets per library.
Build action messages describing what the tool is doing, which look something like:
5.4 In Case of Build Errors
The only error messages you see when building Boost—if any—should be related to the IOStreams library's support of zip and bzip2 formats as described here. Install the relevant development packages for libz and libbz2 if you need those features. Other errors when building Boost libraries are cause for concern.
If it seems like the build system can't find your compiler and/or linker, consider setting up a user-config.jam file as described here. If that isn't your problem or the user-config.jam file doesn't work for you, please address questions about configuring Boost for your compiler to the Boost.Build mailing list.
To demonstrate linking with a Boost binary library, we'll use the following simple program that extracts the subject lines from emails. It uses the Boost.Regex library, which has a separately-compiled binary component.
There are two main challenges associated with linking:
- Tool configuration, e.g. choosing command-line options or IDE build settings.
- Identifying the library binary, among all the build variants, whose compile configuration is compatible with the rest of your project.
There are two main ways to link to libraries:
You can specify the full path to each library:
You can separately specify a directory to search (with -L directory) and a library name to search for (with -l library, 2 dropping the filename's leading lib and trailing suffix (.a in this case):
As you can see, this method is just as terse as method A for one library; it really pays off when you're using multiple libraries from the same directory. Note, however, that if you use this method with a library that has both static (.a) and dynamic (.so) builds, the system may choose one automatically for you unless you pass a special option such as -static on the command line.
In both cases above, the bold text is what you'd add to the command lines we explored earlier.
6.1 Library Naming
In order to choose the right binary for your build configuration you need to know how Boost binaries are named. Each library filename is composed of a common sequence of elements that describe how it was built. For example, libboost_regex-vc71-mt-d-1_34.lib can be broken down into the following elements:
lib Prefix: except on Microsoft Windows, every Boost library name begins with this string. On Windows, only ordinary static libraries use the lib prefix; import libraries and DLLs do not. 4 boost_regex Library name: all boost library filenames begin with boost_. -vc71 Toolset tag: identifies the toolset and version used to build the binary. -mt Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt . -d
ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key Use this library when: Boost.Build option s linking statically to the C++ standard library and compiler runtime support libraries. runtime-link=static g using debug versions of the standard and runtime support libraries. runtime-debugging=on y using a special debug build of Python. python-debugging=on d building a debug version of your code. 5 variant=debug p using the STLPort standard library rather than the default one supplied with your compiler. stdlib=stlport
For example, if you build a debug version of your code for use with debug versions of the static runtime library and the STLPort standard library in “native iostreams” mode, the tag would be: -sgdpn . If none of the above apply, the ABI tag is ommitted.
-1_34 Version tag: the full Boost release number, with periods replaced by underscores. For example, version 1.31.1 would be tagged as "-1_31_1". .lib Extension: determined according to the operating system's usual convention. On most unix-style platforms the extensions are .a and .so for static libraries (archives) and shared libraries, respectively. On Windows, .dll indicates a shared library and .lib indicates a static or import library. Where supported by toolsets on unix variants, a full version extension is added (e.g. ".so.1.34") and a symbolic link to the library file, named without the trailing version number, will also be created.
6.2 Test Your Program
To test our subject extraction, we'll filter the following text file. Copy it out of your browser and save it as jayne.txt:
If you linked to a shared library, you may need to prepare some platform-specific settings so that the system will be able to find and load it when your program is run. Most platforms have an environment variable to which you can add the directory containing the library. On many platforms (Linux, FreeBSD) that variable is LD_LIBRARY_PATH, but on MacOS it's DYLD_LIBRARY_PATH, and on Cygwin it's simply PATH. In most shells other than csh and tcsh, you can adjust the variable as follows (again, don't type the $—that represents the shell prompt):
Once the necessary variable (if any) is set, you can run your program as follows:
The program should respond with the email subject, “Will Success Spoil Rock Hunter?”
This concludes your introduction to Boost and to integrating it with your programs. As you start using Boost in earnest, there are surely a few additional points you'll wish we had covered. One day we may have a “Book 2 in the Getting Started series” that addresses them. Until then, we suggest you pursue the following resources. If you can't find what you need, or there's anything we can do to make this document clearer, please post it to the Boost Users' mailing list.
Good luck, and have fun!
—the Boost Developers
Читайте также: