Re: [PPL-devel] Graphite build fails if PPL configured with --disable-shared
Janis Johnson wrote:
On Mon, 2009-05-11 at 13:07 -0700, Ian Lance Taylor wrote:
Another Graphite build issue: it appears that I must not use --disable-shared when I configure PPL. If I do use --disable-shared, I get this:
/home/iant/gnu/ppl-0.10.2-install/lib/libppl_c.a(ppl_c_implementation_common.o): In function `finalize': /home/iant/gnu/ppl-0.10.2/interfaces/C/../../src/ppl.hh:1842: undefined reference to `operator delete(void*)'
followed by thousands of similar errors. This is unfortunate, as it means that I must manually set LD_LIBRARY_PATH to the directory where the PPL library is installed. This also makes it harder for anybody else to run the compiler that I build. This needs to be fixed.
I get around this by setting LDFLAGS for the ppl configure:
LDFLAGS="-static" \ ./configure \ --prefix=$PREFIX \ --build=powerpc-linux \ --with-gnu-ld \ --with-libgmp-prefix=$PREFIX \ --with-libgmpxx-prefix=$PREFIX \ --disable-shared
I am not sure I understand: we trust that Libtool, which provides us with the --disable-shared option, will do the right thing. And it seems it does here: the static library is built and passes its checks.
Perhaps you want something different from what --disable-shared promises, that is, not to build any shared libraries?
I copy libstdc++.a into the directory with the other GCC host libraries (gmp/mpfr/ppl/cloog/mpc).
Building these libraries is indeed quite painful.
Any suggestion about how to improve the PPL is welcome. This, of course, applies also to the build machinery. All the best,
Roberto
Roberto Bagnara bagnara@cs.unipr.it writes:
Janis Johnson wrote:
On Mon, 2009-05-11 at 13:07 -0700, Ian Lance Taylor wrote:
Another Graphite build issue: it appears that I must not use --disable-shared when I configure PPL. If I do use --disable-shared, I get this:
/home/iant/gnu/ppl-0.10.2-install/lib/libppl_c.a(ppl_c_implementation_common.o): In function `finalize': /home/iant/gnu/ppl-0.10.2/interfaces/C/../../src/ppl.hh:1842: undefined reference to `operator delete(void*)'
followed by thousands of similar errors. This is unfortunate, as it means that I must manually set LD_LIBRARY_PATH to the directory where the PPL library is installed. This also makes it harder for anybody else to run the compiler that I build. This needs to be fixed.
I get around this by setting LDFLAGS for the ppl configure:
LDFLAGS="-static" \ ./configure \ --prefix=$PREFIX \ --build=powerpc-linux \ --with-gnu-ld \ --with-libgmp-prefix=$PREFIX \ --with-libgmpxx-prefix=$PREFIX \ --disable-shared
I am not sure I understand: we trust that Libtool, which provides us with the --disable-shared option, will do the right thing. And it seems it does here: the static library is built and passes its checks.
Perhaps you want something different from what --disable-shared promises, that is, not to build any shared libraries?
I copy libstdc++.a into the directory with the other GCC host libraries (gmp/mpfr/ppl/cloog/mpc).
Building these libraries is indeed quite painful.
Any suggestion about how to improve the PPL is welcome. This, of course, applies also to the build machinery.
I don't think this is a problem with PPL.
The problem is that PPL uses libstdc++ and gcc does not. Thus, linking against PPL configured with --disable-shared requires also linking against libstdc++. That is the part which needs to be improved when using gcc with PPL. We have ways to do it, but they are not good ways, and they are not documented on the Graphite_build wiki page.
Ian
On Tue, 2009-05-12 at 18:46 +0200, Roberto Bagnara wrote:
Any suggestion about how to improve the PPL is welcome. This, of course, applies also to the build machinery.
Hi Roberto,
I added some instructions on how to build to the GCC wiki (end of page):
http://gcc.gnu.org/wiki/Graphite_Build
They worked with ppl-0.10 and cloog-ppl-0.15 however they now fail with ppl-0.10.2 and cloog-ppl-0.15.3 on cloog-ppl-0.15.3 configure:
... checking for ppl_c.h... no configure: error: Can't find PPL headers.
Looking at config.log:
configure:20698: gcc -c -g -O2 -I/include -I/n/17/guerby/install-ppl2/gmp-4.2.4/include conftest.c >&5
configure is not adding the -I for ppl hence the failure. I checked and the wanted ppl_c.h was correctly installed so I don't think ppl-0.10.2 is the issue.
Looking more at cloog-ppl/configure I find stuff like:
<< # Check whether --with-ppl or --without-ppl was given. if test "${with_ppl+set}" = set; then withval="$with_ppl"
fi;
# Check whether --with-polylib_prefix or --without-polylib_prefix was given. if test "${with_polylib_prefix+set}" = set; then withval="$with_polylib_prefix"
fi;
# Check whether --with-polylib_exec_prefix or --without-polylib_exec_prefix was given. if test "${with_polylib_exec_prefix+set}" = set; then withval="$with_polylib_exec_prefix"
fi;
# Check whether --with-polylib_builddir or --without-polylib_builddir was given. if test "${with_polylib_builddir+set}" = set; then withval="$with_polylib_builddir"
fi;
Wich is obviously broken since all the tests are setting the same variable $withval and so --with-ppl just doesn't work. I looked at cloog-ppl-0.15 configure and it was ok.
Now I don't know how to fix configury stuff but may be someone can help here.
Also it would be nice if cloog-ppl-0.15.3.tar.gz top level directory was named with version "cloog-ppl-0.15.3" instead of the current version-less "cloog-ppl".
Thanks for your help,
Laurent
Laurent GUERBY laurent@guerby.net writes:
Looking more at cloog-ppl/configure I find stuff like:
<< # Check whether --with-ppl or --without-ppl was given. if test "${with_ppl+set}" = set; then withval="$with_ppl"
fi;
# Check whether --with-polylib_prefix or --without-polylib_prefix was given. if test "${with_polylib_prefix+set}" = set; then withval="$with_polylib_prefix"
fi;
# Check whether --with-polylib_exec_prefix or --without-polylib_exec_prefix was given. if test "${with_polylib_exec_prefix+set}" = set; then withval="$with_polylib_exec_prefix"
fi;
# Check whether --with-polylib_builddir or --without-polylib_builddir was given. if test "${with_polylib_builddir+set}" = set; then withval="$with_polylib_builddir"
fi;
Wich is obviously broken since all the tests are setting the same variable $withval and so --with-ppl just doesn't work. I looked at cloog-ppl-0.15 configure and it was ok.
The variable withval is only for use in the third argument (ACTION-IF-GIVEN) of AC_ARG_WITH. In all other places the variable with_PACKAGE should be used.
Andreas.
On Tue, 2009-05-12 at 21:31 +0200, Andreas Schwab wrote:
Laurent GUERBY laurent@guerby.net writes:
Looking more at cloog-ppl/configure I find stuff like:
<< # Check whether --with-ppl or --without-ppl was given. if test "${with_ppl+set}" = set; then withval="$with_ppl"
fi;
# Check whether --with-polylib_prefix or --without-polylib_prefix was given. if test "${with_polylib_prefix+set}" = set; then withval="$with_polylib_prefix"
fi;
# Check whether --with-polylib_exec_prefix or --without-polylib_exec_prefix was given. if test "${with_polylib_exec_prefix+set}" = set; then withval="$with_polylib_exec_prefix"
fi;
# Check whether --with-polylib_builddir or --without-polylib_builddir was given. if test "${with_polylib_builddir+set}" = set; then withval="$with_polylib_builddir"
fi;
Wich is obviously broken since all the tests are setting the same variable $withval and so --with-ppl just doesn't work. I looked at cloog-ppl-0.15 configure and it was ok.
The variable withval is only for use in the third argument (ACTION-IF-GIVEN) of AC_ARG_WITH. In all other places the variable with_PACKAGE should be used.
When I search for with_ppl in configure I get in order:
... # Check whether --with-ppl or --without-ppl was given. if test "${with_ppl+set}" = set; then withval="$with_ppl"
fi; ... echo "$as_me:$LINENO: checking for Parma Polyhedral Library (PPL)" >&5 echo $ECHO_N "checking for Parma Polyhedral Library (PPL)... $ECHO_C" >&6 if test "x$with_ppl" != "x" -a "x$with_ppl" != "xno"; then
if test "x$with_polylib_prefix" != "x" -o "x$with_polylib_exec_prefix" != "x" -o "x$with_polylib_builddir" != "x"; then { { echo "$as_me:$LINENO: error: --with-polylib and --with-ppl are mutually exclusive" >&5 echo "$as_me: error: --with-polylib and --with-ppl are mutually exclusive" >&2;} { (exit 1); exit 1; }; } fi
if test "x$with_ppl" != "xyes" ; then ...
So 0.15.3 configure does not set $with_ppl variable at all.
Laurent
Laurent GUERBY laurent@guerby.net writes:
So 0.15.3 configure does not set $with_ppl variable at all.
Sure it does. Look at the argument parsing loop.
Andreas.
On Tue, 2009-05-12 at 21:49 +0200, Andreas Schwab wrote:
Laurent GUERBY laurent@guerby.net writes:
So 0.15.3 configure does not set $with_ppl variable at all.
Sure it does. Look at the argument parsing loop.
I added a dump and $with_ppl is indeed set correctly but $ppl_prefix (which is used for -I if I follow correctly) is empty:
echo "$as_me:$LINENO: checking for Parma Polyhedral Library (PPL)" >&5 echo $ECHO_N "checking for Parma Polyhedral Library (PPL)... $ECHO_C" >&6 echo WITH_PPL "$with_ppl" > zconf echo PPL_PREFIX "$ppl_prefix" >> zconf if test "x$with_ppl" != "x" -a "x$with_ppl" != "xno"; then
if test "x$with_polylib_prefix" != "x" -o "x$with_polylib_exec_prefix" != "x" -o "x$with_polylib_builddir" != "x"; then { { echo "$as_me:$LINENO: error: --with-polylib and --with-ppl are mutually exclusive" >&5 echo "$as_me: error: --with-polylib and --with-ppl are mutually exclusive" >&2;} { (exit 1); exit 1; }; } fi
if test "x$with_ppl" != "xyes" ; then echo "$as_me:$LINENO: result: installed in $ppl_prefix" >&5 echo "${ECHO_T}installed in $ppl_prefix" >&6 CPPFLAGS="-I$ppl_prefix/include $CPPFLAGS" ... $ cat zconf WITH_PPL /n/17/guerby/install-ppl2/ppl-0.10.2 PPL_PREFIX $
Do you know what part of configure is supposed to set $ppl_prefix?
In the 0.15 configure the code was using $with_prefix directly:
<< echo "$as_me:$LINENO: checking for Parma Polyhedral Library (PPL)" >&5 echo $ECHO_N "checking for Parma Polyhedral Library (PPL)... $ECHO_C" >&6; } if test "x$with_ppl" != "x"; then
if test "x$with_polylib_prefix" != "x" -o "x$with_polylib_exec_prefix" != "x" -o "x$with_polylib_builddir" != "x"; then { { echo "$as_me:$LINENO: error: --with-polylib and --with-ppl are mutually exclusive" >&5 echo "$as_me: error: --with-polylib and --with-ppl are mutually exclusive" >&2;} { (exit 1); exit 1; }; } fi
{ echo "$as_me:$LINENO: result: installed in $with_ppl" >&5 echo "${ECHO_T}installed in $with_ppl" >&6; } POLYHEDRAL_BACKEND=ppl CPPFLAGS="-I$with_ppl/include -DCLOOG_PPL_BACKEND $CPPFLAGS"
Or may be just replace $ppl_prefix in 0.15.3 configure.in and configure?
Thanks for your help,
Laurent
Laurent GUERBY schrieb am Dienstag 12 Mai 2009 um 22:03:
On Tue, 2009-05-12 at 21:49 +0200, Andreas Schwab wrote:
Laurent GUERBY laurent@guerby.net writes:
So 0.15.3 configure does not set $with_ppl variable at all.
Sure it does. Look at the argument parsing loop.
I added a dump and $with_ppl is indeed set correctly but $ppl_prefix (which is used for -I if I follow correctly) is empty:
I just had the same problem while installing under an RHEL user account. I'm not a autotools guy (cmake ftw.), but by looking at the configure.ac of ppl, I figured that
AC_ARG_WITH(ppl, [AS_HELP_STRING([--with-ppl=DIR], [Prefix of Parma Polyhedral Library installation])]) has to be
AC_ARG_WITH(ppl, [AS_HELP_STRING([--with-ppl=DIR], [Prefix of Parma Polyhedral Library installation])], ppl_prefix=$with_ppl)
which made it work for, after running ./autogen.sh.
Best, -- Maik
On Tue, 2009-05-12 at 18:46 +0200, Roberto Bagnara wrote:
Janis Johnson wrote:
On Mon, 2009-05-11 at 13:07 -0700, Ian Lance Taylor wrote:
Another Graphite build issue: it appears that I must not use --disable-shared when I configure PPL. If I do use --disable-shared, I get this:
/home/iant/gnu/ppl-0.10.2-install/lib/libppl_c.a(ppl_c_implementation_common.o): In function `finalize': /home/iant/gnu/ppl-0.10.2/interfaces/C/../../src/ppl.hh:1842: undefined reference to `operator delete(void*)'
followed by thousands of similar errors. This is unfortunate, as it means that I must manually set LD_LIBRARY_PATH to the directory where the PPL library is installed. This also makes it harder for anybody else to run the compiler that I build. This needs to be fixed.
I get around this by setting LDFLAGS for the ppl configure:
I was wrong, I use these flags for other reasons.
LDFLAGS="-static" \ ./configure \ --prefix=$PREFIX \ --build=powerpc-linux \ --with-gnu-ld \ --with-libgmp-prefix=$PREFIX \ --with-libgmpxx-prefix=$PREFIX \ --disable-shared
I am not sure I understand: we trust that Libtool, which provides us with the --disable-shared option, will do the right thing. And it seems it does here: the static library is built and passes its checks.
The --disable-shared option worked as expected. What I had problems with was finding my static versions of libgmp and libgmpxx; configure kept finding the default shared versions, which were too old, until I added LDFLAGS="-static" before ./configure, and passed LDFLAGS="-all-static" to make and make check. I had assumed that by specifying their locations, configure and make would be able to use those particular libraries.
Perhaps you want something different from what --disable-shared promises, that is, not to build any shared libraries?
I copy libstdc++.a into the directory with the other GCC host libraries (gmp/mpfr/ppl/cloog/mpc).
Building these libraries is indeed quite painful.
Any suggestion about how to improve the PPL is welcome. This, of course, applies also to the build machinery. All the best,
One small change would be to use --with-gmp as a configure option. It's not clear whether it's necessary to use both --with-libgmp-prefix and --with-libgmpxx-prefix. Other packages that GCC needs (MPFR, CLoog, MPC) use --with-gmp for the GMP package.
Janis
participants (6)
-
Andreas Schwab -
Ian Lance Taylor -
Janis Johnson -
Laurent GUERBY -
Maik Beckmann -
Roberto Bagnara