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.