Description of problem: Package polymake fails to build from source with Perl 5.38 in Fedora Rawhide. ************* *** ERROR *** ************* polymake does not work with perl 5.37 or newer; your perl interpreter says it is 5.038000. Access to various functions that are required to hook into the perl interpreter has been restricted to the perl core, which unfortunately breaks polymake. If you already have another (older) perl interpreter somewhere else, you can specify its location on the command line: ./configure PERL=/path/to/my/new/perl [other options ...] You can install a custom perl version in your home directory using perlbrew (https://perlbrew.pl). Make sure to append '-Duseshrplib' to the install command if you want to use libpolymake (e.g. for the jupyter interface) and to install all required perl modules which are listed after running configure again with the new perl. Version-Release number of selected component (if applicable): 4.10-2.fc39 https://koji.fedoraproject.org/koji/taskinfo?taskID=103257961 Reproducible: Always Steps to Reproduce: koji build --scratch f39 polymake-4.10-1.fc39.src.rpm
Oooooooooooh noooooooooo! I don't know what to do about this, other than retire polymake, which will do serious damage to our mathematical tools stack. It will impact Macaulay2, sagemath, gap-pkg-polymaking, and everything that sits on top of gap-pkg-polymaking. If anybody has a bright idea, I'm all ears.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
I have a partial patch to address this problem at https://jjames.fedorapeople.org/polymake-perl-5.38.patch. It fully fixes or works around the issues caused by hiding symbols in perl 5.38.0. That is, compilation and linking succeeds, and a binary RPM is generated. The binary can even do simple things, such as run "polymake --reconfigure". However, something is wrong with either reading or processing rules files. If I run polymake in debug mode (with the -d flag), I can see the various rules files being processed. When it is time to solve a problem, however, the viable rules search procedure turns up almost nothing. There is usually no path at all from source to sink in the very sparse graph that is generated. On the rare occasions when there is a path, it doesn't produce the correct answer. I have not yet figured out whether the problem stems from reading the rules files, or from the valid rules search going awry. I do not have much in the way of perl skills, so I would really appreciate any help those with such skills can provide. Upstream is not interested in pursuing this path. They are focused on rewriting polymake in Julia, which is exactly what they should be doing. It would be nice if we could keep perl-based polymake functional until they produce something, though.
FEDORA-2023-52bc97dfc5 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-52bc97dfc5
FEDORA-2023-52bc97dfc5 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-52bc97dfc5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-52bc97dfc5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-52bc97dfc5 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.