boost-devel Requires: boost, which itself needs to Requires all
library subpackages so that the libboost_*.so symlinks are resolved,
and packages can safely link to them.
This change addresses the issue of
https://github.com/boostorg/math/issues/1132
the patch addresses the issue where float_next() and float_prior() return
a domain error instead +INF or -INF. this issue is a regression in
Boost 1.79.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
This change addresses the issue of
https://github.com/boostorg/multiprecision/issues/553,
the fix prevents an application from crash due to an exception
thrown in a function marked `noexcept`, when converting a `cpp_int`
to a float, if the value of this `cpp_int` cannot be represented with
a float. this issue is a regression in Boost 1.79, see more details
at https://github.com/boostorg/multiprecision/pull/618
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
This change silences the warning when compiling Boost.accumulators
with GCC 13. as some projects using Boost.Accumulators are compiled
with -Werror. Without this change, these project would have to disable
-Wuninitialized warning or silence it temporarily when including
the offending headers. Neither of these two solution is ideal from
a developer's perspective. so let's apply the patch when packaging
Boost. The patch was included by Boost 1.83.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
See https://fedoraproject.org/wiki/Changes/F38Boost181
Drop patches:
deleted: boost-1.58.0-pool.patch
deleted: boost-1.58.0-pool-test_linking.patch
deleted: boost-1.78.0-build-optflags.patch
deleted: boost-1.73-locale-empty-vector.patch
deleted: boost-1.76.0-fix_multiprecision_issue_419-ppc64le.patch
deleted: boost-1.76.0-ptr_cont-xml.patch
deleted: boost-1.78.0-fix-b2-staging.patch
deleted: boost-1.76.0-enum_type_object-type-python-3.11.patch
- New Boost.URL runtime component
- boost_build directory is now b2 in upstream, renamte to boost_build on install
This doesn't restore the Provides: boost-nowide-devel as that is only
used in one package, which is already changing. The Provides: boost-jam
isn't needed either.
See https://fedoraproject.org/wiki/Changes/F37Boost178
Drop patches:
deleted: boost-1.75.0-build-optflags.patch
deleted: boost-1.75.0-no-rpath.patch
deleted: boost-1.76.0-b2-build-flags.patch
deleted: boost-1.76.0-fix-include-inside-boost-namespace.patch
deleted: boost-1.76.0-fix-duplicate-typedef-in-mp.patch
Fix silent dropping of some libraries
See https://github.com/bfgroup/b2/pull/113
This prevents installing the 32-bit boost-iostreams. package on 64-bit
systems, because the 32-bit xz package is not available.
The dependency on the shared lib will be added automatically anyway.
The previous version of boost was already rebuilt for Python 3.9 but the
new Boost version needs to be rebuilt now that python3-3.8.3-1.fc33 is
in rawhide.
Boost upstream does not link Boost.Python libraries to libpython, which
matches the advice from Python upstream as well. Drop the Fedora patches
which cause libpython to be linked to. Those patches have been causing
problems for a while anyway.
Now that we only build Boost.Python for one version of Python there is
no benefit to keeping `boost-python3` and `boost-python3-devel` separate
from the main `boost` and `boost-devel` packages.
This change makes `boost` install `boost-python3` (and recommend
`boost-numpy3` if `python3-numpy` is already installed). The
`boost-python3-devel` subpackage is dropped and its contents added to
the main `boost-devel` subpackage instead.
The %build and %install steps still build the py3 pieces separately,
which is no longer necessary now that we don't build both py2 and py3
subpackages.
This patch is supposed to make boost::mpl::print issue a warning with
GCC, but actually it prevents it from warning, whereas the upstream code
does warn.
New library: Boost.Contract
The Python-related shared libraries now carry the full Python version,
eg _python27.so and _python37.so
Drop patches:
deleted: boost-1.66.0-address-model.patch
deleted: boost-1.66.0-compute.patch
deleted: boost-1.66.0-numpy3.patch
deleted: boost-1.66.0-python37.patch
deleted: boost-1.66.0-spirit-abs-overflow.patch
The Fedora OpenMPI and MPICH Flatpaks pose considerable challenges for
rebuilding to use in Flaptaks with prefix=/app - in particular because
of their use of environment-modules. An analysis of all graphical
applications in Fedora that we might want to create Flatpak containers
of shows no apps that use the OpenMPI and MPICH subpackages of boost,
though many other boost packages are used. So simply disabling openmpi
and mpich for Flatpak rebuilds is the simplest approach.
The %{python2_version} and %{python3_version} macros are pre-defined, so
we don't need to use ver.py to find the versions.
Use shell variable for Python 3 ABI flags instead of global macro. This
avoids errors when creating SRPMs or running rpmlint, because by
delaying the command until the %build stage we can rely on python3-devel
being installed.
Rename all subpackages using python2 from boost-xxx to boost-xxx2.
Split new subpackage boost-python2-devel out of boost-devel.
Split new subpackage boost-openmpi-python2-devel out of boost-openmpi-devel.
Split new subpackage boost-mpich-python2-devel out of boost-mpich-devel.
Enable conditional build for python2 packages.
The Group tag is not used by RPM.
In F28 the ldconfig %post and %postun scriptlets are done automatically
and so don't need to be explicit in the spec file.
This should hopefully fix linking with boost_context, which currently
fails on ppc64le with:
/usr/lib/gcc/ppc64le-redhat-linux/7/../../../../lib64/libboost_context.so:
undefined reference to `std::__once_functor@GLIBCXX_3.4.11'
A change to tools/build/src/tools/python.jam means that the python=2.7
argument to b2 is ignored and both libboost_python.so and
libboost_python3.so are linked to libpython2.7.so. Reverting that change
restores the previous behaviour that allowed building Boost.Python in
two different ways.
PYTHON2_VERSION needs to be visible across sections, and it's awkward to
define it twice. Just make it a macro. %global expands once only.
PYTHON3_* technically doesn't need this, but let's be consistent.
glibc newly defines a macro TIME_UTC, which collides with boost::TIME_UTC.
We can't avoid expanding that macro, but the value happens to be the same
as that of boost::TIME_UTC. So drop enum xtime_clock_types. Update boost
to use macro TIME_UTC instead of the scoped enum value. External clients
will have to do the same.
- the reason being that we would have to provide this to preserve upgrade
path, which would clutter the spec file further
- and all other packages name this sub-package "example"
(Container and Move) and a new library (Locale).
Resolves: #754865
Added a patch with a manual page for the bjam executable.
Added a patch to fix the non-UTF8-encoded example source file.
Re-worked a little bit the example section, so as to fix the
DOS-formatted and the ISO-8859-encoded files. The examples
sub-package itself has been renamed into examples-devel.
- boost doesn't bring in the MPI stuff. Instead, $MPI-devel does. It needs
to, so that the symlinks don't dangle.
- boost-graph-$MPI depends on boost-$MPI so that boost-mpich2 doesn't
satisfy the SONAME dependency of boost-graph-openmpi.
- Resolves: #559009
Mon Jan 18 2010 Denis Arnaud <denis.arnaud_fedora@m4x.org> - 1.41.0-2.2
- Further split the Boost.MPI sub-package into boost-mpi and
boost-mpi-python
- Changed the description of Boost.MPI according to the actual dependency
(MPICH2 rather than OpenMPI)
- Added a few details on the generation of the mpi.so library
Wed May 06 2009 Benjamin Kosnik <bkoz@redhat.com> - 1.39.0-0.3
- Fixes for rpmlint.
Wed May 06 2009 Petr Machata <pmachata@redhat.com> - 1.39.0-0.2
- Split up boost package to sub-packages per library
- Resolves: #496188
Wed May 06 2009 Benjamin Kosnik <bkoz@redhat.com> - 1.39.0-0.1
- Rebase to 1.39.0.
- Add --with docs_generated.
- #225622: Substitute optflags at prep time instead of RPM_OPT_FLAGS.
- Fix rpmlint warnings on tabs and spaces.
- Bump SONAME to 4
Tue Nov 17 2008 Benjamin Kosnik <bkoz@redhat.com> - 1.37.0-0.1
- Rebase to 1.37.0.
Tue Oct 21 2008 Benjamin Kosnik <bkoz@redhat.com> - 1.36.0-1
- Rebase to 1.36.0.
Mon Oct 6 2008 Petr Machata <pmachata@redhat.com> - 1.34.1-17
- Fix gcc43 patch to apply cleanly under --fuzz=0
- Resolves: #465003
Mon Aug 11 2008 Petr Machata <pmachata@redhat.com> - 1.36.0-0.1.beta1
- Rebase to 1.36.0.beta1
- Drop boost-regex.patch and portions of boost-gcc43.patch, port the rest
- Automate SONAME tracking and bump SONAME to 4
- Adjust boost-configure.patch to include threading=single,multi explicitly
- Drop boost-regex.patch and portions of boost-gcc43.patch, port the rest
- Automate SONAME tracking and bump SONAME to 4
- Adjust boost-configure.patch to include threading=single,multi explicitly
Limit actions to x number of seconds after which they are stopped
.PP
\fB-n\fP
.br
Don't actually execute the updating actions
.PP
\fB-ox\fP
.br
Write the updating actions to file x
.PP
\fB-px\fP
.br
x=0, pipes action stdout and stderr merged into action output
.PP
\fB-q\fP
.br
Quit quickly as soon as a target fails
.PP
\fB-sx=y\fP
.br
Set variable x=y, overriding environment
.PP
\fB-tx\fP
.br
Rebuild x, even if it is up-to-date
.PP
\fB-v\fP
.br
Print the version of b2 and exit
.PP
\fB--x\fP
.br
Option is ignored
.SH"DESCRIPTION"
.PP
This section provides the information necessary to create your own projects using \fIBoost\&.Build\fP The information provided here is relatively high-level, and Chapter 6, Reference as well as the on-line help system must be used to obtain low-level documentation (see --help)
.PP
\fIBoost\&.Build\fP actually consists of two parts - \fIBoost\&.Jam\fP, a build engine with its own interpreted language, and \fIBoost\&.Build\fP itself, implemented in \fIBoost\&.Jam's\fP language\&. The chain of events when you type b2 on the command line is as follows:
.IP"\(bu"2
\fIBoost\&.Jam\fP tries to find \fIBoost\&.Build\fP and loads the top-level module\&. The exact process is described in the section called “Initialization”
.PP
.PP
.IP"\(bu"2
The top-level module loads user-defined configuration files, \fIuser-config\&.jam\fP and \fIsite-config\&.jam\fP, which define available toolsets
.PP
.PP
.IP"\(bu"2
The \fIJamfile\fP in the current directory is read That in turn might cause reading of further Jamfiles\&. As a result, a tree of projects is created, with targets inside projects
.PP
.PP
.IP"\(bu"2
Finally, using the build request specified on the command line, \fIBoost\&.Build\fP decides which targets should be built and how\&. That information is passed back to \fIBoost\&.Jam\fP, which takes care of actually running the scheduled build action commands
.PP
.PP
So, to be able to successfully use \fIBoost\&.Build\fP, you need to know only four things:
.IP"\(bu"2
How to configure \fIBoost\&.Build\fP (http://www.boost.org/boost-build2/doc/html/bbv2/overview/configuration.html)
.IP"\(bu"2
How to declare targets in Jamfiles (http://www.boost.org/boost-build2/doc/html/bbv2/overview/targets.html)
.IP"\(bu"2
How the build process works (http://www.boost.org/boost-build2/doc/html/bbv2/overview/build_process.html)
.PP
.PP
Some Basics about the \fIBoost\&.Jam\fP language\&. See the section called “Boost\&.Jam Language” (http://www.boost.org/boost-build2/doc/html/bbv2/overview/jam_language.html)
.SH"CONCEPTS"
.PP
\fIBoost\&.Build\fP has a few unique concepts that are introduced in this section\&. The best way to explain the concepts is by comparison with more classical build tools
.PP
When using any flavour of make, you directly specify targets and commands that are used to create them from other target\&. The below example creates a\&.o from a\&.c using a hardcoded compiler invocation command
.PP
a\&.o: a\&.c
.br
g++ -o a\&.o -g a\&.c
.PP
This is rather low-level description mechanism and it is hard to adjust commands, options, and sets of created targets depending on the used compiler and operating system\&.
.PP
To improve portability, most modern build system provide a set of higher-level functions that can be used in build description files\&. Consider this example:
.PP
add_program ('a', 'a\&.c')
.br
.PP
This is a function call that creates targets necessary to create executable file from source file a\&.c\&. Depending on configured properties, different commands line may be used\&. However, \fIadd_program\fP is higher-level, but rather thin level All targets are created immediately when build description is parsed, which makes it impossible to perform multi-variant builds\&. Often, change in any build property requires complete reconfiguration of the build tree
.PP
In order to support true multivariant builds, Boost\&.Build introduces the concept of metatarget—object that is created when build description is parsed and can be later called with specific build properties to generate actual targets
.PP
Consider an example:
.PP
exe a : a\&.cpp ;
.br
.PP
When this declaration is parsed, \fIBoost\&.Build\fP creates a metatarget, but does not yet decides what files must be created, or what commands must be used\&. After all build files are parsed, Boost\&.Build considers properties requested on the command line\&. Supposed you have invoked \fIBoost\&.Build\fP with:
.PP
\fIb2\fP toolset=gcc toolset=msvc
.br
.PP
In that case, the metatarget will be called twice, once with toolset=gcc and once with toolset=msvc\&. Both invocations will produce concrete targets, that will have different extensions and use different command lines\&. Another key concept is build property\&. Build property is a variable that affects the build process\&. It can be specified on the command line, and is passed when calling a metatarget
.PP
While all build tools have a similar mechanism, \fIBoost\&.Build\fP differs by requiring that all build properties are declared in advance, and providing a large set of properties with portable semantics
.PP
The final concept is property propagation\&. Boost\&.Build does not require that every metatarget is called with the same properties\&. Instead, the 'top-level' metatargets are called with the properties specified on the command line Each metatarget can elect to augment or override some properties (in particular, using the requirements mechanism, see the section called “Requirements”: http://www.boost.org/boost-build2/doc/html/bbv2/overview/targets.html#bbv2.overview.targets.requirements) Then, the dependency metatargets are called with modified properties and produce concrete targets that are then used in build process Of course, dependency metatargets maybe in turn modify build properties and have dependencies of their own\&.
.PP
For more in-depth treatment of the requirements and concepts, you may refer to SYRCoSE 2009 Boost\&.Build article (http://syrcose.ispras.ru/2009/files/04_paper.pdf)\&.
.SH"SEE ALSO"
.PP
\fBboost-libraries\fP(3)
.SH"SUPPORT"
.PP
Please report any bugs to https://svn.boost.org/trac/boost/
.SH"COPYRIGHT"
.PP
Boost Software License - Version 1\&.0 - August 17th, 2003
.PP
See the LICENSE_1_0\&.txt file for more information on that license, or directly on Internet:
["$tests_count" -ge "$TESTS_COUNT_MIN"]&& rlLogInfo "Test counter: $tests_count"|| rlFail "Test counter $tests_count should be greater than or equal to $TESTS_COUNT_MIN"
