[Scilab-Dev] 64-bit build oddness

Clément David clement.david at scilab-enterprises.com
Tue Aug 25 14:30:46 CEST 2015


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



More information about the dev mailing list