Cross-compiling for ARMv6 #10488

schwarzwalder93 · 2015-03-12T11:23:44Z

I am trying to cross-build Julia for ARMv6 with arm-buildroot-linux-uclibcgnueabi toolchain on a Intel-PC(x86) as a build machine.

What are the Makefile config parameters to be changed for such a cross-compilation ?

nalimilan · 2015-03-12T12:42:08Z

GitHub issues are not for questions, but for bug reports. I see you have also sent a message to the julia-dev mailing list, thus I'm closing this issue in favor of the latter. If you find actionable items that deserve a bug report, feel free to reopen it.

ViralBShah · 2015-03-12T12:50:39Z

I guess this is kind of an issue in the sense that we may need to figure out if this works, and if so, document it. In general, we do not have cross-compilation instructions.

ihnorton · 2015-03-12T14:40:00Z

There are cross-compile instructions in the windows readme. However,
bootstrapping the cross-compile binary requires Wine on linux. Maybe that
step could be run under QEMU user mode..

I guess this is kind of an issue in the sense that we may need to figure
out if this works, and if so, document it. Do we have cross-compilation
instructions?

—
Reply to this email directly or view it on GitHub
#10488 (comment).

tkelman · 2015-03-12T21:43:14Z

set XC_HOST to the prefix, and see what breaks first

schwarzwalder93 · 2015-03-13T15:20:57Z

Here are some of the flags that I modified in Make.inc for the cross-compile:
OPENBLAS_TARGET_ARCH=ARMV6
OPENBLAS_DYNAMIC_ARCH = 1
ARCH=arm
XC_HOST = arm-buildroot-linux-uclibcgnueabi
HOSTCC = gcc
MARCH = armv6

And in deps/Makefile:
CONFIGURE_COMMON += --host=arm-buildroot-linux-uclibcgnueabi --target=arm-buildroot-linux-uclibcgnueabi

Now,its picking up the arm-buildroot-linux-uclibcgnueabi toolchain successfully.

I got errors in Tests/Checks target recipe for a few dependencies(Obvious,its testing the libs and exes on x86 platform),so I disabled them in makefiles.
LLVM build is not picking arm-buildroot-linux-uclibcgnueabi-strip instead it picks build machines stip and so llvm-install fails.How to resolve that ?
After skipping llvm-install,build breaks at FFTW, below is the log details

Making all in support
Making all in kernel
Making all in simd-support
Making all in dft
Making all in scalar
Making all in codelets
Making all in simd
Making all in common
Making all in sse2
Making all in avx
Making all in altivec
Making all in neon
libtool: compile: arm-buildroot-linux-uclibcgnueabi-gcc -march=armv6 -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../kernel -I../../../dft -I../../../dft/simd -I../../../simd-support -mfpu=neon -O3 -fomit-frame-pointer -fstrict-aliasing -fno-schedule-insns -ffast-math -MT n1fv_2.lo -MD -MP -MF .deps/n1fv_2.Tpo -c n1fv_2.c -fPIC -DPIC -o .libs/n1fv_2.o
In file included from ../../../dft/simd/n1f.h:21:0,
from ../common/n1fv_2.c:71,
from n1fv_2.c:3:
../../../simd-support/simd-neon.h:33:2: error: #error "compiling simd-neon.h requires -mfpu=neon or equivalent"
#error "compiling simd-neon.h requires -mfpu=neon or equivalent"
^
In file included from ../../../simd-support/simd-neon.h:36:0,
from ../../../dft/simd/n1f.h:21,
from ../common/n1fv_2.c:71,
from n1fv_2.c:3:
/home/vish/work/ssdk/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.8.3/include/arm_neon.h:32:2: error: #error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h
#error You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h
^
In file included from ../../../dft/simd/n1f.h:21:0,
from ../common/n1fv_2.c:71,
from n1fv_2.c:3:
../../../simd-support/simd-neon.h:40:1: error: unknown type name 'float32x4_t'
typedef float32x4_t V;
^
../../../simd-support/simd-neon.h: In function 'LDA':
../../../simd-support/simd-neon.h:78:6: warning: implicit declaration of function 'vld1q_f32' [-Wimplicit-function-declaration]
return vld1q_f32((const float32_t *)x);
^
../../../simd-support/simd-neon.h:78:6: error: unknown type name 'float32_t'
../../../simd-support/simd-neon.h: In function 'LD':
../../../simd-support/simd-neon.h:84:6: warning: implicit declaration of function 'vcombine_f32' [-Wimplicit-function-declaration]
return vcombine_f32(vld1_f32((float32_t *)x), vld1_f32((float32_t *)(x + ivs)));
^
../../../simd-support/simd-neon.h:84:6: warning: implicit declaration of function 'vld1_f32' [-Wimplicit-function-declaration]
../../../simd-support/simd-neon.h:84:36: error: 'float32_t' undeclared (first use in this function)
return vcombine_f32(vld1_f32((float32_t *)x), vld1_f32((float32_t *)(x + ivs)));
^
../../../simd-support/simd-neon.h:84:36: note: each undeclared identifier is reported only once for each function it appears in
../../../simd-support/simd-neon.h:84:47: error: expected expression before ')' token
return vcombine_f32(vld1_f32((float32_t *)x), vld1_f32((float32_t *)(x + ivs)));
^
../../../simd-support/simd-neon.h:84:73: error: expected expression before ')' token
return vcombine_f32(vld1_f32((float32_t *)x), vld1_f32((float32_t *)(x + ivs)));
^
../../../simd-support/simd-neon.h: In function 'STA':
../../../simd-support/simd-neon.h:90:6: warning: implicit declaration of function 'vst1q_f32' [-Wimplicit-function-declaration]

Looks like some flags are missing in fftw configure,I tried adding but couldn't resolve..

ViralBShah · 2015-03-13T15:26:37Z

I would just do USE_SYSTEM_FFTW=1, since we have some known trouble with FFTW on ARM.

ViralBShah · 2015-03-13T15:28:29Z

@staticfloat Do you think we can have nightly dev PPAs for arm? They don't yet pass all tests, but people want to experiment - and this would be generally useful. Also, I am wondering if we should cross build for arm on travis and run a simple test suite just to get things started.

staticfloat · 2015-03-13T17:32:02Z

I enabled armhf a while back, but it appears the builds have been hanging because I was requiring patchelf for the build process. This is not available on ARM, so I've disabled it and we'll see how things go.

ViralBShah · 2015-03-13T18:43:50Z

@staticfloat Should we continue the PPA nightlies discussion in #8359 ?

@vishnusuganth Can you submit a PR? Many of these things can go into the existing ARM.inc, and can be enabled with a flag like make CROSS_COMPILE=1. This will generally be useful.

schwarzwalder93 · 2015-03-14T15:16:49Z

@ViralBShah If I enable "USE_SYSTEM_XXX=1" flag ,should I build those libraries separately and add the path of the libXXX.so to LDFLAGS ?

ViralBShah · 2015-03-14T15:44:08Z

Usually, you would have them provided by the system - through apt-get or something similar. If they are on the system path, the julia build will pick them up.

ViralBShah · 2015-03-14T15:46:04Z

The other way to get around this is probably to remove the mention of --enable-neon in deps/Make.inc. There are other issues with FFTW and neon even if this builds:

FFTW/fftw3#30

schwarzwalder93 · 2015-03-14T15:56:43Z

I am trying to port Julia into an embedded system which has no access to internet or whatsoever and I am pretty sure it does not have any of Julia dependencies in it already.

staticfloat · 2015-03-14T20:37:05Z

@vishnusuganth if you manually build dependencies separately, you will need to install them into a place where the Julia build process can find them. Examples that are searched by default are places like /usr/local, where libraries will get put into /usr/local/lib, headers into /usr/local/include, etc... If you decide to put things in a different location, such as ~/local, which is not searched by default, you'll need to communicate to Julia where those files are. This will involve including -I~/local/include in CPPFLAGS, -L~/local/lib in LDFLAGS, and adding ~/local/lib to LD_LIBRARY_PATH, in the case of shared libraries that Julia or other dependencies might need in order to startup.

schwarzwalder93 · 2015-03-16T08:41:23Z

@ViralBShah I skipped FFTW and continued the build.It broke at this point with some error.

CC src/support/strtod.o
In file included from libsupport.h:10:0,
from strtod.c:2:
utils.h:76:0: warning: "bswap_16" redefined [enabled by default]
#define bswap_16(x) (((x) & 0x00ff) << 8 | ((x) & 0xff00) >> 8)
^
In file included from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
from libsupport.h:6,
from strtod.c:2:
/home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:30:0: note: this is the location of the previous definition
#define bswap_16(x) __bswap_16 (x)
^
In file included from libsupport.h:10:0,
from strtod.c:2:
utils.h:81:0: warning: "bswap_32" redefined [enabled by default]
#define bswap_32(x)
^
In file included from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
from libsupport.h:6,
from strtod.c:2:
/home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:33:0: note: this is the location of the previous definition
#define bswap_32(x) __bswap_32 (x)
^
In file included from libsupport.h:10:0,
from strtod.c:2:
utils.h:97:0: warning: "bswap_64" redefined [enabled by default]
#define bswap_64(x) ByteSwap64(x)
^
In file included from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
from /home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
from libsupport.h:6,
from strtod.c:2:
/home/vish/work/ssdk/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:37:0: note: this is the location of the previous definition

define bswap_64(x) __bswap_64 (x)

^
strtod.c:19:1: error: unknown type name 'locale_t'
static locale_t c_locale;
^
strtod.c:21:1: error: unknown type name 'locale_t'
locale_t get_c_locale()
^
strtod.c: In function 'get_c_locale':
strtod.c:26:5: warning: implicit declaration of function 'newlocale' [-Wimplicit-function-declaration]
c_locale = newlocale(LC_ALL_MASK, "C", NULL);
^
strtod.c:26:26: error: 'LC_ALL_MASK' undeclared (first use in this function)
c_locale = newlocale(LC_ALL_MASK, "C", NULL);
^
strtod.c:26:26: note: each undeclared identifier is reported only once for each function it appears in
strtod.c: In function 'strtod_c':
strtod.c:33:3: warning: implicit declaration of function 'strtod_l' [-Wimplicit-function-declaration]
return strtod_l(nptr, endptr, get_c_locale());
^
strtod.c: In function 'strtof_c':
strtod.c:38:3: warning: implicit declaration of function 'strtof_l' [-Wimplicit-function-declaration]
return strtof_l(nptr, endptr, get_c_locale());
^
Makefile:43: recipe for target '/home/vish/work/julia5/src/support/strtod.o' failed
make[2]: *** [/home/vish/work/julia5/src/support/strtod.o] Error 1
Makefile:79: recipe for target 'support/libsupport.a' failed
make[1]: *** [support/libsupport.a] Error 2
Makefile:76: recipe for target 'julia-src-release' failed

ViralBShah · 2015-03-16T08:49:47Z

This is perhaps some ARMV6 peculiarity that doesn't materialize on ARMV7 that we have tested on so far.

Cc: @ihnorton

ViralBShah · 2015-03-16T08:50:36Z

Seems more of a peculiarity of the embedded linux than ARMV6 - perhaps a missing header or something.

schwarzwalder93 · 2015-03-16T11:27:57Z

I replaced #if !defined(OS_WINDOWS) in strtod.c with #ifdef USE_XLOCALE and continued the build.
But I get a new error related to Flisp

`make`
**/home/vish/work/julia5/usr/bin/llvm-config: 1: /home/vish/work/julia5/usr/bin/llvm-config: Syntax error: word unexpected (expecting ")")**
   `CC src/jltypes.o
In file included from support/libsupport.h:10:0,
                 from julia.h:10,
                 from jltypes.c:13:
support/utils.h:76:0: warning: "bswap_16" redefined [enabled by default]
 #define bswap_16(x) (((x) & 0x00ff) << 8 | ((x) & 0xff00) >> 8)
 ^
In file included from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
                 from jltypes.c:7:
/home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:30:0: note: this is the location of the previous definition
 #define bswap_16(x) __bswap_16 (x)
 ^
In file included from support/libsupport.h:10:0,
                 from julia.h:10,
                 from jltypes.c:13:
support/utils.h:81:0: warning: "bswap_32" redefined [enabled by default]
 #define bswap_32(x) \
 ^
In file included from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
                 from jltypes.c:7:
/home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:33:0: note: this is the location of the previous definition
 #define bswap_32(x) __bswap_32 (x)
 ^
In file included from support/libsupport.h:10:0,
                 from julia.h:10,
                 from jltypes.c:13:
support/utils.h:97:0: warning: "bswap_64" redefined [enabled by default]
 #define bswap_64(x) ByteSwap64(x)
 ^
In file included from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
                 from jltypes.c:7:
/home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:37:0: note: this is the location of the previous definition
 # define bswap_64(x) __bswap_64 (x)
 ^
/home/vish/work/julia5/usr/bin/llvm-config: 1: /home/vish/work/julia5/usr/bin/llvm-config: Syntax error: word unexpected (expecting ")")
    CC src/gf.o
In file included from support/libsupport.h:10:0,
                 from julia.h:10,
                 from gf.c:15:
support/utils.h:76:0: warning: "bswap_16" redefined [enabled by default]
 #define bswap_16(x) (((x) & 0x00ff) << 8 | ((x) & 0xff00) >> 8)
 ^
In file included from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
                 from gf.c:9:
/home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:30:0: note: this is the location of the previous definition
 #define bswap_16(x) __bswap_16 (x)
 ^
In file included from support/libsupport.h:10:0,
                 from julia.h:10,
                 from gf.c:15:
support/utils.h:81:0: warning: "bswap_32" redefined [enabled by default]
 #define bswap_32(x) \
 ^
In file included from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
                 from gf.c:9:
/home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:33:0: note: this is the location of the previous definition
 #define bswap_32(x) __bswap_32 (x)
 ^
In file included from support/libsupport.h:10:0,
                 from julia.h:10,
                 from gf.c:15:
support/utils.h:97:0: warning: "bswap_64" redefined [enabled by default]
 #define bswap_64(x) ByteSwap64(x)
 ^
In file included from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/endian.h:61:0,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/waitstatus.h:65,
                 from /home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdlib.h:45,
                 from gf.c:9:
/home/vish/work/ssdk-/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/byteswap.h:37:0: note: this is the location of the previous definition
 # define bswap_64(x) __bswap_64 (x)`
**FLISP src/julia_flisp.boot
./flisp/flisp: 1: ./flisp/flisp: Syntax error: word unexpected (expecting ")")**
`Makefile:72: recipe for target 'julia_flisp.boot' failed
make[1]: *** [julia_flisp.boot] Error 2
Makefile:76: recipe for target 'julia-src-release' failed
make: *** [julia-src-release] Error 2`

[pao: quoting]

tkelman · 2015-03-16T14:24:39Z

llvm-config and flisp are binaries that get built for the host architecture, so this is where cross-compiling is going to hit trouble. Is there a way, perhaps via qemu, that you can execute arm-compiled binaries on the build system?

schwarzwalder93 · 2015-03-16T14:44:02Z

@tkelman Yea I get it.I will try it and give an update.....Btw,I have few doubts.

Will julia-src use any of the llvm/clang compiler for its build process ? or does it use gcc ?
While building julia-deps I could see the config.log file for each dependencies to know which toolchain and triplet it has picked during the build process.Is there any such log file for julia-src building process tracking ?

tkelman · 2015-03-16T14:53:53Z

Will julia-src use any of the llvm/clang compiler for its build process ? or does it use gcc ?

Depends what you ask for. On Linux the default is gcc. With XC_HOST set I'm pretty sure the suffixed cross-compiler names always end in gcc, g++, gfortran. But we need to link to various llvm libraries when we create libjulia which contains the JIT compiler, and the link commands are currently obtained by running llvm-config. There's a later system image bootstrap process to precompile Julia's standard library which requires running the compiled julia binary, that will be using the linked host LLVM compiler from Julia code. Cross-building this part could get really complicated.

Is there any such log file for julia-src building process tracking ?

No, we don't use autotools for base Julia. We may eventually switch from hand-written makefiles to CMake, but that's probably a long way off. You can set VERBOSE=1 either on the make invocation command-line, or in a file Make.user created at the top level source checkout, to see the full compilation commands that get used for Julia's C source.

vtjnash · 2015-03-17T03:58:58Z

If I was to buy an ARM computer to be able to look into these issues better, is there some platform that is better than another for that purpose? RasPi, RasPi2, BeagleBones, or such?

schwarzwalder93 · 2015-03-17T10:44:13Z

Meanwhile,could anyone help me to solve this error ?
@staticfloat @ViralBShah

/home/vish/work/julia5/deps/llvm-3.5.1/autoconf/mkinstalldirs /home/vish/work/julia5/usr/lib llvm[3]: Installing Release+Asserts Archive Library /home/vish/work/julia5/usr/lib/libLLVMTableGen.a /home/vish/work/julia5/deps/llvm-3.5.1/autoconf/mkinstalldirs /home/vish/work/julia5/usr/lib /usr/bin/install -c /home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts/Release+Asserts/lib/libLLVMTableGen.a /home/vish/work/julia5/usr/lib/libLLVMTableGen.a make[3]: Leaving directory '/home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts/lib/TableGen' make[3]: Entering directory '/home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts/utils' \ SD=/home/vish/work/julia5/deps/llvm-3.5.1/utils/FileCheck; \ DD=FileCheck; \ if [ ! -f $SD/Makefile ]; then \ SD=FileCheck; \ DD=FileCheck; \ fi; \ if ([ ! -f $DD/Makefile ] || \ command test $DD/Makefile -ot \ $SD/Makefile ); then \ /home/vish/work/julia5/deps/llvm-3.5.1/autoconf/mkinstalldirs $DD; \ /bin/cp $SD/Makefile $DD/Makefile; \ fi; \ make -C $DD install make[4]: Entering directory '/home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts/utils/FileCheck'
llvm[4]: Installing Release+Asserts /home/vish/work/julia5/usr/bin/arm-buildroot-linux-uclibcgnueabi-FileCheck
/home/vish/work/julia5/deps/llvm-3.5.1/autoconf/mkinstalldirs /home/vish/work/julia5/usr/bin
/usr/bin/install -c -s -m 0755 /home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts/Release+Asserts/bin/FileCheck /home/vish/work/julia5/usr/bin/arm-buildroot-linux-uclibcgnueabi-FileCheck
strip: Unable to recognise the format of the input file /home/vish/work/julia5/usr/bin/arm-buildroot-linux-uclibcgnueabi-FileCheck
/usr/bin/install: strip process terminated abnormally
/home/vish/work/julia5/deps/llvm-3.5.1/Makefile.rules:1465: recipe for target /home/vish/work/julia5/usr/bin/arm-buildroot-linux-uclibcgnueabi-FileCheck failed make[4]: *** [/home/vish/work/julia5/usr/bin/arm-buildroot-linux-uclibcgnueabi-FileCheck] Error 1 make[4]: Leaving directory '/home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts/utils/FileCheck /home/vish/work/julia5/deps/llvm-3.5.1/Makefile.rules:937: recipe for target 'FileCheck/.makeinstall' failed make[3]: *** [FileCheck/.makeinstall] Error 2 make[3]: Leaving directory '/home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts/utils' /home/vish/work/julia5/deps/llvm-3.5.1/Makefile.rules:878: recipe for target 'install' failed make[2]: *** [install] Error 1 make[2]: Leaving directory '/home/vish/work/julia5/deps/llvm-3.5.1/build_Release+Asserts' Makefile:545: recipe for target '/home/vish/work/julia5/usr/lib/libLLVMCodeGen.a' failed make[1]: *** [/home/vish/work/julia5/usr/lib/libLLVMCodeGen.a] Error 2 make[1]: Leaving directory '/home/vish/work/julia5/deps' Makefile:67: recipe for target 'julia-deps' failed make: *** [julia-deps] Error 2

tkelman · 2015-03-17T10:49:41Z

looks like llvm might be trying to use the x86 strip instead of arm-buildroot-linux-uclibcgnueabi-strip?

schwarzwalder93 · 2015-03-17T10:58:12Z

All other deps are using arm-buildroot-linux-uclibcgnueabi-strip! Why aint LLVM picking it ?

tkelman · 2015-03-17T11:00:17Z

Dunno, something wrong in their autotools, or the way we're calling them maybe?

ihnorton · 2015-03-19T17:19:22Z

Well they do work for the cross compile we officially support (Windows). Pull requests are welcome! I've tried this last night and ran in to several similar issues, the biggest ones being libuv's IPv6 dependency (not available in the toolchain I was using), and the fact that LLVM's install target assumes it is running on host. Using binfmts with qemu could help there but I didn't get the config correct yet.

tkelman · 2015-03-19T17:22:54Z

Well they do work for the cross compile we officially support (Windows).

Except that the new GC doesn't work under wine last I checked, but that's beside the point.

Definitely worth patching a few places to make this easier, when XC_HOST is set and/or BUILD_OS is different than OS.

schwarzwalder93 · 2015-03-20T05:28:30Z

@nalimilan I dint go that far.Since I had problems with sysimg bootstrap.
I meant the "tests" & "install" done for the Julia dependencies.

schwarzwalder93 · 2015-03-20T08:45:55Z

@ViralBShah
Aint it should be something like this
CFLAGS= -march=$(MARCH)
CXXFLAGS= -march=$(MARCH)
rather than
https://github.com/JuliaLang/julia/blob/master/Make.inc#L444-L446 ?

ViralBShah · 2015-03-20T13:54:18Z

Does it matter? CLAGS and CXXFLAGS are reserved for the user.

tkelman · 2015-03-20T13:55:30Z

Appending flags like that to CC and CXX does cause all sorts of problems and we should reorganize things so we stop doing that, but I'm also not sure we send CFLAGS and CXXFLAGS to every single dependency or every file in src

ViralBShah · 2015-03-20T13:57:37Z

We certainly do not send CFLAGS and CXXFLAGs to every dependency.

schwarzwalder93 · 2015-03-20T14:06:09Z

Any idea about this ?

/home/vish/work/julia6/usr/lib/libjulia.so: undefined reference to del_curterm' /home/vish/work/julia6/usr/lib/libjulia.so: undefined reference totigetnum'
/home/vish/work/julia6/usr/lib/libjulia.so: undefined reference to compress2' /home/vish/work/julia6/usr/lib/libjulia.so: undefined reference tocrc32'
/home/vish/work/julia6/usr/lib/libjulia.so: undefined reference to setupterm' /home/vish/work/julia6/usr/lib/libjulia.so: undefined reference tocompressBound'
/home/vish/work/julia6/usr/lib/libjulia.so: undefined reference to uncompress' /home/vish/work/julia6/usr/lib/libjulia.so: undefined reference toset_curterm'
collect2: error: ld returned 1 exit status
Makefile:74: recipe for target '/home/vish/work/julia6/usr/bin/julia' failed
make[1]: *** [/home/vish/work/julia6/usr/bin/julia] Error 1
make[1]: Leaving directory '/home/vish/work/julia6/ui'
Makefile:79: recipe for target 'julia-ui-release' failed
make: *** [julia-ui-release] Error 2

ViralBShah · 2015-03-20T14:19:37Z

Seems like you need to install ncurses-dev or something.

schwarzwalder93 · 2015-03-20T15:03:07Z

@ViralBShah Thanks.I solved that.
I tried rebuilding again with LLVM_FLAGS=--with-cpu=arm1136jf-s --with-float=soft --with-abi=aapcs-vfp --with-fpu=vfp
But still it breaks the same way! :(

make[1]: Leaving directory '/home/vish/work/julia6/base'
make[1]: Entering directory '/home/vish/work/julia6'
cd base && qemu-arm -L /home/vish/work/ssdk-a5n2/target/ /home/vish/work/julia6/usr/bin/julia -C arm1136jf-s --build /home/vish/work/julia6/usr/lib/julia/sys0 sysimg.jl
exports.jl
base.jl
reflection.jl
build_h.jl
version_git.jl
c.jl
options.jl
promotion.jl
tuple.jl
range.jl
expr.jl
error.jl
bool.jl
number.jl
int.jl
operators.jl
pointer.jl
refpointer.jl
rounding.jl
float.jl
LLVM ERROR: Program used external function 'fmaf' which could not be resolved!
Makefile:168: recipe for target '/home/vish/work/julia6/usr/lib/julia/sys0.o' failed
make[1]: *** [/home/vish/work/julia6/usr/lib/julia/sys0.o] Error 1
make[1]: Leaving directory '/home/vish/work/julia6'
Makefile:82: recipe for target 'julia-sysimg-release' failed
make: *** [julia-sysimg-release] Error 2

ViralBShah · 2015-03-20T15:06:37Z

Since you are not using USE_SYSTEM_LIBM right now, perhaps try with that instead. You may want to clean out the old sys.* files. I think there is some other bug elsewhere.

pao · 2015-03-20T15:58:09Z

--with-float=soft

--with-float=soft will force software FP, which you don't want; though --with-fpu might override it? And to be clear, I was looking at the GCC flags for ARM; the LLVM flags should be similar but you should refer to its documentation.

schwarzwalder93 · 2015-03-20T16:33:02Z

I have not cross-compiled LIBM for my target separately and also the target
has no internet access to download LIBM.
So I don't think I can try with USE_SYSTEM_LIBM=1
On Mar 20, 2015 8:36 PM, "Viral B. Shah" notifications@github.com wrote:

Since you are not using USE_SYSTEM_LIBM right now, perhaps try with that
instead. You may want to clean out the old sys.* files. I think there is
some other bug elsewhere.

—
Reply to this email directly or view it on GitHub
#10488 (comment).

schwarzwalder93 · 2015-03-20T16:47:46Z

@pao The LLVM_FLAGS are used in the llvm ./configure script. But when I
checked with "./configure --help" I couldn't see
"--with-cpu,--with-fpu,--with-float" options at all. So just confused with
where it's even getting used !
So after referring the ARM GCC documentation I just changed my CC to be
CC += -march=armv6 -cpu=arm1136jf-s -with-float=soft -fpu=vfp
And similarly for CXX

But still same error! I guess there is a bug at some other point
On Mar 20, 2015 9:28 PM, "pao" notifications@github.com wrote:

--with-float=soft

--with-float=soft will force software FP, which you don't want; though
--with-fpu might override it? And to be clear, I was looking at the GCC
flags for ARM; the LLVM flags should be similar but you should refer to its
documentation.

—
Reply to this email directly or view it on GitHub
#10488 (comment).

pao · 2015-03-20T16:58:06Z

There are two separate issues that are here, which is causing some confusion:

LLVM is configured in such a way that it produces instructions while compiling Julia code which are not allowed on the target system. That is what everyone except for me is addressing.
Julia and its dependencies need to be compiled in such a way that they will run on the target system correctly. That is what I am addressing, and why we suggested pulling that conversation off of this issue and over to the mailing list (as it is not an issue with Julia).

schwarzwalder93 · 2015-03-20T17:52:25Z

Yea fine . We could discuss there. Not a problem. But I have already sent a
message earlier to dev-mailing group but I dint get any response unlike
here.
On Mar 20, 2015 10:28 PM, "pao" notifications@github.com wrote:

There are two separate issues that are here, which is causing some
confusion:

LLVM is configured in such a way that it produces instructions
while compiling Julia code which are not allowed on the target system. That
is what everyone except for me is addressing.

Julia and its dependencies need to be compiled in such a way that
they will run on the target system correctly. That is what I am addressing,
and why we suggested pulling that conversation off of this issue and over
to the mailing list (as it is not an issue with Julia).

—
Reply to this email directly or view it on GitHub
#10488 (comment).

pao · 2015-03-20T21:02:06Z

Could you please link to that thread, @vishnusuganth?

schwarzwalder93 · 2015-03-21T02:59:07Z

https://groups.google.com/forum/m/?hl=en#!topic/julia-dev/EL7dwdF1Cds
On Mar 21, 2015 2:32 AM, "pao" notifications@github.com wrote:

Could you please link to that thread, @vishnusuganth
https://github.com/vishnusuganth?

—
Reply to this email directly or view it on GitHub
#10488 (comment).

vtjnash · 2015-03-21T18:28:20Z

If I was to buy an ARM computer to be able to look into these issues better, is there some platform that is better than another for that purpose? RasPi, RasPi2, BeagleBones, or such?

I wouldn't bother with the original RPi at this point, unless you're specifically interested in the ARMv6 architecture. I suspect you'll be happier with a faster system though. I'd recommend either the ODROID-U3, which is pretty snappy, or at a significantly higher price point, the NVIDIA Jetson TK1. The BeagleBone Black is by all accounts a great board, but for Julia development I'd take the faster ODROID, since you won't be using the I/O. Similar story for the RPi2.

those do look like impressive specs, which would be nice. once i got julia working, my next step would likely seem to be making julia interact with the I/O, so the dev boards seem better for that. but maybe i should just collect them all; it's not like they are very expensive.

ViralBShah · 2015-03-22T10:08:46Z

I have been using a Samsung Chromebook for ARM testing, which has worked out quite well, and Julia starts up just fine on it.

ViralBShah · 2015-03-22T10:29:38Z

What doesn't work is make dist and running julia from the resulting tarball crashes. Haven't debugged that yet.

schwarzwalder93 · 2015-03-27T13:37:36Z

@pao I have a working LLVM/Clang for my target (ARMv6) after cross-compilation
I followed these steps.I dint specify any other configure flags apart from host & target triplet.
http://bgamari.github.io/posts/2011-10-17-crosscompiling_llvm.html

Is there any way to run the sysimg bootstrap alone on my target now ? Will that be meaningful ? Sorry I am not much aware of this sysimg bootstrap process

pao · 2015-03-27T16:42:22Z

I have a working LLVM/Clang for my target (ARMv6) after cross-compilation
I followed these steps.I dint specify any other configure flags apart from host & target triplet.

That should be fine; the additional flags are tuning. I'm not sure what the state of the art is on running the bootstrap--someone else will need to chime in on that.

vtjnash · 2015-04-29T02:41:49Z

#10488 (comment)

that should be one of the processors supported natively by llvm (http://llvm.org/docs/doxygen/html/Host_8cpp_source.html#l00647)

unfortunately, that list is extremely small. and some of the information it maps to is invalid/incomplete (in the ProcessorModel list in lib/Targets/ARM/ARM.td)

there are mind-boggling number of configuration options (-mapi, -mfpu, -mfloat-abi https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/ARM-Options.html). it might be possible to put together a tool to help the user (and codegen.cpp/ llvm) pick the right combination (for example, following the info on https://wiki.debian.org/ArmEabiPort), esp. in the 'generic' (MARCH='native') case, and esp wrt. to '+(-)neon' and '+(-)vfp'

ViralBShah · 2015-04-29T04:06:42Z

It seems like we should have a conservative set of defaults that are likely to work for most common use cases. Is it fair to say that targeting generic with vfpv4 for FP and disabling Neon should work for the Raspberry Pis and Odroid boards that people are using here?

ViralBShah · 2015-04-29T04:07:21Z

Interestingly, the llvm ARM binaries seem to be doing something along those lines, since people have reported success building julia with those.

vtjnash · 2015-04-29T04:15:55Z

'generic(hard-float)+vfp' and 'generic(hard-float)-vfp' are the most conservative options (which would also disable neon, and uses the aapcs abi). it is necessary to provide both (they are not compatible). it's maybe unlikely anyone is trying to run julia on a 'generic(soft-float)-vfp' machine, but that would be a third, common, incompatible option. most of the other calling conventions are special-purpose or old -- i'm not even sure if llvm supports all of them.

ViralBShah · 2015-05-13T04:11:16Z

I believe #10917 should fix this. The CPU used there arm1176jzf-s. Please reopen if it does not.

ViralBShah added the building Build system, or building Julia or its dependencies label Mar 12, 2015

nalimilan closed this as completed Mar 12, 2015

ViralBShah added the system:arm ARMv7 and AArch64 label Mar 14, 2015

ViralBShah reopened this Mar 16, 2015

sbromberger mentioned this issue Apr 13, 2015

ARM build failing during bootstrap on Raspberry Pi 2 #10235

Closed

ViralBShah closed this as completed May 13, 2015

Cross-compiling for ARMv6 #10488

Cross-compiling for ARMv6 #10488

Comments

schwarzwalder93 commented Mar 12, 2015

nalimilan commented Mar 12, 2015

ViralBShah commented Mar 12, 2015

ihnorton commented Mar 12, 2015

tkelman commented Mar 12, 2015

schwarzwalder93 commented Mar 13, 2015

ViralBShah commented Mar 13, 2015

ViralBShah commented Mar 13, 2015

staticfloat commented Mar 13, 2015

ViralBShah commented Mar 13, 2015

schwarzwalder93 commented Mar 14, 2015

ViralBShah commented Mar 14, 2015

ViralBShah commented Mar 14, 2015

schwarzwalder93 commented Mar 14, 2015

staticfloat commented Mar 14, 2015

schwarzwalder93 commented Mar 16, 2015

define bswap_64(x) __bswap_64 (x)

ViralBShah commented Mar 16, 2015

ViralBShah commented Mar 16, 2015

schwarzwalder93 commented Mar 16, 2015

tkelman commented Mar 16, 2015

schwarzwalder93 commented Mar 16, 2015

tkelman commented Mar 16, 2015

vtjnash commented Mar 17, 2015

schwarzwalder93 commented Mar 17, 2015

tkelman commented Mar 17, 2015

schwarzwalder93 commented Mar 17, 2015

tkelman commented Mar 17, 2015

ihnorton commented Mar 19, 2015

tkelman commented Mar 19, 2015

schwarzwalder93 commented Mar 20, 2015

schwarzwalder93 commented Mar 20, 2015

ViralBShah commented Mar 20, 2015

tkelman commented Mar 20, 2015

ViralBShah commented Mar 20, 2015

schwarzwalder93 commented Mar 20, 2015

ViralBShah commented Mar 20, 2015

schwarzwalder93 commented Mar 20, 2015

ViralBShah commented Mar 20, 2015

pao commented Mar 20, 2015

schwarzwalder93 commented Mar 20, 2015

schwarzwalder93 commented Mar 20, 2015

pao commented Mar 20, 2015

schwarzwalder93 commented Mar 20, 2015

pao commented Mar 20, 2015

schwarzwalder93 commented Mar 21, 2015

vtjnash commented Mar 21, 2015

ViralBShah commented Mar 22, 2015

ViralBShah commented Mar 22, 2015

schwarzwalder93 commented Mar 27, 2015

pao commented Mar 27, 2015

vtjnash commented Apr 29, 2015

ViralBShah commented Apr 29, 2015

ViralBShah commented Apr 29, 2015

vtjnash commented Apr 29, 2015

ViralBShah commented May 13, 2015