<elflng>the second is to totally change around how ints do exponentiation. more on that later as there are a huge number of pitfalls, some of which have been commented already in the code and the history, and some of which they missed entirely.
<bonz060>Cool! I'll try to work something out in the meantime \m/\m/
<elflng>fwiw, the original bug report is incorrect - theres no way that 64 bit python 2.4 on x86_64 will ever give the correct results. as an interesting sidenote - the 32 bit one i have was compiled for 64 bit systems
<elflng>so apparently these bugs were known. (the rest of the libraries on this backup are 64bit)
<elflng>one more thing before i go: it may pay to look at the 2.6 exponentiation for integers and copy that in as the patch, as 2.6 is 64bit compiled and gives correct results, i think.
<elflng>theres a few other functions that will give weird results too. look at anything in intobject that does a double conversion implicitly for the result
<bonz060>I've managed to have a successful 32bit build by running: ./pre-inst-env guix build -L ~/projects/guix-past/modules firstname.lastname@example.org --system=i686-linux. Had to tweak the package definition to disable parallel-tests. Getting weird results too: 2 ** 63 = 0 ; 2 ** 33 = 0 ; 2 ** 32 = 0 ; 2 ** 31 = -2147483648
<bonz060>elflng: I don't think the problem's with how the package is defined... I'm thinking that there's something up with the build flags. I'm wondering if providing libm would have any effect? Thoughts?
<elflng>the problem has to do with how its doing the integer->double conversions for certain ops
<elflng>its assuming that sizeof(int) < sizeof(long) and sizeof(long) <= sizeof(double)
<elflng>i dont know what the env you have is ... when you do 'file python2.4', is it showing up as a 64 bit or a 32 bit executable?
<elflng>you probably need a whole 32-bit toolchain to pull this off correctly, if you want to compile it as 32 bit - just changing system wont help. im not sure it respects the system flag, regardless.