Undefined PPL references attempting to build cloog-ppl
Hello,
I'm replying to this thread I found in the archive: http://www.cs.unipr.it/pipermail/ppl-devel/2009-August/015195.html since I was hit by the same error while trying to build PPL under Solaris 10/Sparc with gcc 4.5.1. It does not seem to be solved because in Version 0.11 of PPL the same error occurs nor could I find a solution, so I had to look myself. It turned out the the problem is related to sed. With Solaris' sed it does not work, but with GNU sed it works. So it does not seem to be related to autoreconf, perl, m4 or awk. Unfortunately I was not able to find out which sed command behaves differently. Maybe it would be a good idea to search for and use GNU sed in configure.
Regards,
Peter
ps: I'm not subscribed, so if you want me to do anything for this issue (like testing or something) please reply to me directly
Peter Kruse wrote:
Hello,
Hello.
I'm replying to this thread I found in the archive: http://www.cs.unipr.it/pipermail/ppl-devel/2009-August/015195.html since I was hit by the same error while trying to build PPL under Solaris 10/Sparc with gcc 4.5.1. It does not seem to be solved because in Version 0.11 of PPL the same error occurs nor could I find a solution, so I had to look myself. It turned out the the problem is related to sed. With Solaris' sed it does not work, but with GNU sed it works.
Your diagnosis is correct. We came to the same conclusion here:
https://www.cs.unipr.it/mantis/view.php?id=103
and added a README.solaris file recommending that GNU sed should be used in all cases.
Unfortunately, the sentence in README.solaris was a little ambiguous in mentioning the Java language interface, while the problem is affecting all interfaces. Hence, I just committed in a less ambiguous sentence:
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=7f6f8d36f5f92...
Thanks anyway for reporting.
Regards, Enea Zaffanella.
So it does not seem to be related to autoreconf, perl, m4 or awk. Unfortunately I was not able to find out which sed command behaves differently. Maybe it would be a good idea to search for and use GNU sed in configure.
Regards,
Peter
ps: I'm not subscribed, so if you want me to do anything for this issue (like testing or something) please reply to me directly _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
Hello
On Sat, Sep 18, 2010 at 9:58 AM, Enea Zaffanella zaffanella@cs.unipr.it wrote:
Your diagnosis is correct. We came to the same conclusion here:
I couldn't search the bug database because the certifacte is self signed and the firewall of the company I work for blocks those sites unless an exception is added which I haven't requested yet. I guess they are over-paranoid...
and added a README.solaris file recommending that GNU sed should be used in all cases.
may I suggest that configure ends with in error if it can't find a GNU sed? Or search $PATH for a GNU sed and use that? I mean if it's possible to automate the process why not do it?
Regards,
Peter
On 09/18/10 11:29, Peter Kruse wrote:
may I suggest that configure ends with in error if it can't find a GNU sed? Or search $PATH for a GNU sed and use that? I mean if it's possible to automate the process why not do it?
Hi Peter,
do you know a way to automate the process with Autoconf? All the best,
Roberto
Hello Roberto,
On Sat, Sep 18, 2010 at 12:30 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
On 09/18/10 11:29, Peter Kruse wrote:
may I suggest that configure ends with in error if it can't find a GNU sed? Or search $PATH for a GNU sed and use that? I mean if it's possible to automate the process why not do it?
do you know a way to automate the process with Autoconf?
I haven't written a configure.ac yes, but there must be numerous examples out there. But looking at the manual I found you could for one use the macro AC_PROG_SED but that doesn't check for GNU sed, then there is a section on sed at http://www.gnu.org/software/autoconf/manual/autoconf.html#sed where it explains so limitations on the sed pattern you should use. Maybe it would be a better idea to use a sed pattern that does not fail with Solaris' sed. Or use perl.
Peter
On 09/19/10 10:28, Peter Kruse wrote:
But looking at the manual I found you could for one use the macro AC_PROG_SED but that doesn't check for GNU sed, then there is a section on sed at http://www.gnu.org/software/autoconf/manual/autoconf.html#sed where it explains so limitations on the sed pattern you should use. Maybe it would be a better idea to use a sed pattern that does not fail with Solaris' sed.
I agree. Can you please try to come up with revised Posix sed patterns that do not fail with Solaris' sed? We would be glad to apply the patch. All the best,
Roberto
Hi,
On Sun, Sep 19, 2010 at 10:41 AM, Roberto Bagnara bagnara@cs.unipr.it wrote:
I agree. Can you please try to come up with revised Posix sed patterns that do not fail with Solaris' sed? We would be glad to apply the patch.
can you show which pattern is the one in question?
Regards,
Peter
On 09/19/10 12:09, Peter Kruse wrote:
On Sun, Sep 19, 2010 at 10:41 AM, Roberto Bagnarabagnara@cs.unipr.it wrote:
I agree. Can you please try to come up with revised Posix sed patterns that do not fail with Solaris' sed? We would be glad to apply the patch.
can you show which pattern is the one in question?
Unfortunately not.
On 09/19/10 12:09, Peter Kruse wrote:
On Sun, Sep 19, 2010 at 10:41 AM, Roberto Bagnarabagnara@cs.unipr.it wrote:
I agree. Can you please try to come up with revised Posix sed patterns that do not fail with Solaris' sed? We would be glad to apply the patch.
can you show which pattern is the one in question?
Unfortunately not. But you can inspect our patterns and compare them with those that are said to be avoided in the documentation you quoted.
Hello,
On Sun, Sep 19, 2010 at 12:52 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
On 09/19/10 12:09, Peter Kruse wrote:
On Sun, Sep 19, 2010 at 10:41 AM, Roberto Bagnarabagnara@cs.unipr.it wrote:
I agree. Can you please try to come up with revised Posix sed patterns that do not fail with Solaris' sed? We would be glad to apply the patch.
can you show which pattern is the one in question?
Unfortunately not. But you can inspect our patterns and compare them with those that are said to be avoided in the documentation you quoted.
ok, I found it. In line 14514 of configure you have this:
required_instantiations=`echo "${enableval}" | sed -e 's/[ ][ ]*/ /g' -e 's/[ ]*([@<>,])[ ]*/\1/g' -e 's/>>/> >/g' -e 's/^[ ]//g' -e 's/[ ]$//g'`
where enableval looks like:
' Polyhedron @ Grid @ Rational_Box @ BD_Shape<int8_t> @ BD_Shape<mpz_class> @ BD_Shape<mpq_class> @ Octagonal_Shape<mpz_class> @ Octagonal_Shape<mpq_class> @ Constraints_Product<C_Polyhedron, Grid> @ Pointset_Powerset<C_Polyhedron> @ Pointset_Powerset<NNC_Polyhedron>'
It is the pattern 's/[ ]*([@<>,])[ ]*/\1/g'. Comparing solaris and gnu:
Solaris:
echo '> @ B' | sed -e 's/[ ]*([@<>,])[ ]*/\1/g'
@ B
GNU:
echo '> @ B' | gsed -e 's/[ ]*([@<>,])[ ]*/\1/g'
@B
notice the extra space. Now the question, it seems the whole point of this step is to "Avoid extra blank". Are there blanks you want to keep, or can you not just remove every blank?
Cheers,
Peter
Il 24/09/2010 11:47, Peter Kruse ha scritto:
echo '> @ B' | sed -e 's/[ ]*([@<>,])[ ]*/\1/g'
@ B
Uh? Badly broken sed?
The first time it should replace "> " with ">" and the second time it should replace "@ " with "@".
I don't see any other sensible behaviour, however in this commit has been introduced a lightly different approach that maybe work around that bug, can you try it?
commit b68f8ff2bde57db64ec4439d8a2592da351742e4 Author: Roberto Bagnara bagnara@cs.unipr.it Date: Thu Aug 5 09:08:44 2010 +0200
Avoid using overlapping regular expressions.
Hi,
On Fri, Sep 24, 2010 at 1:38 PM, Abramo Bagnara abramo.bagnara@gmail.com wrote:
I don't see any other sensible behaviour, however in this commit has been introduced a lightly different approach that maybe work around that bug, can you try it?
with this patch both seds produce the same result. So I can compile Version 0.10 now.
Peter
Peter Kruse wrote:
Hello,
On Sun, Sep 19, 2010 at 12:52 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
On 09/19/10 12:09, Peter Kruse wrote:
On Sun, Sep 19, 2010 at 10:41 AM, Roberto Bagnarabagnara@cs.unipr.it wrote:
I agree. Can you please try to come up with revised Posix sed patterns that do not fail with Solaris' sed? We would be glad to apply the patch.
can you show which pattern is the one in question?
Unfortunately not. But you can inspect our patterns and compare them with those that are said to be avoided in the documentation you quoted.
ok, I found it. In line 14514 of configure you have this:
required_instantiations=`echo "${enableval}" | sed -e 's/[ ][ ]*/ /g' -e 's/[ ]*([@<>,])[ ]*/\1/g' -e 's/>>/> >/g' -e 's/^[ ]//g' -e 's/[ ]$//g'`
where enableval looks like:
' Polyhedron @ Grid @ Rational_Box @ BD_Shape<int8_t> @ BD_Shape<mpz_class> @ BD_Shape<mpq_class> @ Octagonal_Shape<mpz_class> @ Octagonal_Shape<mpq_class> @ Constraints_Product<C_Polyhedron, Grid> @ Pointset_Powerset<C_Polyhedron> @ Pointset_Powerset<NNC_Polyhedron>'
It is the pattern 's/[ ]*([@<>,])[ ]*/\1/g'. Comparing solaris and gnu:
Solaris:
echo '> @ B' | sed -e 's/[ ]*([@<>,])[ ]*/\1/g'
@ B
GNU:
echo '> @ B' | gsed -e 's/[ ]*([@<>,])[ ]*/\1/g'
@B
notice the extra space. Now the question, it seems the whole point of this step is to "Avoid extra blank". Are there blanks you want to keep, or can you not just remove every blank?
We do not want to remove every blank, because the enable_val string could contain something like
Pointset_Powerset<BD_Shape<mpq_class> >
and we want to keep the blank separating the two closing angle brackets.
Cheers, Enea.
Cheers,
Peter _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
participants (4)
-
Abramo Bagnara -
Enea Zaffanella -
Peter Kruse -
Roberto Bagnara