Build failure on arm

[ViralBShah]

Openlibm fails to build on powerpc and arm. Failure is in compiling s_fma.c.

https://buildd.debian.org/status/package.php?p=julia&suite=sid

[Keno]

Do we have access to any machines with these architectures?

[ViralBShah]

I have requested @sebastien-villemot to see if logins are possible.

I think we should separate out Faddeeva and AMOS from openlibm, and keep it to just being a libm implementation. That way, Julia can then have a USE_SYSTEM_LIBM build option, which can be used on non x86 architectures.

In any case, it would be nice to make openlibm work on the other architectures.

[pao]

I have a Raspberry Pi I can check ARM on, but I'm away from it for a couple of weeks.

[ViralBShah]

Would be great if you can try to build julia on ARM when you get to it.

[pao]

I'll need to set up a cross-compilation environment for a full build, but suspect I won't have enough RAM to run Julia if I do and we get lucky. I have a first run Pi with only 256 MB RAM.

[riegaz]

I tried to build Julia from source on my raspberry. Everything looks good until it comes to openblas. It tells that "This arch/CPU is not supported by OpenBLAS". Any ideas how to solve this?

[ViralBShah]

You need to build reference BLAS for now and link it with system blas etc.

[ViralBShah]

@riegaz The openblas project has now released an arm version.

[nalimilan]

I also get a build failure when building the Fedora RPM package on arm7hl. Looks like x86 instructions have slipped in the build (maybe I've done something wrong). http://kojipkgs.fedoraproject.org//work/tasks/6329/6506329/build.log

[cfusting]

Failing on the Beaglebone Black (ARM):

gcc  -fno-gnu89-inline -std=c99 -Wall -O3 -I/root/openlibm -I/root/openlibm/include -I/root/openlibm/ld80 -I/root/openlibm/arm -I/root/openlibm/src -DASSEMBLER -D__BSD_VISIBLE -Wno-implicit-function-declaration -fPIC  -c src/s_fma.c -o src/s_fma.c.o
/tmp/ccJyrmWe.s: Assembler messages:
/tmp/ccJyrmWe.s:40: Error: bad instruction `fnstcw [sp,#6]'
/tmp/ccJyrmWe.s:49: Error: bad instruction `fldcw [sp,#6]'
/tmp/ccJyrmWe.s:59: Error: bad instruction `stmxcsr [sp,#0]'
/tmp/ccJyrmWe.s:68: Error: bad instruction `ldmxcsr [sp,#0]'
/tmp/ccJyrmWe.s:149: Error: bad instruction `fnstcw [sp,#46]'
/tmp/ccJyrmWe.s:171: Error: bad instruction `fnstcw [sp,#46]'
/tmp/ccJyrmWe.s:179: Error: bad instruction `fldcw [sp,#46]'
/tmp/ccJyrmWe.s:311: Error: bad instruction `stmxcsr [sp,#40]'
/tmp/ccJyrmWe.s:319: Error: bad instruction `ldmxcsr [sp,#40]'

[vtjnash]

I don't know what else you'll run into, but this should get you started:

diff --git a/arm/fenv.h b/arm/fenv.h
index 3421b8f..22bd396 100644
--- a/arm/fenv.h
+++ b/arm/fenv.h
@@ -29,7 +29,7 @@
 #ifndef        _FENV_H_
 #define        _FENV_H_

-#include <sys/_types.h>
+#include <sys/types.h>

 #ifndef        __fenv_static
 #define        __fenv_static   static
diff --git a/include/fenv.h b/include/fenv.h
index f60bc0d..7643c07 100644
--- a/include/fenv.h
+++ b/include/fenv.h
@@ -1,5 +1 @@
-#ifdef __LP64
-#include "../amd64/fenv.h"
-#else
-#include "../i387/fenv.h"
-#endif
+#include "../arm/fenv.h"

Alternatively, you can just link julia against the system libm and skip building openlibm for now

[ViralBShah]

I would suggest simply using USE_SYSTEM_LIBM=1 and getting everything compiling first.

[ihnorton]

This is what I used last time I tried this: https://github.com/ihnorton/julia/compare/arm-make

The base system built ok (note: using llvm-svn), but failed in bootstrap.

[cfusting]

Make is still attempting to build openlibm. I have created the following Make.user file in the project root. Perhaps I am configuring something incorrectly?

USE_SYSTEM_LIBM=1
LDFLAGS=-Wl,-rpath /lib/arm-linux-gnueabihf

[ViralBShah]

Can you try with override? Alternately, try it on the command line with make USE_SYSTEM_LIBM=1. I checked the Makefiles, and it should not be trying to build openlibm.

override USE_SYSTEM_LIBM = 1

[ihnorton]

see JuliaLang/julia@67e55d6

[talex5]

I get this on Ubuntu 14.04/arm32, after applying vtjnash's patch (above):

# make
gcc  -fno-gnu89-inline -std=c99 -Wall -O3 -I/root/openlibm -I/root/openlibm/include -I/root/openlibm/ld80 -I/root/openlibm/arm -I/root/openlibm/src -DASSEMBLER -D__BSD_VISIBLE -Wno-implicit-function-declaration -fPIC  -c src/s_fmaxl.c -o src/s_fmaxl.c.o
src/s_fmaxl.c: In function 'fmaxl':
src/s_fmaxl.c:37:19: error: array type has incomplete element type
  union IEEEl2bits u[2];
           ^
src/s_fmaxl.c:37:19: warning: unused variable 'u' [-Wunused-variable]

[ihnorton]

@talex5 see JuliaLang/julia#3134 (comment)

[talex5]

Removing all support for "long double" (which is just the same as "double" on ARM) fixed it for me:

https://github.com/talex5/openlibm/commits/arm-hacks

Note that I'm not actually trying to run Julia; I'm using it as the libm for an OCaml/Mirage unikernel.

[nalimilan]

@talex5 Are you saying this code should be removed because double and long double are guaranteed to always be the same on ARM? Why was the code written in the first place? ;-)

[talex5]

The comment in Make.files says:

If long double != double use these; otherwise, we alias the double versions.

Since OCaml never uses long doubles anyway, this is fine for me. If you want to support 80-bit doubles on platforms with no native support, I guess you'd need to do more work.

[talex5]

So, is removing long double support on ARM the correct solution?

BTW, you don't need ARM hardware to debug this problem. You can just install an ARM cross-compiler (e.g. arm-linux-gnueabihf-gcc) and build with that.

[nalimilan]

@talex5 So with this PR merged openlibm build on/for ARM for you? I'll give it a try then. Do the tests pass?

[talex5]

It builds. I tried running test-double, and many tests fail with:

Exception "Invalid operation" set

[talex5]

With the test for exceptions disabled and llrint calls removed (they make it hang), the output of test-double on ARM is:

testing double (without inline functions)
Failure: Test: expm1 (1) == M_El - 1.0
Result:
 is:          1.71828182845904531284e+00   0x1.b7e151628aed30000000p+0
 should be:   1.71828182845904509080e+00   0x1.b7e151628aed20000000p+0
 difference:  2.22044604925031308085e-16   0x1.00000000000000000000p-52
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `expm1'
 is      :  1.0000 ulp
 accepted:  0.0000 ulp

Test suite completed:
  1092 test cases plus 935 tests for exception flags executed.
  2 errors occurred.

[nalimilan]

OK, so it looks not too far! :-)

[ViralBShah]

Builds on arm now, and powerpc is not a target of interest at this point!

[nalimilan]

On Fedora arm the build works, but tests all fail with "Exception "Invalid operation" set". Any ideas? https://kojipkgs.fedoraproject.org//work/tasks/7049/8297049/build.log

[ViralBShah]

The failures may have to do with the long double and complex support I added yesterday. Let's keep this issue open. I also have an arm Chromebook.

I can set things up for people to login to it for testing and generally helping with the arm ports.

[nalimilan]

@ViralBShah Actually this build is using version 0.4, so it cannot be related with your changes from yesterday.

[nalimilan]

And the result with 0.4.1 is very similar:
https://kojipkgs.fedoraproject.org//work/tasks/632/8300632/build.log

[ViralBShah]

@talex5 Is it fair to close this that openlibm works on ARM? @nalimilan reported some errors, but that URL is no longer valid. I suggest opening a new issue for specific breakages.

[talex5]

@ViralBShah It build on ARM (and seems to work), but there are some failures in the unit tests, as reported above, so you might want to open a new issue for that. You can see the errors just by enabling the ARM tests in the Travis script and pushing to a new branch so it runs them.

[ViralBShah]

Good idea. Best to have a separate issue for various failing tests on different architectures and compilers.