search

iocane / unbox

GPL licensed J interpreter
Other
37 stars 7 forks source link

Build fails on ARM #6

Open hoosierEE opened 8 years ago

hoosierEE commented 8 years ago

What I did:

  1. $ git clone https://github.com/iocane/unbox.git
  2. $ cd unbox
  3. $ tup

Many errors of the same type happen when tup gets to the file src/libj/x15.c, right before an #if SY_WIN32 section.

Here's an example of the error:

src/libj/x15.c:845:1: error: initializer element is not constant
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&cb9};
 ^
src/libj/x15.c:845:1: error: (near initialization for 'cbv[0]')
src/libj/x15.c:845:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&cb9};
                         ^
src/libj/x15.c:845:1: error: initializer element is not constant
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&cb9};
 ^
src/libj/x15.c:845:1: error: (near initialization for 'cbv[1]')
src/libj/x15.c:845:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&

Errors for cbv[2] through cbv[8] elided for brevity here. Last few lines of output:

src/libj/x15.c:857:1: error: initializer element is not constant
 I static cbvx[]={(I)&cbx0,(I)&cbx1,(I)&cbx2,(I)&cbx3,(I)&cbx4,(I)&cbx5,(I)&cbx6,(I)&cbx7,(I)&cbx8,(I)&cbx9};
 ^
src/libj/x15.c:857:1: error: (near initialization for 'cbvx[9]')
 *** tup errors ***
 *** Command ID=858 failed with return value 1
tup error: Expected to write to file 'build/x15.o' from cmd 858 but didn't
 *** Additionally, command 858 failed to process input dependencies. These should probably be fixed before addressing the command failure.
 [ETA~=7s  ]  11%
 *** tup: 1 job failed.

Here's some info about my system. For what it's worth, I use the "raspi" version of the official J804 release.

$ uname -a
Linux localhost 3.8.11 #1 SMP Wed Jan 6 19:59:47 PST 2016 armv7l armv7l armv7l GNU/Linux
$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 48.00
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc0f
CPU revision    : 4

processor       : 1
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 48.00
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc0f
CPU revision    : 4

Hardware        : SAMSUNG EXYNOS5 (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000
iocane commented 8 years ago

Hi, Alex. Would you mind testing again with the develop branch. The new J source release from J Software which I merged in might fix this. Once I dig my Raspberry Pi out of the closet I'll include an arm build in my testing and add the binary to the release.

hoosierEE commented 8 years ago

I'll test the develop branch on ARM tonight. Just tested on OSX, see #8. For future reference, should I do all new-system testing on the develop branch?

iocane commented 8 years ago

Definitely do new-system testing in the develop branch at least until the next tagged release because of the system configuration changes in js.h from the J Software release.

hoosierEE commented 8 years ago

Tested on develop, no change.