[Scilab-Dev] 64-bit build oddness

[Crispin Boylan]

hi

thanks for taking a look , but it is already linking against refBLAS, i 
dont have openBLAS installed anywhere.

i tried running the lapack/blas testsuite and all tests pass successfully.

given that the binary version runs successfully. on the same machine i 
figure it's not glibc...

any other ideas for me to try?

thanks
cris.


On 25/08/15 13:30, Clément David wrote:
> Hello,
>
> On my Fedora 22 laptop, the build PASS on Intel platforms (both i686
> x86_64) [1].
>
> On your log I found that you are using openblas ; can you try linking
> against refBLAS ?
>
> [1]: https://apps.fedoraproject.org/packages/scilab
>
> Regards,
>
> --
> Clément <davidcl> David
>
> Le dimanche 23 août 2015 à 23:55 +0100, Crispin Boylan a écrit :
>> hi
>>
>> i wonder if anyone can help me with some build weirdness i'm
>> experiencing.  Any help appreciated as it has me totally stumped.
>>
>> On openmandriva I can build i586 fine, no problems all tests pass. On
>> x86_64 i'm seeing odd behaviour:
>>
>> 1. looks like some sort of corruption in the 'debug' output:
>>
>>    setgetmode  ¦q¦  d   ¦¦         -1     307
>>    stackg  ¦4¦%  7¦  ¦4¦%        -4
>>
>> I know on windows for example this does not happen.  However I can
>> also
>> see this on the prebuilt binaries for x86_64 so I'm wondering if this
>> is
>> just a linux thing.
>>
>> 2. make doc fails with an 'invalid index error' ( i raised bug 14088
>> about this).
>>
>> I finally tracked this down to:
>>
>> a=[]
>> a($)
>>
>> giving an invalid index.  It seems this was working on 5.3.3 but only
>> because the extra checks on empty lists in matext1/2 between 5.5.0
>> -beta1
>> and 5.5.0 were not there.
>>
>> This part of the code is producing the error:
>>
>>            if(
>>        &     stk(sadr(il1+4)).le.0.and.
>>        &     abs(istk(il1)).ne.4.or.
>>        &   (abs(istk(il1)).ne.1.and.
>>        &   abs(istk(il1)).ne.2.and.
>>        &   abs(istk(il1)).ne.4.and.
>>        &   abs(istk(il1)).ne.129)) then
>>               call error(21)
>>               return
>>            endif
>>
>>
>> so for some reason stk(sadr(il1+4)) is giving a negative number for
>> a($).  If I add the type check for 2 and 129 to the first part of the
>> expression it succeeds.
>>
>>
>> 3. IEEEcompatibility test fails.
>>
>> This is due to number_properties('denorm') returning F.  I've tried
>> fiddling with the build properties of lapack to remove optimisation
>> etc
>> without success.
>>
>>
>> So i'm thinking overall there's something odd about this build, but I
>> cant for the life of me think what.  Some things i've tried:
>>
>> Using a different kernel
>> Freshly built gcc 5.2.0 with no patches
>> Updating a gcc
>> Rebuilding lapack (3.5) with various options removed
>> Rebuilding glibc with most of our patches and optimisation levels
>> removed
>> Rebuilding scilab with no optimisation
>>
>> The fact that this happens on both our platforms (2014.2 has gcc
>> 4.8/glibc 2.19 and dev has gcc 5.2/glibc 2.22) is odd...
>>
>> Any suggestions?
>>
>> thanks
>> cris.
>>
>> _______________________________________________
>> dev mailing list
>> dev at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/dev
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev