Polybori needs to be built. In Fedora 16, essentially, this is required to build with current cudd-devel
polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h --- polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h.orig 2012-04-24 23:17:47.328677842 -0300 +++ polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h 2012-04-24 23:17:53.406678079 -0300 @@ -54,8 +54,6 @@ inline const char* error_text(PBORI_PREF return("Invalid argument."); case CUDD_INTERNAL_ERROR: return("Internal error."); - case CUDD_TIMEOUT_EXPIRED: - return("Timed out."); case CUDD_NO_ERROR: return("No error. (Should not reach here!)"); }
too bad cudd.h version identifier is only a string
#define CUDD_VERSION "2.4.2"
so, probably need to write a check in
polybori-0.8.1/SConstruct
It is also required a patch similar to this one to be able to build sagemath with it:
http://svn.mandriva.com/viewvc/packages/cooker/polybori/current/SPECS/polybo...
[...] I am still too noob with fedora, so, I could not finish the build, because, while I know how to git clone a fedora package, do not know how to fetch sources. For example, I see easily how to clone http://pkgs.fedoraproject.org/gitweb/?p=polybori.git
but failed to finish build (did download upstream tarball) due to missing + tar xJf /home/pcpa/rpmbuild/SOURCES/polybori-logos.tar.xz -C /home/pcpa/rpmbuild/BUILDROOT/polybori-0.8.1-2.fc16.x86_64/usr/share/icons/hicolor tar (child): /home/pcpa/rpmbuild/SOURCES/polybori-logos.tar.xz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now
and my guess to what to do failed also :-) Need to read more wiki pages and check fedpkg options for a readonly checkout, and if it can also be used to fetch sources.
$ fedpkg clone polybori Cloning into 'polybori'... The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)' can't be established. RSA key fingerprint is fe:2e:6a:86:f3:41:e7:03:95:ea:9c:7f:75:9c:ce:9d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4' (RSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly Could not execute clone: Command '['git', 'clone', 'ssh://pcpa@pkgs.fedoraproject.org/polybori']' returned non-zero exit status 128
but as stated above, it would still fail to build sagemath anyway:
Traceback (most recent call last): File "./setup.py", line 18, in <module> from module_list import ext_modules File "/home/pcpa/rpmbuild/BUILD/sage-4.8/spkg/build/sage-4.8/module_list.py", line 80, in <module> for line in open(SAGE_LOCAL + "/share/polybori/flags.conf"): IOError: [Errno 2] No such file or directory: '/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/share/polybori/flags.conf'
[...] Just so that it should be easy to reproduce what I did tonight in a quick check of "how deep the water is", and initial adaptation of my Mandriva sagemath spec, I will attach the spec and patches.
So far, mpir is not packaged in Mandriva, and besides sagemath, I also patched Macaulay2 to not hardcode mpir dependency also, and use gmp5.
The patch to use unpatched ntl should have a nasty side effect in the notebook because it will miss the error message, if in the terminal, it will print the error message to stderr anyway before calling abort. But really, it should have been sagemath to convince upstream NTL for the need of a more complete api.
Thanks, Paulo
and my guess to what to do failed also :-) Need to read more wiki
Learned about -a or --anonymous, but I used the sequence: CONFFILE=%{buildroot}%{_includedir}/polybori/flags.conf perl -pi -e 's|%{buildroot}||g;' %{buildroot}%{_includedir}/polybori/flags.conf
that is, also moved it to /usr/include/polybori/flags.conf, otherwise it would require masking who owns the file; in Mandriva I did a different package approach, with ipbori in the main polybori package. Only issue with putting it in /usr/include is that it then needs an extra patch to sagemath's module_list.py:
... polybori_extra_compile_args = [] -for line in open(SAGE_LOCAL + "/share/polybori/flags.conf"): +for line in open(SAGE_INC + "polybori/flags.conf"): if not line.startswith("CPPDEFINES"): ...
Now, with polybori-devel installed, after some extra patches the failure is:
... gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include -Ic_lib/include -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/devel/sage/sage/ext -I/usr/include/python2.7 -c sage/graphs/cliquer.c -o build/temp.linux-x86_64-2.7/sage/graphs/cliquer.o -w sage/graphs/cliquer.c:235:27: fatal error: cliquer/graph.h: No such file or directory compilation terminated. error: command 'gcc' failed with exit status 1 ...
I will later (probably tomorrow) use the srpm at http://jjames.fedorapeople.org/cliquer/ but either way, the package I use in Mandriva is http://svn.mandriva.com/viewvc/packages/cooker/cliquer/
Thanks and sorry for replying to myself, Paulo
2012/4/24 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
that is, also moved it to /usr/include/polybori/flags.conf, otherwise it would require masking who owns the file; in Mandriva I did a different package approach, with ipbori in the main polybori package. Only issue with putting it in /usr/include is that it then needs an extra patch to sagemath's module_list.py:
I don't see a problem with adding it as /usr/share/polybori/flags.conf. We should be able to make that work.
I will later (probably tomorrow) use the srpm at http://jjames.fedorapeople.org/cliquer/ but either way, the package I use in Mandriva is http://svn.mandriva.com/viewvc/packages/cooker/cliquer/
Hmmm, I threw that package together some time ago and haven't touched it since. I hope it still works!
Thanks and sorry for replying to myself,
Heh. Sometimes that's the best way to have an intelligent conversation. :-)
2012/4/24 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
Polybori needs to be built. In Fedora 16, essentially, this is required to build with current cudd-devel
polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h --- polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h.orig 2012-04-24 23:17:47.328677842 -0300 +++ polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h 2012-04-24 23:17:53.406678079 -0300 @@ -54,8 +54,6 @@ inline const char* error_text(PBORI_PREF return("Invalid argument."); case CUDD_INTERNAL_ERROR: return("Internal error.");
- case CUDD_TIMEOUT_EXPIRED:
- return("Timed out.");
case CUDD_NO_ERROR: return("No error. (Should not reach here!)"); }
I don't understand. What problem does this solve?
Also, note that up through Fedora 16, we had a package named python-polybori, with various subpackages. A few months ago, I reorganized the packages to produce a package named polybori and various subpackages (including a python-polybori subpackage). This is available in Fedora 17 (to be released in about a month) and Fedora Rawhide. I will probably not backport that reorganization to Fedora 16, as it would involve making some changes that violate the Package Update Policy; see https://fedoraproject.org/wiki/Updates_Policy.
Bottom line: Fedora 16 has polybori 0.7.2 and cudd 2.4.2, and will probably stay that way. Fedora 17 and above currently have polybori 0.8.1 and cudd 2.5.0. Any changes we need to make should be done there.
It is also required a patch similar to this one to be able to build sagemath with it:
http://svn.mandriva.com/viewvc/packages/cooker/polybori/current/SPECS/polybo...
[...]
Okay, I can add that easily. I'm going to wait until I understand why you wanted the other change above, though.
Also, I haven't yet built polybori with NTL support. Is that going to be necessary for Sage?
I am still too noob with fedora, so, I could not finish the build, because, while I know how to git clone a fedora package, do not know how to fetch sources.
Use "fedpkg sources", or you can even run "fedpkg srpm" to build the source RPM.
$ fedpkg clone polybori Cloning into 'polybori'... The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)' can't be established. RSA key fingerprint is fe:2e:6a:86:f3:41:e7:03:95:ea:9c:7f:75:9c:ce:9d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4' (RSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly Could not execute clone: Command '['git', 'clone', 'ssh://pcpa@pkgs.fedoraproject.org/polybori']' returned non-zero exit status 128
I believe this is because you are not yet a packager. Once you are sponsored, this problem should go away. If I'm wrong about that, hopefully someone else reading this will correct me.
The patch to use unpatched ntl should have a nasty side effect in the notebook because it will miss the error message, if in the terminal, it will print the error message to stderr anyway before calling abort. But really, it should have been sagemath to convince upstream NTL for the need of a more complete api.
What patch would NTL need to solve this problem?
Em 25 de abril de 2012 17:35, Jerry James loganjerry@gmail.com escreveu:
2012/4/24 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
Polybori needs to be built. In Fedora 16, essentially, this is required to build with current cudd-devel
polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h --- polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h.orig 2012-04-24 23:17:47.328677842 -0300 +++ polybori-0.8.1/libpolybori/include/polybori/ring/CCuddInterface.h 2012-04-24 23:17:53.406678079 -0300 @@ -54,8 +54,6 @@ inline const char* error_text(PBORI_PREF return("Invalid argument."); case CUDD_INTERNAL_ERROR: return("Internal error.");
- case CUDD_TIMEOUT_EXPIRED:
- return("Timed out.");
case CUDD_NO_ERROR: return("No error. (Should not reach here!)"); }
I don't understand. What problem does this solve?
polybori does not build because CUDD_TIMEOUT_EXPIRED is not defined in cudd.h (it should be in an enum).
Also, note that up through Fedora 16, we had a package named python-polybori, with various subpackages. A few months ago, I reorganized the packages to produce a package named polybori and various subpackages (including a python-polybori subpackage). This is available in Fedora 17 (to be released in about a month) and Fedora Rawhide. I will probably not backport that reorganization to Fedora 16, as it would involve making some changes that violate the Package Update Policy; see https://fedoraproject.org/wiki/Updates_Policy.
Ok. I am currently running fedora 16 in my home computer, but should update to use rawhide at some point.
Bottom line: Fedora 16 has polybori 0.7.2 and cudd 2.4.2, and will
I found only python-polybori{,-devel} with "yum search polybori", so, I built polybori from http://pkgs.fedoraproject.org/gitweb/?p=polybori.git but used the available cudd-devel.
probably stay that way. Fedora 17 and above currently have polybori 0.8.1 and cudd 2.5.0. Any changes we need to make should be done there.
It is also required a patch similar to this one to be able to build sagemath with it:
http://svn.mandriva.com/viewvc/packages/cooker/polybori/current/SPECS/polybo...
[...]
Okay, I can add that easily. I'm going to wait until I understand why you wanted the other change above, though.
Also, I haven't yet built polybori with NTL support. Is that going to be necessary for Sage?
Not 100% sure, but several other issues are likely to happen, and "sage -testall" will show the problems, while others should also appear until actually getting everything built. But at first I think it is required. I remember polybori being one of the major source of problems in my first sagemath packages.
I am still too noob with fedora, so, I could not finish the build, because, while I know how to git clone a fedora package, do not know how to fetch sources.
Use "fedpkg sources", or you can even run "fedpkg srpm" to build the source RPM.
$ fedpkg clone polybori Cloning into 'polybori'... The authenticity of host 'pkgs.fedoraproject.org (209.132.181.4)' can't be established. RSA key fingerprint is fe:2e:6a:86:f3:41:e7:03:95:ea:9c:7f:75:9c:ce:9d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'pkgs.fedoraproject.org,209.132.181.4' (RSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly Could not execute clone: Command '['git', 'clone', 'ssh://pcpa@pkgs.fedoraproject.org/polybori']' returned non-zero exit status 128
I believe this is because you are not yet a packager. Once you are sponsored, this problem should go away. If I'm wrong about that, hopefully someone else reading this will correct me.
The patch to use unpatched ntl should have a nasty side effect in the notebook because it will miss the error message, if in the terminal, it will print the error message to stderr anyway before calling abort. But really, it should have been sagemath to convince upstream NTL for the need of a more complete api.
What patch would NTL need to solve this problem?
It is basically to allow sagemath cython code to have access to the error string NTL my print.
The patch I have been using is http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ntl/current/SOURC...
You may also want to package and build ntl with gf2x support.
For the NTL patch probably we should contact upstream to attempt to have it (not exactly as is in the above link), or an alternate patch with the same feature added.
-- Jerry James http://www.jamezone.org/
Paulo
2012/4/25 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
Em 25 de abril de 2012 17:35, Jerry James loganjerry@gmail.com escreveu:
[snip]
polybori does not build because CUDD_TIMEOUT_EXPIRED is not defined in cudd.h (it should be in an enum).
Sorry to be slow. So the current polybori effectively requires cudd 2.5.0, but Fedora 16 has cudd 2.4.2. Got it. This patch isn't necessary for Fedora 17 or Rawhide, which have cudd 2.5.0, so I will probably do nothing about this problem. Sorry.
Ok. I am currently running fedora 16 in my home computer, but should update to use rawhide at some point.
I run Rawhide inside virtual machines, since it can get a bit rough at times. But Fedora 17 Beta just came out. Perhaps it would be worth updating to that.
I found only python-polybori{,-devel} with "yum search polybori", so, I built polybori from http://pkgs.fedoraproject.org/gitweb/?p=polybori.git but used the available cudd-devel.
Right. The situation is not great on Fedora 16, but is too painful to change now. Let's focus on making the Fedora 17 versions be all that we need.
Also, I haven't yet built polybori with NTL support. Is that going to be necessary for Sage?
Not 100% sure, but several other issues are likely to happen, and "sage -testall" will show the problems, while others should also appear until actually getting everything built. But at first I think it is required. I remember polybori being one of the major source of problems in my first sagemath packages.
Okay, I'll see what needs to happen to build polybori with NTL support, and add the patch to install flags.conf.
What patch would NTL need to solve this problem?
It is basically to allow sagemath cython code to have access to the error string NTL my print.
The patch I have been using is http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ntl/current/SOURC...
You may also want to package and build ntl with gf2x support.
For the NTL patch probably we should contact upstream to attempt to have it (not exactly as is in the above link), or an alternate patch with the same feature added.
I am adding the NTL package maintainer to CC to make him aware of this issue. Regards,
Em 25 de abril de 2012 18:39, Jerry James loganjerry@gmail.com escreveu:
2012/4/25 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
Em 25 de abril de 2012 17:35, Jerry James loganjerry@gmail.com escreveu:
[snip]
polybori does not build because CUDD_TIMEOUT_EXPIRED is not defined in cudd.h (it should be in an enum).
Sorry to be slow. So the current polybori effectively requires cudd 2.5.0, but Fedora 16 has cudd 2.4.2. Got it. This patch isn't necessary for Fedora 17 or Rawhide, which have cudd 2.5.0, so I will probably do nothing about this problem. Sorry.
No problems. I am doing a test build and package adaptation to know ahead of time most issues that will need to be solved.
Ok. I am currently running fedora 16 in my home computer, but should update to use rawhide at some point.
I run Rawhide inside virtual machines, since it can get a bit rough at times. But Fedora 17 Beta just came out. Perhaps it would be worth updating to that.
Well, until last sunday I was running Mandriva cooker at home, so, I am used to things breaking, badly :-)
I found only python-polybori{,-devel} with "yum search polybori", so, I built polybori from http://pkgs.fedoraproject.org/gitweb/?p=polybori.git but used the available cudd-devel.
Right. The situation is not great on Fedora 16, but is too painful to change now. Let's focus on making the Fedora 17 versions be all that we need.
Also, I haven't yet built polybori with NTL support. Is that going to be necessary for Sage?
Not 100% sure, but several other issues are likely to happen, and "sage -testall" will show the problems, while others should also appear until actually getting everything built. But at first I think it is required. I remember polybori being one of the major source of problems in my first sagemath packages.
Okay, I'll see what needs to happen to build polybori with NTL support, and add the patch to install flags.conf.
What patch would NTL need to solve this problem?
It is basically to allow sagemath cython code to have access to the error string NTL my print.
Note accurate :-) What happens is basically that sagemath has a interface to handle signals, etc, and have a place for a static string that should describe an error, and it wants to wrap "NTL print string to stderr and call abort" logic, what makes sense when NTL is a library it is linked to. The sagemath patch also adds an extra context pointer to the callback.
The patch I have been using is http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ntl/current/SOURC...
You may also want to package and build ntl with gf2x support.
For the NTL patch probably we should contact upstream to attempt to have it (not exactly as is in the above link), or an alternate patch with the same feature added.
I am adding the NTL package maintainer to CC to make him aware of this issue. Regards,
Ok. I just got home, built your cliquer package, but no luck:
... gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include -Ic_lib/include -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/devel/sage/sage/ext -I/usr/include/python2.7 -c sage/graphs/cliquer.c -o build/temp.linux-x86_64-2.7/sage/graphs/cliquer.o -w In file included from /usr/include/cliquer/graph.h:5:0, from sage/graphs/cliquer.c:235: /usr/include/cliquer/set.h:16:18: fatal error: misc.h: No such file or directory compilation terminated. error: command 'gcc' failed with exit status 1 ...
cliquer probably would need this patch, otherwise unsure how to handle it:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/cliquer/current/S... and there is another header file in the SOURCES dir.
I also packaged cliquer 1.2 and not updated it, and 1.2 happens to be the one used at least by sagemath 4.8.
This is another case we should push for upstream adding support to the desired interface, not necessarily verbatim patch and adding new sage_xyz symbols.
-- Jerry James http://www.jamezone.org/
Paulo
[...]
cliquer probably would need this patch, otherwise unsure how to handle it:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/cliquer/current/S... and there is another header file in the SOURCES dir.
I also packaged cliquer 1.2 and not updated it, and 1.2 happens to be the one used at least by sagemath 4.8.
This is another case we should push for upstream adding support to the desired interface, not necessarily verbatim patch and adding new sage_xyz symbols.
For the sake of checking what is next, I patched your cliquer package, and built this srpm:
http://kenobi.mandriva.com/~pcpa/cliquer-1.21-1.fc16.src.rpm
(not that I did not bump release from yours cliquer srpm)
basically, it installs the new cl.h header, because it appears to be missing from the main tarball, but some source includes it, and installed other headers:
cp -p %{SOURCE9} cliquer.h cliquerconf.h graph.h misc.h reorder.h set.h $RPM_BUILD_ROOT%{_includedir}/cliquer
After installing a few extra packages, ecl, gc-devel, libfplll-devel, etc, the next problem is linbox (needs sage specific patches) and missing lcalc. Note, I feel major problems will be with singular, but that should show itself shortly :-)
I also scp'ed a sample build log, to have an idea of what I have building right now:
http://kenobi.mandriva.com/~pcpa/sagemath.log.gz
Note that at first I want to have it working, then after that redesign the package to split in multiple components, change some paths, etc. And from previous experience, once getting it built, expect very long gdb&valgrind sessions until figuring out what causes several different crashes.
-- Jerry James http://www.jamezone.org/
Thanks, Paulo
Em 25 de abril de 2012 21:37, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com escreveu: [...]
I did a test build with the linbox in fedora, but note that in Mandriva I packaged linbox 1.1.6 and did not upgrade to have it matching sagemath spkg version. So, using linbox 1.2.2 in fedora, I see:
sage/libs/linbox/linbox.cpp: In function 'int __pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_echelonize(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*)': sage/libs/linbox/linbox.cpp:2308:123: error: 'linbox_modn_dense_echelonize' was not declared in this scope sage/libs/linbox/linbox.cpp: In function 'PyObject* __pyx_pf_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_4_poly(PyObject*, PyObject*)': sage/libs/linbox/linbox.cpp:2480:335: error: no matching function for call to 'linbox_modn_dense_minpoly(size_t&, size_t**, size_t*, size_t&, size_t**&, int&)' sage/libs/linbox/linbox.cpp:2480:335: note: candidate is: /usr/include/linbox/linbox-sage.h:65:11: note: template<class Element> Element* linbox_modn_dense_minpoly(Element, Element**, size_t*, size_t, Element*) sage/libs/linbox/linbox.cpp:2527:43: error: 'linbox_modn_dense_delete_array' was not declared in this scope sage/libs/linbox/linbox.cpp: In function 'PyObject* __pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_matrix_matrix_multiply(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*, size_t**, size_t**, size_t, size_t)': sage/libs/linbox/linbox.cpp:2578:187: error: no matching function for call to 'linbox_modn_dense_matrix_matrix_multiply(size_t&, size_t**&, size_t**&, size_t**&, size_t&, size_t&, size_t&, size_t&)' sage/libs/linbox/linbox.cpp:2578:187: note: candidate is: /usr/include/linbox/linbox-sage.h:77:9: note: template<class Element> Element* linbox_modn_dense_matrix_matrix_multiply(Element, Element*, Element*, Element*, size_t, size_t, size_t) sage/libs/linbox/linbox.cpp: In function 'long unsigned int __pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_rank(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*)': sage/libs/linbox/linbox.cpp:2634:117: error: 'linbox_modn_dense_rank' was not declared in this scope sage/libs/linbox/linbox.cpp: In function 'size_t __pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_det(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*, int)': sage/libs/linbox/linbox.cpp:2697:116: error: no matching function for call to 'linbox_modn_dense_det(size_t&, size_t**&, size_t&, size_t&)' sage/libs/linbox/linbox.cpp:2697:116: note: candidate is: /usr/include/linbox/linbox-sage.h:59:9: note: template<class Element> Element linbox_modn_dense_det(Element, Element*, size_t, size_t) sage/libs/linbox/linbox.cpp: In function 'PyObject* __pyx_pf_4sage_4libs_6linbox_6linbox_20Linbox_integer_dense_2_poly(PyObject*, PyObject*)': sage/libs/linbox/linbox.cpp:5127:253: error: invalid initialization of non-const reference of type '__mpz_struct (*&)[1]' from an rvalue of type '__mpz_struct (**)[1]' /usr/include/linbox/linbox-sage.h:108:6: error: in passing argument 1 of 'void linbox_integer_dense_minpoly(__mpz_struct (*&)[1], size_t&, size_t, __mpz_struct (**)[1])' sage/libs/linbox/linbox.cpp:5139:254: error: invalid initialization of non-const reference of type '__mpz_struct (*&)[1]' from an rvalue of type '__mpz_struct (**)[1]' /usr/include/linbox/linbox-sage.h:110:6: error: in passing argument 1 of 'void linbox_integer_dense_charpoly(__mpz_struct (*&)[1], size_t&, size_t, __mpz_struct (**)[1])' sage/libs/linbox/linbox.cpp: In function 'PyObject* __pyx_f_4sage_4libs_6linbox_6linbox_20Linbox_integer_dense_matrix_matrix_multiply(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_integer_dense*, __mpz_struct (**)[1], __mpz_struct (**)[1], size_t, size_t)': sage/libs/linbox/linbox.cpp:5283:173: error: too many arguments to function 'int linbox_integer_dense_matrix_matrix_multiply(__mpz_struct (**)[1], __mpz_struct (**)[1], __mpz_struct (**)[1], size_t, size_t, size_t)' /usr/include/linbox/linbox-sage.h:115:5: note: declared here error: command 'gcc' failed with exit status 1
But hopefully it would not crash as it appears to have a different approach to an issue that causes crashes when built with --enable-sage that is linbox-destructor.patch.
The patch I use in Mandriva for linbox 1.1.6 is
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/linalg-linbox/cur...
Need to check also upcoming sagemath 5.0 sources, but at first testing 4.8 that is the latest release.
Note that at first I want to have it working, then after that redesign the package to split in multiple components, change some paths, etc. And from previous experience, once getting it built, expect very long gdb&valgrind sessions until figuring out what causes several different crashes.
-- Jerry James http://www.jamezone.org/
Thanks, Paulo
Em 25 de abril de 2012 22:24, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com escreveu:
Em 25 de abril de 2012 21:37, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com escreveu: [...]
I did a test build with the linbox in fedora, but note that in Mandriva I packaged linbox 1.1.6 and did not upgrade to have it matching sagemath spkg version. So, using linbox 1.2.2 in fedora, I see:
sage/libs/linbox/linbox.cpp: In function 'int __pyx_f_4sage_4libs_6linbox_6linbox_17Linbox_modn_dense_echelonize(__pyx_obj_4sage_4libs_6linbox_6linbox_Linbox_modn_dense*)': sage/libs/linbox/linbox.cpp:2308:123: error: 'linbox_modn_dense_echelonize' was not declared in this scope
[...]
I think this is the major showstopper for now.
Jerry, do you think it is reasonably to downngrade and use linbox 1.1.6? Patching should be possible, but not much trivial, quick guess would be to use mpz interfaces for the apparently now deprecated or available elsewhere or other interfaces, integer matrix operations.
Sorry for more fedora newbie questions, but how do I query what requires a package? E.g. in Mandriva I can use
urpmq --whatrequires foobar
asking it to know what, if anything requires linbox.
Need to check also upcoming sagemath 5.0 sources, but at first testing 4.8 that is the latest release.
sage 5.0 will also use linbox 1.1.6 from what I understand, or at least should be what is used in alpha builds.
Thanks, Paulo
2012/4/25 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
I think this is the major showstopper for now.
Jerry, do you think it is reasonably to downngrade and use linbox 1.1.6? Patching should be possible, but not much trivial, quick guess would be to use mpz interfaces for the apparently now deprecated or available elsewhere or other interfaces, integer matrix operations.
Linbox was updated from 1.1.6 to 1.1.7 before I became involved with it. Judging by the changelog, though, the problem is that 1.1.6 failed to build due to requiring an old version of givaro and 1.1.7 fixed the build problem: I became involved when the same problem occurred; givaro was updated, and then linbox 1.1.7 failed to build. I contacted upstream about the problem, and they suggested moving to linbox 1.2.1, which did solve it. The move to linbox 1.2.2 was coordinated with another new release of givaro.
In short, moving backwards in linbox versions will require also moving backwards in givaro versions.
Sorry for more fedora newbie questions, but how do I query what requires a package? E.g. in Mandriva I can use
urpmq --whatrequires foobar
asking it to know what, if anything requires linbox.
repoquery --whatrequires foobar
Or, to find the total set of affected packages:
repoquery --whatrequires --recursive foobar
The repoquery command is provided by the yum-utils package.
sage 5.0 will also use linbox 1.1.6 from what I understand, or at least should be what is used in alpha builds.
Hmmm, that puts us in a difficult position. Fedora is all about being on the cutting edge, so moving backwards in versions is ... painful. What might be reasonable is to make new packages, linbox11 and givaro32, containing linbox 1.1.6 and givaro 3.2.15, respectively, for the use of sage. That way we can keep the newer versions around for anybody who might be using them, but still support sage. What do you think?
Em 26 de abril de 2012 11:30, Jerry James loganjerry@gmail.com escreveu:
2012/4/25 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
I think this is the major showstopper for now.
Jerry, do you think it is reasonably to downngrade and use linbox 1.1.6? Patching should be possible, but not much trivial, quick guess would be to use mpz interfaces for the apparently now deprecated or available elsewhere or other interfaces, integer matrix operations.
Linbox was updated from 1.1.6 to 1.1.7 before I became involved with it. Judging by the changelog, though, the problem is that 1.1.6 failed to build due to requiring an old version of givaro and 1.1.7 fixed the build problem: I became involved when the same problem occurred; givaro was updated, and then linbox 1.1.7 failed to build. I contacted upstream about the problem, and they suggested moving to linbox 1.2.1, which did solve it. The move to linbox 1.2.2 was coordinated with another new release of givaro.
In short, moving backwards in linbox versions will require also moving backwards in givaro versions.
Ok. Actually, I have been carrying patches for newer givaro with linbox 1.1.6 and sagemath in Mandriva for quite some time.
There is this request to update givaro http://trac.sagemath.org/sage_trac/ticket/9511 and it appears to have been updated, causing linbox to fail :-) http://trac.sagemath.org/sage_trac/ticket/12349
I just sent an email to linbox-devel asking for some help in integrating linbox 1.2.2 with sagemath 4.8 or newer, see http://groups.google.com/group/linbox-use/browse_thread/thread/713663b790d0d...
Sorry for more fedora newbie questions, but how do I query what requires a package? E.g. in Mandriva I can use
urpmq --whatrequires foobar
asking it to know what, if anything requires linbox.
repoquery --whatrequires foobar
Or, to find the total set of affected packages:
repoquery --whatrequires --recursive foobar
The repoquery command is provided by the yum-utils package.
Thanks!
sage 5.0 will also use linbox 1.1.6 from what I understand, or at least should be what is used in alpha builds.
Hmmm, that puts us in a difficult position. Fedora is all about being on the cutting edge, so moving backwards in versions is ... painful. What might be reasonable is to make new packages, linbox11 and givaro32, containing linbox 1.1.6 and givaro 3.2.15, respectively, for the use of sage. That way we can keep the newer versions around for anybody who might be using them, but still support sage. What do you think?
givaro should be ok, but by contacting upstream we hopefully should have all components working together. I just reported in sagemath trac: http://trac.sagemath.org/sage_trac/ticket/12883
-- Jerry James http://www.jamezone.org/ _______________________________________________ scitech mailing list scitech@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/scitech
Paulo
2012/4/26 Jerry James loganjerry@gmail.com:
Jerry, do you think it is reasonably to downngrade and use linbox 1.1.6? Patching should be possible, but not much trivial, quick guess would be to use mpz interfaces for the apparently now deprecated or available elsewhere or other interfaces, integer matrix operations.
Linbox was updated from 1.1.6 to 1.1.7 before I became involved with it. Judging by the changelog, though, the problem is that 1.1.6 failed to build due to requiring an old version of givaro and 1.1.7 fixed the build problem: I became involved when the same problem occurred; givaro was updated, and then linbox 1.1.7 failed to build. I contacted upstream about the problem, and they suggested moving to linbox 1.2.1, which did solve it. The move to linbox 1.2.2 was coordinated with another new release of givaro.
In short, moving backwards in linbox versions will require also moving backwards in givaro versions.
[...]
Hmmm, that puts us in a difficult position. Fedora is all about being on the cutting edge, so moving backwards in versions is ... painful. What might be reasonable is to make new packages, linbox11 and givaro32, containing linbox 1.1.6 and givaro 3.2.15, respectively, for the use of sage. That way we can keep the newer versions around for anybody who might be using them, but still support sage. What do you think?
Packaging linbox 1.1.6 may be an alternative, but proper approach should be to get both components to work together. I just attached two patches to http://trac.sagemath.org/sage_trac/ticket/12883 The sagemath side patch is http://trac.sagemath.org/sage_trac/attachment/ticket/12883/sage-4.8-linbox.p... and the patch for linbox 1.2.2, that would need to be applied to Fedora linbox package is: http://trac.sagemath.org/sage_trac/attachment/ticket/12883/linbox-sagemath.p...
As I stated in the trac, these are not final patches, just a call for feedback, as, while they most likely are correct, I did only test that it builds and makes both sides agree on api/abi.
Now my fedora sagemath package is stuck in lcalc :-)
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include/lcalc/ -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/local/include -Ic_lib/include -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-4.8-0.1.x86_64/usr/share/sagemath/devel/sage/sage/ext -I/usr/include/python2.7 -c sage/libs/lcalc/lcalc_Lfunction.cpp -o build/temp.linux-x86_64-2.7/sage/libs/lcalc/lcalc_Lfunction.o -O3 -ffast-math -w In file included from sage/libs/lcalc/lcalc_Lfunction.cpp:242:0: sage/libs/lcalc/lcalc_sage.h:1:15: fatal error: L.h: No such file or directory compilation terminated.
-- Jerry James http://www.jamezone.org/
Paulo
Hi Paulo,
Sorry for the silence. I was sick for a few days, and spent yesterday playing catchup at work. Nevertheless, late in the day yesterday, I updated the Fedora polybori package to install flags.conf and to build with NTL support. The new polybori build should be in today's Rawhide compose, and here is the Fedora 17 update:
https://admin.fedoraproject.org/updates/polybori-0.8.1-3.fc17
On Sat, Apr 28, 2012 at 7:44 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Packaging linbox 1.1.6 may be an alternative, but proper approach should be to get both components to work together. I just attached two patches to http://trac.sagemath.org/sage_trac/ticket/12883 The sagemath side patch is http://trac.sagemath.org/sage_trac/attachment/ticket/12883/sage-4.8-linbox.p... and the patch for linbox 1.2.2, that would need to be applied to Fedora linbox package is: http://trac.sagemath.org/sage_trac/attachment/ticket/12883/linbox-sagemath.p...
Okay, let's see what the Sage and linbox upstreams have to say about your patches.
As I stated in the trac, these are not final patches, just a call for feedback, as, while they most likely are correct, I did only test that it builds and makes both sides agree on api/abi.
Now my fedora sagemath package is stuck in lcalc :-)
Right, nobody has packaged lcalc for Fedora yet. I'll say more about that in reply to your other email.
2012/5/1 Jerry James loganjerry@gmail.com:
Hi Paulo,
Hi Jerry,
Sorry for the silence. I was sick for a few days, and spent yesterday playing catchup at work. Nevertheless, late in the day yesterday, I
Hope you are already well now :-)
updated the Fedora polybori package to install flags.conf and to build with NTL support. The new polybori build should be in today's Rawhide compose, and here is the Fedora 17 update:
https://admin.fedoraproject.org/updates/polybori-0.8.1-3.fc17
Ok, I am still figuring out my way with fedora, so, currently still running Fedora16 plus all updates, but plan to switch to rawhide shortly. For now I am ok with rebuilding some packages, like polybori, or already running a newer pari.
On Sat, Apr 28, 2012 at 7:44 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Packaging linbox 1.1.6 may be an alternative, but proper approach should be to get both components to work together. I just attached two patches to http://trac.sagemath.org/sage_trac/ticket/12883 The sagemath side patch is http://trac.sagemath.org/sage_trac/attachment/ticket/12883/sage-4.8-linbox.p... and the patch for linbox 1.2.2, that would need to be applied to Fedora linbox package is: http://trac.sagemath.org/sage_trac/attachment/ticket/12883/linbox-sagemath.p...
Okay, let's see what the Sage and linbox upstreams have to say about your patches.
Me too also waiting, otherwise, will take me some time to actually run sagemath in Fedora and debug it myself, as I believe if there is something wrong with the patch, it was my misunderstanding of things like arguments in format "A_nr, A_nc, B_nr, B_nc" renamed to "m, n, k" as the constraint is number of rows of A must match number of columns of B (for multiplication), or missed some place where there could be a double dereference or double free as linbox 1.1.6 did allocate a buffer for every matrix row and linbox 1.2.2 allocates a single buffer.
As I stated in the trac, these are not final patches, just a call for feedback, as, while they most likely are correct, I did only test that it builds and makes both sides agree on api/abi.
Now my fedora sagemath package is stuck in lcalc :-)
Right, nobody has packaged lcalc for Fedora yet. I'll say more about that in reply to your other email.
Ok. Once a newer pari is available I will update the lcalc package, but it is just a matter of applying the pari patch. Could add a build requires versioned, but not required as if applying the patch it would not build with an older pari anyway.
-- Jerry James http://www.jamezone.org/
Thanks, Paulo
2012/5/1 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
[...]
Okay, let's see what the Sage and linbox upstreams have to say about your patches.
Me too also waiting, otherwise, will take me some time to actually run sagemath in Fedora and debug it myself, as I believe if there is something wrong with the patch, it was my misunderstanding of things like arguments in format "A_nr, A_nc, B_nr, B_nc" renamed to "m, n, k" as the constraint is number of rows of A must match number of columns of B (for multiplication), or missed some place where there could be a double dereference or double free as linbox 1.1.6 did allocate a buffer for every matrix row and linbox 1.2.2 allocates a single buffer.
Today I made some experimental builds in a Mandriva computer where I have sagemath-4.8 working, to update to use givaro 3.5.0 and linbox 1.2.2. It is required significant extra patches to fully build sagemath, and a new patch is not yet complete, but by doing this, I will have a better idea of viability of using linbox 1.2.2, or patching linbox 1.1.6 to use newer givaro.
Once done the test build, I will see what breaks in sage doctests, hopefully nothing, or just require trivial patches, and then it should be easier to get it integrated in sagemath. Too bad I am afraid it will not be in time for sagemath 5.0, kind like too late even if patches were available and known to work 3 months ago...
Paulo
2012/5/2 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
2012/5/1 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
[...]
Okay, let's see what the Sage and linbox upstreams have to say about your patches.
Me too also waiting, otherwise, will take me some time to actually run sagemath in Fedora and debug it myself, as I believe if there is something wrong with the patch, it was my misunderstanding of things like arguments in format "A_nr, A_nc, B_nr, B_nc" renamed to "m, n, k" as the constraint is number of rows of A must match number of columns of B (for multiplication), or missed some place where there could be a double dereference or double free as linbox 1.1.6 did allocate a buffer for every matrix row and linbox 1.2.2 allocates a single buffer.
Today I made some experimental builds in a Mandriva computer where I have sagemath-4.8 working, to update to use givaro 3.5.0 and linbox 1.2.2. It is required significant extra patches to fully build sagemath, and a new patch is not yet complete, but by doing this, I will have a better idea of viability of using linbox 1.2.2, or patching linbox 1.1.6 to use newer givaro.
Once done the test build, I will see what breaks in sage doctests, hopefully nothing, or just require trivial patches, and then it should be easier to get it integrated in sagemath. Too bad I am afraid it will not be in time for sagemath 5.0, kind like too late even if patches were available and known to work 3 months ago...
Jerry, can you please add the attached patch to fflas-ffpack and better yet if get it in upstream :-) I am working on linbox 1.2.2 patches, that also need -D__LINBOX_HAVE_INT64=1 in CFLAGS and CXXFLAGS (optional for 32 bit arches and sagemath), as that is not defined anywhere, and should be done either in configure.ac and autoreconf, or just set it in linbox.spec, but still trying to get all bits together to get things to compile and then check if everything works...
Paulo
On Thu, May 3, 2012 at 1:03 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Jerry, can you please add the attached patch to fflas-ffpack and better yet if get it in upstream :-)
I have sent the patch upstream, and am building a new fflas-ffpack package now (for Rawhide and F17).
2012/5/3 Jerry James loganjerry@gmail.com:
On Thu, May 3, 2012 at 1:03 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Jerry, can you please add the attached patch to fflas-ffpack and better yet if get it in upstream :-)
I have sent the patch upstream, and am building a new fflas-ffpack package now (for Rawhide and F17).
Thanks!
I did get sagemath to build in mandriva with fflas-ffpack with that patch, and the new linbox and sagemath I am attaching, but for now, only for documentation purposes.
linbox 1.2.2 needs to be built with -D__LINBOX_HAVE_INT64=1 in CXXFLAGS and CFLAGS (otherwise the fflas-ffpack patch is not required).
The linbox patch corrects some prototypes, adds some extra definitions (cut&paste&adapt from modular-int32.h) and forces instantiation of some templates.
The sagemath patch builds the linbox interface and the matrix interfaces, but stops when building the givaro interface, as I also did need to update it in my Mandriva build as newer linbox wants it. I will get to the same state when I have singular package in fedora... But it may fail earlier if there is another component that does not match versions.
The sage-4.8-linbox.patch also needs to redefine mod_int to ssize_t instead of size_t, otherwise a very large patch would be required to implement uint64_t interfaces, or, could use the unsigned interfaces and force it to use uint32_t.
I also need to check more carefully sage/matrix/matrix_integer_dense.pyx because I may have missed the part where it free's it, and may not be using the __dealloc__ in sage/libs/linbox/linbox.pyx
The givaro build failure looks like:
gcc -pthread -shared -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags build/temp.linux-x86_64-2.7/sage/libs/ratpoints.o -Lc_lib -L/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/lib -L/usr/lib64 -lcsage -lratpoints -lgmp -lstdc++ -lntl -lm -lgmp -ldl -lpython2.7 -o build/lib.linux-x86_64-2.7/sage/libs/ratpoints.so gcc -pthread -fno-strict-aliasing -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -DNDEBUG -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -fPIC -fno-PIE -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/singular -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/factory -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include -Ic_lib/include -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/devel/sage/sage/ext -I/usr/include/python2.7 -c sage/libs/singular/singular.cpp -o build/temp.linux-x86_64-2.7/sage/libs/singular/singular.o -w In file included from sage/libs/singular/singular.cpp:252:0: /usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) In file included from sage/libs/singular/singular.cpp:252:0: /usr/include/givaro/givconfig.h:91:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) /usr/include/givaro/givconfig.h:97:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) /usr/include/givaro/givconfig.h:103:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) /usr/include/givaro/givconfig.h:109:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) /usr/include/givaro/givconfig.h:115:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) /usr/include/givaro/givconfig.h:121:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) /usr/include/givaro/givconfig.h:127:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :) sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does not name a type sage/libs/singular/singular.cpp: In function '__pyx_obj_4sage_5rings_12finite_rings_14element_givaro_FiniteField_givaroElement* __pyx_f_4sage_4libs_8singular_8singular_si2sa_GFqGivaro(snumber*, ip_sring*, __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro*)': sage/libs/singular/singular.cpp:3383:30: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' sage/libs/singular/singular.cpp:3392:32: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' sage/libs/singular/singular.cpp:3401:35: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' sage/libs/singular/singular.cpp:3421:32: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' sage/libs/singular/singular.cpp:3449:36: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' sage/libs/singular/singular.cpp:3461:48: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' sage/libs/singular/singular.cpp:3470:36: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' sage/libs/singular/singular.cpp: In function 'snumber* __pyx_f_4sage_4libs_8singular_8singular_sa2si(__pyx_obj_4sage_9structure_7element_Element*, ip_sring*)': sage/libs/singular/singular.cpp:6150:186: error: 'struct __pyx_obj_4sage_5rings_12finite_rings_14element_givaro_Cache_givaro' has no member named 'objectptr' error: command 'gcc' failed with exit status 1
-- Jerry James http://www.jamezone.org/
Paulo
2012/5/3 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
[...]
/usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :)
This warning is all over the place, but so far, with the attached linbox-integer.patch on top of an installed system it does not fail earlier. But should get __STDC_LIMIT_MACROS defined before the first c++ code includes stdint.h ...
[...]
sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does not name a type sage/libs/singular/singular.cpp: In function
The attached sage-fedora-prepare.patch is another work in progress patch, that should be helpful to give an idea of what needs to be patched to build with newer linbox, sytem cudd, m4ri, m4rie, etc.
I did some work to attempt to have Mandriva using the same versions and as close as possible packages, so that I can know more of what to expect during preparation to package sagemath in Fedora.
BTW, current build failure looks like:
gcc -pthread -fno-strict-aliasing -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -DNDEBUG -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -fPIC -fno-PIE -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/cudd -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/polybori -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include/polybori/groebner -Isage/libs/polybori -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/local/include -Ic_lib/include -I/home/pcpa/rpm/BUILDROOT/sagemath-4.8-2-mdv2012.0.x86_64-buildroot/usr/share/sage/devel/sage/sage/ext -I/usr/include/python2.7 -c sage/rings/polynomial/pbori.cpp -o build/temp.linux-x86_64-2.7/sage/rings/polynomial/pbori.o -DPBORI_NDEBUG -DSIZEOF_VOID_P=8 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DPBORI_HAVE_GD -DPBORI_HAVE_TR1_UNORDERED_MAP -DPBORI_HAVE_M4RI -DPBORI_USE_ORIGINAL_CUDD -DPBORI_HAVE_NTL -mmmx -msse -msse2 -w sage/rings/polynomial/pbori.cpp: In function 'int __pyx_pf_4sage_5rings_10polynomial_5pbori_21BooleanPolynomialRing___init__(PyObject*, PyObject*, PyObject*)': sage/rings/polynomial/pbori.cpp:4937:5: error: 'appendBlock' is not a member of 'polybori::BooleEnv' sage/rings/polynomial/pbori.cpp: In function 'PyObject* __pyx_pf_4sage_5rings_10polynomial_5pbori_21BooleanPolynomialRing_4gen(PyObject*, PyObject*, PyObject*)': sage/rings/polynomial/pbori.cpp:5485:393: error: could not convert 'polybori::BoolePolyRing::variable(polybori::BoolePolyRing::checked_idx_type) const(polybori::CCheckedIdx(((polybori::CAuxTypes::idx_type)(*(((__pyx_obj_4sage_5rings_10polynomial_5pbori_BooleanPolynomialRing*)__pyx_v_self)->__pyx_obj_4sage_5rings_10polynomial_5pbori_BooleanPolynomialRing::pbind + ((long unsigned int)(((long unsigned int)__pyx_t_3) * 8ul)))))))' from 'polybori::BoolePolyRing::var_type {aka polybori::BooleVariable}' to 'polybori::BooleSet'
[[ at least 100Kb of error messages here ]]
/usr/include/polybori/BooleVariable.h:63:3: note: no known conversion for argument 1 from 'const int' to 'const ring_type& {aka const polybori::BoolePolyRing&}' /usr/include/polybori/BooleVariable.h:59:3: note: polybori::BooleVariable::BooleVariable(polybori::CAuxTypes::idx_type, const ring_type&) /usr/include/polybori/BooleVariable.h:59:3: note: candidate expects 2 arguments, 1 provided error: command 'gcc' failed with exit status 1
Well, for singular, at least for now I think it is better to use exactly the version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora) appears to be going to require quite some work ...
Paulo
On Fri, May 4, 2012 at 3:19 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
/usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :)
This warning is all over the place, but so far, with the attached linbox-integer.patch on top of an installed system it does not fail earlier. But should get __STDC_LIMIT_MACROS defined before the first c++ code includes stdint.h ...
Right, I had to do that with m4rie also.
sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does not name a type sage/libs/singular/singular.cpp: In function
Also an issue with m4rie. The problem is that there is now a namespace involved, so you have to change all instances of GFqDom to Givaro::GFqDom.
The attached sage-fedora-prepare.patch is another work in progress patch, that should be helpful to give an idea of what needs to be patched to build with newer linbox, sytem cudd, m4ri, m4rie, etc.
Okay, I'll look through it over the weekend. If you have parts that you think are ready to go, the best thing to do is file a bug. That way the patches won't get lost or forgotten.
Well, for singular, at least for now I think it is better to use exactly the version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora) appears to be going to require quite some work ...
Okay, we can pursue that path.
Incidentally, looking at the latest Singular release, I see that it can use flint if it is available. We have flint 1.6, which I kept deliberately because Sage's flint package is at 1.5.0. However, Singular wants flint 2.3! What should we do there? Is there a part of sage that really needs the older flint version, or should I upgrade it for Singular?
2012/5/4 Jerry James loganjerry@gmail.com:
On Fri, May 4, 2012 at 3:19 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
/usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :)
This warning is all over the place, but so far, with the attached linbox-integer.patch on top of an installed system it does not fail earlier. But should get __STDC_LIMIT_MACROS defined before the first c++ code includes stdint.h ...
Right, I had to do that with m4rie also.
sage/libs/singular/singular.cpp:922:3: error: 'GFqDom' does not name a type sage/libs/singular/singular.cpp: In function
Also an issue with m4rie. The problem is that there is now a namespace involved, so you have to change all instances of GFqDom to Givaro::GFqDom.
Yes, that was what I did, plus a few other Givaro:: added to the cython sources in sage-fedora-prepare.patch.
The attached sage-fedora-prepare.patch is another work in progress patch, that should be helpful to give an idea of what needs to be patched to build with newer linbox, sytem cudd, m4ri, m4rie, etc.
Okay, I'll look through it over the weekend. If you have parts that you think are ready to go, the best thing to do is file a bug. That way the patches won't get lost or forgotten.
Right now I will prefer to avoid proposing incomplete patches over incomplete patches; I already submitted two patches to the sagemath trac, but specified that they were only to give an idea of the issue, and a call for feedback...
Well, for singular, at least for now I think it is better to use exactly the version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora) appears to be going to require quite some work ...
Okay, we can pursue that path.
I am going to also give up in attempting to get sage-4.8 working, and work on sage-5.0-rc0, at least it already uses polybori-0.8.1, what makes life easier for me :-) But I am afraid it may not be easy to get all patches integrated, because too many components will need to be updated at once. But IMHO it is sage that is not playing so nice with upstream, letting several components versions rot, and making things harder for anybody willing to get sagemath working with system packages in a Linux distro.
Incidentally, looking at the latest Singular release, I see that it can use flint if it is available. We have flint 1.6, which I kept deliberately because Sage's flint package is at 1.5.0. However, Singular wants flint 2.3! What should we do there? Is there a part of sage that really needs the older flint version, or should I upgrade it for Singular?
I really hope flint 2.3 is api compatible with flint 1.5.0, but did not look at details so far.
Well, in Mandriva, unless it was an already a system package, or maintained by somebody else, I always packaged the version required by sagemath, this way things are easier to handle. And still took me quite some time to have a usable package after getting all components working together. But I plan to submit a singular package for review shortly, unless you want to beat me to that, then, I suggest following the pattern of the Mandriva package to avoid too much problems with missing headers, as well as the sagemath patches:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/singular/current/...
-- Jerry James http://www.jamezone.org/ _______________________________________________ scitech mailing list scitech@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/scitech
Paulo
2012/5/4 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com:
[...]
Well, for singular, at least for now I think it is better to use exactly the version used by sagemath, as polybori 0.7.1 (sagemath) to 0.8.1 (fedora) appears to be going to require quite some work ...
Okay, we can pursue that path.
[...]
Incidentally, looking at the latest Singular release, I see that it can use flint if it is available. We have flint 1.6, which I kept deliberately because Sage's flint package is at 1.5.0. However, Singular wants flint 2.3! What should we do there? Is there a part of sage that really needs the older flint version, or should I upgrade it for Singular?
I really hope flint 2.3 is api compatible with flint 1.5.0, but did not look at details so far.
I made a review request for a Singular package at https://bugzilla.redhat.com/show_bug.cgi?id=819264
With the generated Singular and Singular-devel the sagemath 5.0.rc0 build fails at:
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/malloc/ -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.x86_64/usr/share/sagemath/local/include -Ic_lib/include -I/home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.x86_64/usr/share/sagemath/devel/sage/sage/ext -I/usr/include/python2.7 -c sage/libs/symmetrica/symmetrica.c -o build/temp.linux-x86_64-2.7/sage/libs/symmetrica/symmetrica.o -w In file included from sage/libs/symmetrica/symmetrica.c:237:0: /usr/include/symmetrica/macro.h:174:1: error: unknown type name 'INT' In file included from sage/libs/symmetrica/symmetrica.c:237:0: /usr/include/symmetrica/macro.h:269:1: error: unknown type name 'INT' In file included from sage/libs/symmetrica/symmetrica.c:237:0: /usr/include/symmetrica/macro.h:557:1: error: unknown type name 'INT' /usr/include/symmetrica/macro.h:560:1: error: unknown type name 'INT' error: command 'gcc' failed with exit status 1
symmetrica as packaged in Fedora should have the sagemath patches added to it. First the above case due to symmetrica/macros.h needing a typedef in symmetrica/def.h. The other patches are to not have the symbols "sort" and "sum" in global namespace, and the other patch is to avoid it printing a banner.
The patches can be fetched from the sagemath package, or also from http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/symmetrica/curren...
Jerry, a possible issue with the Singular package is that the generated Singular-devel package conflicts with libfac-devel, but only headers, because all code is in libsingular.so, so, I believe it could be changed to install headers in /usr/include/singular, as code compiling with it should be using #include <factory/...> and having -I/usr/include/singular in CPPPATH.
Paulo
2012/5/4 Jerry James loganjerry@gmail.com:
On Fri, May 4, 2012 at 3:19 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
/usr/include/givaro/givconfig.h:85:17: note: #pragma message: #warning somebody nasty previously included <stdint.h> without __STDC_LIMIT_MACROS :)
This warning is all over the place, but so far, with the attached linbox-integer.patch on top of an installed system it does not fail earlier. But should get __STDC_LIMIT_MACROS defined before the first c++ code includes stdint.h ...
Right, I had to do that with m4rie also.
Jerry, sorry for more newbie questions, but what is the procedure to request a package update?
I did upload a new symmetrica with patches to continue sagemath build:
Spec URL: http://kenobi.mandriva.com/~pcpa/symmetrica.spec SRPM URL: http://kenobi.mandriva.com/~pcpa/symmetrica-2.0-7.fc16.src.rpm
Also, what you suggest to "update" to run rawhide?
Thanks, Paulo
On Sat, May 5, 2012 at 10:20 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Jerry, sorry for more newbie questions, but what is the procedure to request a package update?
File a bug against the package in bugzilla. Often, people will prefix the bug summary with "RFE: " (Request For Enhancement). The current symmetrica maintainer is Conrad Meyer. I am comaintaining several of his packages, because he has been short on time recently for working on Fedora packaging. I will contact him about comaintaining symmetrica also.
Also, what you suggest to "update" to run rawhide?
I still think you should update to F-17. Really. It's about to be released, but you can get the nearly final version as described here:
http://lists.fedoraproject.org/pipermail/devel/2012-May/166719.html
I'm not sure if the preupgrade package is ready to go yet or not, but you could try that as well. If you really, really want to install Rawhide, then install the fedora-release-rawhide package, then edit the files in /etc/yum.repos.d to enable the Rawhide repositories and disable your current repositories. Then run "yum distro-sync" and cross your fingers. Backup your system first, either way!
2012/5/7 Jerry James loganjerry@gmail.com:
On Sat, May 5, 2012 at 10:20 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Jerry, sorry for more newbie questions, but what is the procedure to request a package update?
File a bug against the package in bugzilla. Often, people will prefix the bug summary with "RFE: " (Request For Enhancement). The current symmetrica maintainer is Conrad Meyer. I am comaintaining several of his packages, because he has been short on time recently for working on Fedora packaging. I will contact him about comaintaining symmetrica also.
Ok. Thanks for addressing the flint problem. I did not add RFE: to the symmetrica bug report, but can do that. I think it would be also reasonably to rename more functions, because they use names too much generic, e.g. add, sub, mult, div, sum, sort, etc.
Also, what you suggest to "update" to run rawhide?
I still think you should update to F-17. Really. It's about to be released, but you can get the nearly final version as described here:
http://lists.fedoraproject.org/pipermail/devel/2012-May/166719.html
I'm not sure if the preupgrade package is ready to go yet or not, but you could try that as well. If you really, really want to install Rawhide, then install the fedora-release-rawhide package, then edit the files in /etc/yum.repos.d to enable the Rawhide repositories and disable your current repositories. Then run "yum distro-sync" and cross your fingers. Backup your system first, either way!
Thanks! I will wait a bit more, as for now I can build from sources whatever I need, but should shortly attempt to switch to rawhide, as I am used to run bleeding edge :-)
-- Jerry James http://www.jamezone.org/
Paulo
On Mon, May 7, 2012 at 10:48 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Ok. Thanks for addressing the flint problem. I did not add RFE: to the symmetrica bug report, but can do that. I think it would be also reasonably to rename more functions, because they use names too much generic, e.g. add, sub, mult, div, sum, sort, etc.
I have rebuilt symmetrica. I addressed one other problem. I saw lots of complaints in the initial build log about printf format specifiers being the wrong width. A little investigation found multiple comments in the sources about the INT type being 4 bytes. But it was 4 bytes on some architectures and 8 bytes on others. I fixed the headers to ensure that INT is always 4 bytes, which led to a different set of printf format specifier problems. Sigh. I finally got the thing patched so that all of the code agrees that INT is 4 bytes.
Thanks! I will wait a bit more, as for now I can build from sources whatever I need, but should shortly attempt to switch to rawhide, as I am used to run bleeding edge :-)
Good luck. :-)
2012/5/8 Jerry James loganjerry@gmail.com:
On Mon, May 7, 2012 at 10:48 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andrade@gmail.com wrote:
Ok. Thanks for addressing the flint problem. I did not add RFE: to the symmetrica bug report, but can do that. I think it would be also reasonably to rename more functions, because they use names too much generic, e.g. add, sub, mult, div, sum, sort, etc.
I have rebuilt symmetrica. I addressed one other problem. I saw lots of complaints in the initial build log about printf format specifiers being the wrong width. A little investigation found multiple comments in the sources about the INT type being 4 bytes. But it was 4 bytes on some architectures and 8 bytes on others. I fixed the headers to ensure that INT is always 4 bytes, which led to a different set of printf format specifier problems. Sigh. I finally got the thing patched so that all of the code agrees that INT is 4 bytes.
There is still a problem:
Exception occurred: File "/home/pcpa/rpmbuild/BUILDROOT/sagemath-5.0.rc0-1.fc16.x86_64/usr/lib64/python2.7/site-packages/sage/libs/symmetrica/all.py", line 3, in <module> from symmetrica import start, end ImportError: /usr/lib64/libsymmetrica.so.0: undefined symbol: local_ende
It probably would be better to set DFLAGS in symmetrica,spec to -DALLTRUE -DFAST like the original makefile does, otherwise, it is required to remove -DLOCALTRUE
$ grep local_ende BUILD/symmetrica-2.0/*.c BUILD/symmetrica-2.0/de.c: local_ende(); /* AK 280705 */ $ grep local_anfang BUILD/symmetrica-2.0/*.c BUILD/symmetrica-2.0/de.c: local_anfang(); /* AK 280705 */
I asked and was granted commit access in the symmetrica bugzilla, but I think it is better for you to correct it as you already did a lot of extra work on it :-)
Thanks! I will wait a bit more, as for now I can build from sources whatever I need, but should shortly attempt to switch to rawhide, as I am used to run bleeding edge :-)
Good luck. :-)
Thanks :-)
-- Jerry James http://www.jamezone.org/
Paulo
Em 25 de abril de 2012 18:39, Jerry James loganjerry@gmail.com escreveu:
[...]
For the NTL patch probably we should contact upstream to attempt to have it (not exactly as is in the above link), or an alternate patch with the same feature added.
I am adding the NTL package maintainer to CC to make him aware of this issue. Regards,
Ok. I am reviewing some cases where I did the dirty&easy way of just adapt sagemath patches and not report upstream :-( So, I just requested the feature, posting to ntl upstream mailing list.
-- Jerry James http://www.jamezone.org/
Paulo
scitech@lists.fedoraproject.org
-
Jerry James -
Paulo César Pereira de Andrade