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 > [email protected] > http://lists.scilab.org/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.scilab.org/mailman/listinfo/dev
