Re: [GiNaC-devel] [GiNaC] patches and questions
Hi, Paul Irofti schrieb:
I maintain the ginac port for OpenBSD and I'm trying to update it to the latest version (ginac-1.4.3). In doing that I encountered a few problems that I fixed. Maybe we can get them commited upstream too? I've attached the patches to this email.
thanks for the patches! I applied most of them into our repository. A release 1.4.4 might soon follow in the next days. :-)
The chec_matrices.cpp patch is for a regression test that goes through an infinite loop when attempting to do inverse_matrix() and the determinant never becomes 0. So I had to comment that out until we can fix it. Maybe you have a solution for this.
I don't know about this one. The check doesn't fail here (and never did before AFAIR). Maybe this happens only on OpenBSD? Sounds strange. I use cln 1.2.2 and gcc 4.3.1. Maybe the bug is related to these tools?
The configure patch is for detecting and enabling ::compile stuff, it might be OpenBSD specific, but it would be cool if you could make a separate case for that upstream.
I also don't know how to treat this one. Your patch applies to "configure". But in the source "configure.ac" LIBS is not explicitly extended by "-ldl", only DL_LIBS. So, this seems like we cannot repair it. Maybe autoconf mixes it up?
The ginac-examples texi was missing a directory entry for info, you should add that upstream. And the Makefile.in patch removes the release target in order to generate proper .so with proper versioning.
I applied these both. Thanks! Regards, Jens
Hi, On Wed, Nov 05, 2008 at 02:41:32PM +0100, Jens Vollinga wrote:
And the Makefile.in patch removes the release target in order to generate proper .so with proper versioning.
I applied these both.
Please revert the second patch. First of all, there's nothing wrong with current versioning scheme. Secondly, changing SONAME in that way breaks every binary linked with libginac (i.e. binary linked with GiNaC 1.4.3 won't work any more after upgrade to 1.4.4). Since we maintain binary compatibility in stable releases, changes like this are inacceptable (that is, even if the patch in question were correct).
I also don't know how to treat this one. Your patch applies to "configure". But in the source "configure.ac" LIBS is not explicitly extended by "-ldl", only DL_LIBS. So, this seems like we cannot repair it. Maybe autoconf mixes it up?
The thing is: dlopen() is in libc on OpenBSD, so there's no need to link with -ldl. I've changed GINAC_EXCOMPILER m4 macro to check for dlopen() in libdl and libc (see commit 375a7aa1f13fa6061c278eb2c2447fd91521b45d in my repository).
The chec_matrices.cpp patch is for a regression test that goes through an infinite loop when attempting to do inverse_matrix() and the determinant never becomes 0. So I had to comment that out until we can fix it. Maybe you have a solution for this.
I don't know about this one. The check doesn't fail here (and never did before AFAIR). Maybe this happens only on OpenBSD? Sounds strange.
It seems to be OpenBSD's rand() bug. The following program illustrates it: $ cat badrand.c #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv) { unsigned int i, modulus; modulus = 2; if (argc > 1) modulus = atoi(argv[1]); for (i = 0; i < 32; ++i) printf("%d: rand() %% %d = %d\n", i, modulus, rand() % modulus); return 0; } On GNU/Linux it gives something like 0: rand() % 2 = 1 1: rand() % 2 = 0 2: rand() % 2 = 1 3: rand() % 2 = 1 4: rand() % 2 = 1 5: rand() % 2 = 1 6: rand() % 2 = 0 7: rand() % 2 = 0 8: rand() % 2 = 1 9: rand() % 2 = 1 10: rand() % 2 = 0 11: rand() % 2 = 1 12: rand() % 2 = 0 13: rand() % 2 = 1 14: rand() % 2 = 1 15: rand() % 2 = 0 16: rand() % 2 = 0 17: rand() % 2 = 0 18: rand() % 2 = 0 19: rand() % 2 = 0 20: rand() % 2 = 1 21: rand() % 2 = 0 22: rand() % 2 = 1 23: rand() % 2 = 1 24: rand() % 2 = 0 25: rand() % 2 = 0 26: rand() % 2 = 0 27: rand() % 2 = 1 28: rand() % 2 = 1 29: rand() % 2 = 1 30: rand() % 2 = 1 31: rand() % 2 = 0 On OpenBSD the output looks like: 0: rand() % 2 = 0 1: rand() % 2 = 1 2: rand() % 2 = 0 3: rand() % 2 = 1 4: rand() % 2 = 0 5: rand() % 2 = 1 6: rand() % 2 = 0 7: rand() % 2 = 1 8: rand() % 2 = 0 9: rand() % 2 = 1 10: rand() % 2 = 0 11: rand() % 2 = 1 12: rand() % 2 = 0 13: rand() % 2 = 1 14: rand() % 2 = 0 15: rand() % 2 = 1 16: rand() % 2 = 0 17: rand() % 2 = 1 18: rand() % 2 = 0 19: rand() % 2 = 1 20: rand() % 2 = 0 21: rand() % 2 = 1 22: rand() % 2 = 0 23: rand() % 2 = 1 24: rand() % 2 = 0 25: rand() % 2 = 1 26: rand() % 2 = 0 27: rand() % 2 = 1 28: rand() % 2 = 0 29: rand() % 2 = 1 30: rand() % 2 = 0 31: rand() % 2 = 1 No randomness at all. That's why symbolic_matrix_inverse() always produces 4x4 matrix with several rows being zero. Such matrix is (obviously) degenerate, so the loop 179 do { 180 for (unsigned co=0; co<size; ++co) { 181 for (unsigned ro=0; ro<size; ++ro) { 182 // populate some elements 183 ex elem = 0; 184 if (rand()%(size/2) == 0) 185 elem = sparse_tree(a, b, c, rand()%2, false, true, false); 186 A.set(ro,co,elem); 187 } 188 } 189 } while (A.determinant() == 0); never terminates. Hopefully OpenBSD developers will fix their RNG. Best regards, Alexei -- All science is either physics or stamp collecting.
Hi, Alexei Sheplyakov schrieb:
Please revert the second patch. First of all, there's nothing wrong with current versioning scheme. Secondly, changing SONAME in that way breaks every binary linked with libginac (i.e. binary linked with GiNaC 1.4.3 won't work any more after upgrade to 1.4.4). Since we maintain binary compatibility in stable releases, changes like this are inacceptable (that is, even if the patch in question were correct).
okay, thanks! I skimmed to quickly through the libtool manual and only read the part that supports the elimination of -release ...
The thing is: dlopen() is in libc on OpenBSD, so there's no need to link with -ldl. I've changed GINAC_EXCOMPILER m4 macro to check for dlopen() in libdl and libc (see commit 375a7aa1f13fa6061c278eb2c2447fd91521b45d in my repository).
Since a cherry-pick failed I applied the changes by hand. Hope it works. Regards, Jens
Hi, On Wed, Nov 05, 2008 at 05:10:39PM +0100, Jens Vollinga wrote:
The thing is: dlopen() is in libc on OpenBSD, so there's no need to link with -ldl. I've changed GINAC_EXCOMPILER m4 macro to check for dlopen() in libdl and libc (see commit 375a7aa1f13fa6061c278eb2c2447fd91521b45d in my repository).
Since a cherry-pick failed
Because this patch depends on a32a30d8ccdd0eb945b8180c8fe82d154e9280de ("Allow user to disable GiNaC::compile_ex"), which in turn depends on other patches.
I applied the changes by hand. Hope it works.
Unfortunately your changes have no effect, since configure.ac in 1.4 branch does not use GINAC_EXCOMPILER macro. Could you please revert your changes? I'll backport necessary stuff tomorrow. Best regards, Alexei -- All science is either physics or stamp collecting.
Hello, On Thu, Nov 06, 2008 at 02:21:02PM +0100, Jens Vollinga wrote:
Alexei Sheplyakov schrieb:
does not use GINAC_EXCOMPILER macro. Could you please revert your changes? I'll backport necessary stuff tomorrow.
done.
Fine. Could you please pull from git://ffmssmsc.jinr.ru:443/varg/ginac.git ginac_1-4 <semi-automatic reminder> < These patches are for ginac_1-4 branch > ---------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || </semi-automatic reminder> Basically, there are 1. build scripts update 2. power::is_polynomial fix (which got lost for some reason). Alexei Sheplyakov (13): build: don't run any ${host} binaries while checking for readline. build: faster check for standard C++ headers. configure: don't check for sizeof(long double), we don't use it. utils.h: use <stdint.h> (if available) instead of reinventing it. configure: don't bother to run checks which can be done at the compile time. configure: run important checks first (and bail out if something is missing). Allow user to disable GiNaC::compile_ex (e.g. for security reasons). build: put (almost) all auto* tools scripts into the config directory. build: shut up automake warnings, don't use GNU make extensions. [portability] GiNaC::compile_ex works on OpenBSD now. [build] Set correct rpath for linking with CLN... [build] Simplify generation of ginac/version.h Fix is_polynomial() so it works as advertised in the manual. Makefile.am | 2 + acinclude.m4 | 152 ++++++++--- check/Makefile.am | 6 +- check/check_is_polynomial.cpp | 30 ++ config/config.rpath | 614 +++++++++++++++++++++++++++++++++++++++ configure.ac | 88 ++---- debian/rules | 1 + doc/examples/Makefile.am | 4 +- doc/tutorial/Makefile.am | 6 +- ginac.pc.in | 2 +- ginac/power.cpp | 2 + ginac/utils.h | 23 +- ginac/version.h.in | 12 +- ginsh/ginsh_parser.yy | 45 +-- m4/lib-ld.m4 | 110 +++++++ m4/lib-link.m4 | 644 +++++++++++++++++++++++++++++++++++++++++ m4/lib-prefix.m4 | 185 ++++++++++++ 17 files changed, 1780 insertions(+), 146 deletions(-) create mode 100644 check/check_is_polynomial.cpp create mode 100755 config/config.rpath create mode 100644 m4/lib-ld.m4 create mode 100644 m4/lib-link.m4 create mode 100644 m4/lib-prefix.m4
And causing some additional noise in the index :-/
Well, human beings do make mistakes sometimes. Best regards, Alexei -- All science is either physics or stamp collecting.
Hi, Alexei Sheplyakov schrieb:
git://ffmssmsc.jinr.ru:443/varg/ginac.git ginac_1-4
done.
---------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||
The w is kind of cute ;-) I updated some more files for the release. This is now the last chance to change something before 1.4.4 will be release! Regards, Jens
Hello, On Fri, Nov 07, 2008 at 02:55:18PM +0100, Jens Vollinga wrote:
I updated some more files for the release. This is now the last chance to change something before 1.4.4 will be release!
I've cherry-picked yet another patch (which updates installation instructions). Could you please pull it from git://ffmssmsc.jinr.ru:443/varg/ginac.git ginac_1-4 Best regards, Alexei -- All science is either physics or stamp collecting.
participants (2)
-
Alexei Sheplyakov
-
Jens Vollinga