Including GMP as an upstream package (was problems building fortran)

[Roger Sayle]

On Thu, 12 Feb 2004, Richard Earnshaw wrote:
> 1) Fortran relies on an external library package gmp being installed on
> the system.
> 2) Even when that is installed, it doesn't find it automatically, even
> when it's in a standard place for the OS concerned.
> 3) And when it is told where the library is, it doesn't link to it
> correctly (no -rpath option), so the executable is unable to locate the
> library at run time.
>
> For other libraries that are needed for a functioning compiler, such as
> zlib, we've pulled these in-tree.  Why are we not doing this for gmp?


That's a conincidence.  I was just writing to Kaveh Ghazi yesterday
asking about how one formally goes about requesting such a decision
from the GCC steering committee.


The selected highlights of that discussion are reproduced below:

>> I was wondering whether as a member of the GCC SC, you could ask your
>> fellow colleagues and Torbjorn, whether there would be any political
>> impediment to classifying "gmp" as an upstream package and
>> including/incorporating it with GCC?
>>
>> With the recent decision to fold tree-ssa into mainline, we'll no
>> longer even build (g)fortran on platforms that don't already have
>> the gmp libraries installed, i.e. IRIX, Solaris, HP-UX, AIX, etc...
>> One way to get around this problem is to include gmp, the same way
>> as we do with zlib, and use the local copy unless someone specifies
>> --with-system-zlib or --with-system-gmp.  This also prevents
>> problems with version differences, and will have the added benefit
>> of keeping GCC's and gmp's longlong.h closer together.
>>
>> I'm sure once the SC obtains permission and gives its blessing to
>> such as project, Nathanael could work out the configure and host
>> vs. build vs. target issues.  These would be needed for a cross
>> compiler for gfortran anyway.
>>
>> Of course, longer term this ends up being a positive step towards
>> investigating the use of "mpfr" as a replacement of GCC's real.c.
>> At the moment no progress is being made, and instead functionality
>> enhancements such as yours are being shot down, creating an impasse.
>>
>> A potential concern is that "mpfr" may turn out to be too slow or
>> too memory hungry to use in a production compiler.  However without
>> doing the experiment we'll never know.  Instead we loose ground
>> to just about every major vendor compiler, that doesn't have to
>> worry about differing host/target floating point formats, so can
>> evaluate sin, cos, cbrt and *every* other math function trivially at
>> compile-time by just calling the host's libc equivalent.  For GCC to
>> continue to catch up with Intel and Microsoft compilers, for example,
>> we need to start making so forward progress on this politically.


In addition to you, me and Kaveh, I believe Richard Henderson
and Joseph Myers are also in favour of at least investigating gmp's
mpfr as a replacement or subroutine library providing functionality
for real.c/real.h.  Presumably Paul Brook and Toon would also favour
including gmp with GCC to simplify gfortan issues.  Though hopefully
these and others can publically lend support to such a proposal in
this thread (or correct any misunderstaing/misrepresentation of mine).

Presumably Torbjorn must first give his permission, and then the SC
or perhaps just a single global-write priviledge maintainer must
(pre)approve a patch to place it in CVS in gcc and src.  Finally, the
"configury" folks will need to wire it up appropriately to the build
process, and the usual portability testing as GMP then gets compiled
using the host compiler on GCC's numerous supported platforms.

Alas there is little I can contribute, except force of will:

Please?  Pretty please?

Roger
--