From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16386 invoked by alias); 12 May 2009 18:29:25 -0000 Received: (qmail 16339 invoked by uid 22791); 12 May 2009 18:29:24 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 May 2009 18:29:16 +0000 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id n4CITBId013212; Tue, 12 May 2009 19:29:11 +0100 Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by zps35.corp.google.com with ESMTP id n4CIT9UP022708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 May 2009 11:29:09 -0700 Received: from localhost.localdomain.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id n4CIT71H014528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 12 May 2009 11:29:08 -0700 To: Roberto Bagnara Cc: gcc@gcc.gnu.org, "The Parma Polyhedra Library developers' list" Subject: Re: Trouble building Graphite References: <4A09A619.70503@cs.unipr.it> From: Ian Lance Taylor Date: Tue, 12 May 2009 18:44:00 -0000 In-Reply-To: <4A09A619.70503@cs.unipr.it> (Roberto Bagnara's message of "Tue\, 12 May 2009 18\:38\:49 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00315.txt.bz2 Roberto Bagnara 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