Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

2023-11-09 Thread Benjamin Lorenz 

Dear David,

On 08/11/2023 23.09, David Bremner wrote:

David Bremner  writes:
I didn't have a chance to investigate so far, but I am seeing a test
failure with Polymake 4.11 building with Perl 5.36. I will try to build
with 5.38 and report a proper build log.

*** Failed tests ***

/<>/apps/polytope/rules/slack_ideal.rules:29: testcase 1
expected: regular return
  got: EXCEPTION: no more rules available to compute 'GENERATORS


That looks like the same as #1052830.
I was able to reproduce this and it comes from a changed return type of 
the Singular saturation command. The attached patch should fix this and 
work with both old and new Singular versions.


Best,
Benjamin
commit 4ce0549f510d246c8f69c85c509fc2d13d882442
Author: Benjamin Lorenz 
Date:   Thu Nov 9 11:15:06 2023 +0100

singular: support new return types for saturation command

This was changed from (ideal, exponent) to just the ideal in singular 4-3-2p5.
To allow older versions we keep using sat but support both return types
instead of switching to the new sat_with_exp.

diff --git a/bundled/singular/apps/ideal/src/singularIdeal.cc b/bundled/singular/apps/ideal/src/singularIdeal.cc
index 4cbc00a6f4..bdade5c29d 100644
--- a/bundled/singular/apps/ideal/src/singularIdeal.cc
+++ b/bundled/singular/apps/ideal/src/singularIdeal.cc
@@ -236,22 +236,24 @@ public:
   arg.next->data=(void *)idCopy(J);
   // call primdecSY
   BOOLEAN res=iiMake_proc(sathdl, nullptr ,);
-  if(!res && (iiRETURNEXPR.Typ() == LIST_CMD)){
- lists L = (lists)iiRETURNEXPR.Data();
- SingularIdeal_wrap* result;
- if(L->m[0].Typ() == IDEAL_CMD){
-result = new SingularIdeal_impl((::ideal) (L->m[0].Data()),singRing);
- } else {
-throw std::runtime_error("Something went wrong for the primary decomposition");
+  if(!res) {
+ ::ideal iddata = nullptr;
+ if (iiRETURNEXPR.Typ() == LIST_CMD) {
+lists L = (lists)iiRETURNEXPR.Data();
+if(L->m[0].Typ() == IDEAL_CMD)
+   iddata = (::ideal) L->m[0].Data();
+ } else if (iiRETURNEXPR.Typ() == IDEAL_CMD) {
+iddata = (::ideal) iiRETURNEXPR.Data();
+ }
+ if (iddata != nullptr) {
+SingularIdeal_wrap* result = new SingularIdeal_impl(iddata, singRing);
+iiRETURNEXPR.CleanUp();
+iiRETURNEXPR.Init();
+return result;
  }
- iiRETURNEXPR.CleanUp();
- iiRETURNEXPR.Init();
- return result;
-  } else {
- iiRETURNEXPR.Init();
- throw std::runtime_error("Something went wrong for the saturation");
   }
-
+  iiRETURNEXPR.Init();
+  throw std::runtime_error("saturation: unable to parse ideal from return value");
}
 
Array primary_decomposition() const

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

2023-11-08 Thread David Bremner 
David Bremner  writes:

> Benjamin Lorenz  writes:
> Dear Benjamin;
>
> Thanks for letting me know. I will try to update the Debian package
> within a week or so.
>
> David

I didn't have a chance to investigate so far, but I am seeing a test
failure with Polymake 4.11 building with Perl 5.36. I will try to build
with 5.38 and report a proper build log.

*** Failed tests ***

/<>/apps/polytope/rules/slack_ideal.rules:29: testcase 1
expected: regular return
 got: EXCEPTION: no more rules available to compute 'GENERATORS

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

2023-11-08 Thread David Bremner 
Benjamin Lorenz  writes:

> we have now managed to work around the perl changes and released 
> polymake version 4.11 which restores compatibility with perl 5.38.
>
> Among various other adjustments the workaround relies on an 
> auto-generated perl source file that was is now copied into the polymake 
> source.
> This means it will almost surely need more changes for future perl 
> releases and we cannot really say if this approach will keep working.
> Right now polymake does work with the latest perl blead and we will be 
> on the lookout for new issues.

Dear Benjamin;

Thanks for letting me know. I will try to update the Debian package
within a week or so.

David

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

2023-11-08 Thread Benjamin Lorenz 

Dear David,

we have now managed to work around the perl changes and released 
polymake version 4.11 which restores compatibility with perl 5.38.


Among various other adjustments the workaround relies on an 
auto-generated perl source file that was is now copied into the polymake 
source.
This means it will almost surely need more changes for future perl 
releases and we cannot really say if this approach will keep working.
Right now polymake does work with the latest perl blead and we will be 
on the lookout for new issues.


Best
Benjamin

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

2023-07-30 Thread David Bremner 
Niko Tyni  writes:

>
> There's an upstream discussion at
> https://forum.polymake.org/viewtopic.php?t=1914 which does not look
> promising. Apparently polymake starting with 4.9 explicitly bails out
> for Perl >= 5.37 because Perl internal symbols that polymake was relying
> on are now hidden.
>
> Filing this to at least track the issue. David, any thoughts on this?

I don't have any real technical insight here (this is the first I'm
hearing of the issue).

Certainly if anybody understands the issues involved on the polymake
side, Ewgenij does. Also, pretty clearly we're not going to keep an
extra Perl stack around. It sounds like at least a short term removal
of polymake from Debian testing is likely at this point.

I've CC'ed my main contact on the project just in case Benjamin has
anything to add to the discussion.

David

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

2023-07-29 Thread Niko Tyni 
Source: polymake
Version: 4.6-5
Severity: important
Tags: ftbfs sid trixie upstream
User: debian-p...@lists.debian.org
Usertags: perl-5.38-transition

This package fails to build from source with Perl 5.38 (currently in
experimental.)

  
http://perl.debian.net/rebuild-logs/perl-5.38/polymake_4.6-5/polymake_4.6-5+b3_amd64-2023-06-29T01:58:06Z.build

   FAILED: 
/<>/build/Opt/lib/perlx/5.38.0/x86_64-linux-gnu-thread-multi/RefHash.o
 
 g++ -c -o 
/<>/build/Opt/lib/perlx/5.38.0/x86_64-linux-gnu-thread-multi/RefHash.o
 -MMD -MT 
/<>/build/Opt/lib/perlx/5.38.0/x86_64-linux-gnu-thread-multi/RefHash.o
 -MF 
/<>/build/Opt/lib/perlx/5.38.0/x86_64-linux-gnu-thread-multi/RefHash.o.d
 -fPIC -pipe -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing 
-fopenmp -Wshadow -Wlogical-op -Wconversion -Wzero-as-null-pointer-constant 
-Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow 
-Wno-array-bounds -Wno-maybe-uninitialized -Wno-free-nonheap-object 
-DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2 
-I/usr/lib/x86_64-linux-gnu/perl/5.38/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN 
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64  -DPerlVersion=5380 -Wno-nonnull  
-I/<>/include/core-wrappers -I/<>/include/core 
/<>/build/perlx/5.38.0/x86_64-linux-gnu-thread-multi/RefHash.cc && 
: 'COMPILER_USED=12.3.0'
   /<>/lib/core/src/perl/RefHash.xxs: In function ‘OP* 
pm::perl::glue::{anonymous}::check_pushhv(PerlInterpreter*, OP*)’:
   /<>/lib/core/src/perl/RefHash.xxs:737:11: error: ‘Perl_ck_fun’ 
was not declared in this scope; did you mean ‘Perl_cx_dup’?

There's an upstream discussion at
https://forum.polymake.org/viewtopic.php?t=1914 which does not look
promising. Apparently polymake starting with 4.9 explicitly bails out
for Perl >= 5.37 because Perl internal symbols that polymake was relying
on are now hidden.

Filing this to at least track the issue. David, any thoughts on this?
-- 
Niko Tyni   nt...@debian.org