Boost logo

Boost :

Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr that have a LGPL license ?
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-20 16:58:30

Hi Paul,

> So what do we do?
> Might we enter into discussion with GMP and mfpr developers to get explicit
> permission to package their library within Boost?
CGAL already distributes the Windows versions of gmp and mpfr, so I know they
don't mind.

OTOH, there are practical issues with distibuting them since they cannot be
built in windows without the separate port provided by Brian Gladman:

> IANAL but I feel this issue should be resolved and a decision recorded.
At the very least I think it should be discussed whether is OK or not to depend
on external components, to what extent, and how so.

As pointed out by Sebastian Redl, there is some form of precedence to this in
Boost.Python and Boost.MPI, both naturally requiring Python and MPI, resp.

Those libs are specifically wrappers for the external components, while in the
case under consideration (GTL), the external GMP (and potentially MPFR) libs are
DEPENDENCIES, thus it could be argued that this is different than Boost.Python
and Boost.MPI and the required functionality *should^* exist within Boost itself.

A much more direct precedence for the GTL case is the Boost.Rational library. It
depends on an integer concept and external big integers are reasonable and even
almost required in practice.

But the GTL case is slightly different because, IMO, the dependent concept
should explicitely require unlimited precision since the library specifically
uses it to *guarantee* robustness. Thus, unlike the case with Boost.Rational,
users should be totally forbiden from using built-in types. They should be left
with no choice but to pick some external component fulfilling the unlimited
precision requirement, otherwise, GTL will have no choice but to fail to
guarantee 100% robustness.

 From the POV of standarization of boost libraries (one of the principal goals),
dependencies on libraries such as GMP or MPFR poses a problem since those
libraries provide highly mature *C* interfaces, not C++ (there is a gmpxx
wrapper lib but it is hardly used compared to the gmp C API). They can't and
won't ever be standarized, at least not within the "C++" SCL (but they could
theoretically be standarized in std C and so included in std C++)

OTOH, producing a high quality Boost library equivalent in performance and
functionality to GMP/MPFR is very very difficult since those GNU projects have
been evolving and maturing for many years. It seems to me somewhat unrealistic
to expect something like that in Boost.

A different and much less ambitious goal could be to come up with a good C++
*interface* to *those* libraries. That is, C++ number types specifically
designed to be implementable on top of a C API like that of GMP and MPFR.

As to what to require to GTL, I think it should be allowed to depend on concepts
which have no models on either native types nor standard library or boost
components, even if that clearly indicates the need for an external library.


Fernando Cacciola
SciSoft Consulting, Founder

Boost list run by bdawes at, gregod at, cpdaniel at, john at