[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: minGW 'make check' errors

From: Rik
Subject: Re: minGW 'make check' errors
Date: Mon, 04 Nov 2013 13:58:21 -0800

On 11/04/2013 12:54 PM, John W. Eaton wrote:
> On 11/03/2013 02:32 PM, Rik wrote:
>> 11/3/13
>> This bug report details some errors which apparently only appear on the
>> minGW system (https://savannah.gnu.org/bugs/?32036).
> Here is what I currently see with a cross build for Windows.  I used
> hg id 573f865aa8c8 for Octave and 7a7d2318ca93+ for mxe-octave (the
> only changes were for the version number and sha1sum of the tar
> file in src/octave.mk).
>   Summary:
>     PASS     11417
>     FAIL        18
>     XFAIL        7
>     SKIPPED     48
> The large number of skipped tests are because I disabled the JIT
> compiler and I don't seem to have Java.  I thought building with Java
> was fixed for Windows cross compiling?  If that is supposed to be
> working, then I need to find out why it is not for me.

Do you truly have Java installed on the Windows side?  For WIN32 targets
the java virtual machine is found at runtime rather than compile time.  I
can see from the tests that HAVE_JAVA is defined so Octave was created with
java enabled and ready to go, but the error message indicates it didn't
find the key in the registry that it was looking for.

The search for jvm.dll is in initialize_jvm in ov-java.cc.  The registry
key is "software\\javasoft\\java runtime environment".
> In the attached fntests.log file I only see 14 failures compared to
> the 18 listed in the summary.  I don't know what's causing that.  The
> counts of skipped tests and expected failures seems to be correct.
The count is correct.  14 failures are due to %!test blocks with the line
"test failed", and 4 are due to %!error blocks with the line "error
failed".  Your grep was probably only looking for "test failed".
> One troubling failure is the one for sort.  Why would sort not be
> stable for complex values on Windows?
> Also the quadgk failure looks bad because it could indicate a
> numerical problem.
> The failure due to missing ghostscript needs to be fixed by somehow
> including ghostscript in the distribution.  Cross compiling it doesn't
> seem to be easy to do.
> I don't expect the group and password functions to work.
> Should umask work?
I doubt it.  Windows has cacls for changing access control lists, but it is
still pretty different from umask.  We should probably disable the umask
tests when on a WIN32 platform which is not Cygwin.

There is a failure in popen2.  I'm not sure how easy that would be to fix.

The failures in assert seem to be down to the printf forcing an extra '0'
into exponential format.  "1e-16" is always "1e-016".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]