This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: fix the --with-mpfr-dir=PATH configure flag

Kaveh R. GHAZI wrote:

> For this discussion, it's actually neither.  The installation logic
> remains the same across mpfr releases.  The second problem you mentioned
> (that the GNU/linux distributors diddle with the locations) also occurs
> but I solved it with a separate patch also cc:ed to you here:

I'm sorry.  I freely confess that I have hard a time keeping up with all
that's going on sometimes.  Thanks for being patient with me!

> The problem problem for this patch is not the installation logic, it's the
> mpfr >build directory< structure.  We care about that because the flag I'm
> fixing is GCC's --with-mpfr-dir=PATH which allows one to specify a path to
> an mpfr source directory where you just compiled mpfr.  Presumably this is
> for people who don't want to install mpfr just to build gfortran.

I didn't fully understand this before.  I'm sorry.

This switch gives us an dependency on the internals of a package we do
not maintain.  That sounds like a bad idea.  Part of the justification
for this may be people who want to build these libraries in-tree, but I
think we should just stop trying to support that -- until/unless the
top-level build machinery begins to support staged installations, and,
then we still wouldn't need special build-directory logic.

So, I think that this switch should be removed from mainline and 4.2.
It's just not that hard to type "make install".  Even though the issue
at hand is 4.1, not mainline, I do think the mainline question is
relevant, because the existence of the switch means that we might well
see the same kind of breakage in 4.2, and every future GCC release.

Given that new libmpfr is causing problems for GCC 4.1 users, I agree
with you that your patch is appropriate there.  Removing the option from
4.1.2 would be a needless incompatibility with 4.1.1.  However, I think
that we should force ourselves to reach consensus on future releases
before applying to 4.1, so that we don't get to this same situation with


Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]