[PPL-devel] Trouble building Graphite

[Ian Lance Taylor]

Roberto Bagnara <bagnara at cs.unipr.it> writes:

> Ian Lance Taylor wrote:
>> I'm having some trouble building the Graphite support.
>>
>> Using ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.10.2.tar.gz :
>>
>> * Unlike gcc, does not support a --with-gmp option.
>>   + Does support a --with-libgmpxx-prefix option.
>
> What is the trouble with this?  I mean, is it a matter of syntax
> (you prefer the option to be called --with-gmp) or semantics
> (the --with-libgmpxx-prefix does not do the right thing)?

Let me start by saying that my message was aimed at the gcc developers
who have brought PPL and CLooG into the gcc build.  My message was not
aimed at the PPL developers.  When MPFR and GMP were brought into the
build, Kaveh spent quite a bit of time getting everything working
smoothly.  I think that the graphite developers need to spend a similar
amount of time getting the PPL and CLooG builds working smoothly.

--with-gmp vs. --with-libgmpxx-prefix is a matter of syntax.  Since all
gcc developers have to build these packages, it's inconvenient to have
to remember different configure options for different packages.


>> * If GMP was not built with C++ support, fails at build time.
>
> Yes, the C++ interface of GMP is required.  On the other hand,
> also the core of PPL is written in C++.  In whhich sense requiring
> the C++ interface of GMP is a trouble?

This is not a problem with PPL.  It's a problem with the existing build
instructions for gcc developers.


>> * If GMP was not built with exception support, complains at configure
>>   time, and recommends using CPPFLAGS=-fexceptions when building GMP.
>
> Well, "complain" is not the right word.  The PPL configuration script
> simply warns about the fact that the bounded memory capabilities of
> the PPL are not available.  Which is not a problem for GCC, since these
> capabilities are not used by CLooG.  The message was designed not
> to alarm people unnecessarily.  It says: "This is OK, if you do not
> plan to use the bounded memory capabilities offered by the PPL."
> Do you think a different wording could help?

Since I don't actually know anything about PPL, the message didn't mean
anything to me.  I didn't know whether GCC used those features or not.
So this is a problem with the existing build instructions: they need to
document this message and state clearly that it may be ignored for
purposes of using PPL with GCC.


>>   + CPPFLAGS is for preprocessor flags, and -fexceptions is not a
>>     preprocessor flag.  However, I admit that setting CFLAGS does not
>>     work correctly, as GMP seems to have special requirements for it.
>
> In facto, our use of CPPFLAGS is motivated by the fact that using CFLAGS
> for that purpose was not working, once upon a time.  See:
>
>   http://www.cs.unipr.it/pipermail/ppl-devel/2001-October/000639.html
>   http://www.cs.unipr.it/pipermail/ppl-devel/2001-October/000663.html
>
> Perhaps it works now: we will check again and, in case it works,
> we will amend the configuration script, documentation and web site.

It will still fail as these messages describe.  When the user sets
CFLAGS, it overrides the default CFLAGS setting.  The best way to make
this work may be to work with the GMP developers.  Again, this is not a
responsibility of the PPL developers, and in fact I have no idea whether
this matters for the ways in which GCC uses PPL.


>>   + I think they mean -funwind-tables anyhow.
>
> We do that because:
>
>        -funwind-tables
>            Similar to -fexceptions, except that it will just generate any
>            needed static data, but will not affect the generated code in any
>            other way.  You will normally not enable this option; instead, a
>            language processor that needs this handling would enable it on your

As far as I know, enabling -funwind-tables for C code is sufficient to
throw exceptions from C++ code to C++ code across that C code.  The
documentation is somewhat misleading.  You never need to specify this
option when your program is written entirely in one language.  Things
are different in multi-language programs.

Ian