Singular fails to build on OSX with 64bit kernel

[vbraun]

OSX usually runs a 32bit kernel (uname -m == 'i386'), but very new Macs default to a 64bit kernel (uname -m == 'x86_64'). This breaks Singular, since the singuname.sh script is not aware of the possibility of x86_64.

From the OSX 10.6 wikipedia page  http://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard

Newer Xserve and Mac Pro machines will run a 64-bit kernel by default; newer iMac machines can run a 64-bit kernel, but will not do so by default. Users wishing to use the 64-bit kernel on those machines must hold down the numbers 6 and 4 on the keyboard while booting to get the 64-bit kernel to load.

Franco Saliola on sage-devel ( https://groups.google.com/d/msg/sage-release/X1J1ciueT5A/doPR9vPVZVAJ) has checked that modifying singuname.sh to return ix86Mac-darwin (same as other OSX versions) allows Singular to build correctly.

Updated spkg is here:

 http://www.stp.dias.ie/~vbraun/Sage/spkg/singular-3-1-1-4.p4.spkg

[vbraun]

I've reported it upstream at  http://www.singular.uni-kl.de:8002/trac/ticket/313

[vbraun]

Upstream agrees that the changes are correct, although they want to introduce a new label because it is also used for binary packages. Since we have our own labels for binary distributions, we can just use the original workaround until the next upstream release.

I've made an updated singular spkg. Franco, can you test it?

I also tried to upgrade Singular to 3-1-2, but found that rather complicated since the location of many headers moved.

[saliola]

Replying to vbraun:

I've made an updated singular spkg. Franco, can you test it?

Sure thing, but can you point me to some documentation on how to swap the old spkg with the new one?

[vbraun]

You can force-install (-f) the spkg from the command line via

sage -f http://www.stp.dias.ie/~vbraun/Sage/spkg/singular-3-1-1-4.p4.spkg

[saliola]

Replying to vbraun:

You can force-install (-f) the spkg from the command line via

sage -f http://www.stp.dias.ie/~vbraun/Sage/spkg/singular-3-1-1-4.p4.spkg

Oh, I see. I thought I was supposed to attempt a fresh install with this spkg in place of the old one.

I'll report back soon.

[vbraun]

you can do that too, just put the new singular spkg in $SAGE_ROOT/spkg/standard. The build will use the newest version in that directory. But considering that this is just a small build fix I don't think that its necessary to go through a completely fresh build...

[saliola]

Replying to vbraun:

just put the new singular spkg in $SAGE_ROOT/spkg/standard.

I did exactly this. It compiled without a problem. However, there was a doctest failure when I ran make ptest:

sage -t -force_lib "devel/sage/sage/groups/matrix_gps/matrix_group.py"
**********************************************************************
File "/Users/saliola/sage-4.6.2.alpha3-trac10739/devel/sage/sage/groups/matrix_gps/matrix_group.py", line 668:
    sage: G.random_element()
Expected:
    [2 1 1 1]
    [1 0 2 1]
    [0 1 1 0]
    [1 0 0 1]
Got:
    [0 1 1 0]
    [1 2 2 2]
    [1 1 1 0]
    [2 0 1 2]
**********************************************************************
File "/Users/saliola/sage-4.6.2.alpha3-trac10739/devel/sage/sage/groups/matrix_gps/matrix_group.py", line 679:
    sage: G.random_element()
Expected:
    [1 3]
    [0 3]
Got:
    [4 2]
    [1 0]
**********************************************************************
File "/Users/saliola/sage-4.6.2.alpha3-trac10739/devel/sage/sage/groups/matrix_gps/matrix_group.py", line 682:
    sage: G.random_element()
Expected:
    [2 2]
    [1 0]
Got:
    [4 1]
    [0 2]
**********************************************************************
File "/Users/saliola/sage-4.6.2.alpha3-trac10739/devel/sage/sage/groups/matrix_gps/matrix_group.py", line 685:
    sage: G.random_element()
Expected:
    [4 0]
    [1 4]
Got:
    [2 4]
    [2 3]
**********************************************************************
1 items had failures:
   4 of  10 in __main__.example_22
***Test Failed*** 4 failures.

Interestingly, this is precisely the same error (including the same output) as in #9310. Note that I now have two independent builds of sage-4.6.2.alpha3 on my machine, one in which this test passes and the other in which it fails.

Anyhow, I think this doctest failure is unrelated. Your fix works perfectly, so I am willing to give it a positive review provided that you agree that the above failure is unrelated.

[vbraun]

Yes, the different random seed for matrices must be an unrelated issue.

But if one build repeatedly passes "make ptest" and the other consistently fails, this would be an excellent opportunity to debug #9310. Presumably the only difference is that the first compilation was interrupted at one point, so the order in which spkgs were built is different. This might have changed linked libraries in some components due to (undiscovered) soft dependencies, for example. Can you diff the two trees (excluding log files etc) and find out the difference?

[saliola]

I agree that this is a good opportunity to debug #9310; I'll mark this as positive review and move the conversation to #9310.