Problem compiling Libreelec on RK3399 SBC

Baderks · October 27, 2018 at 7:34 PM

I started experimenting with compiling LibreELEC for my RockPro64 device. All went well using VirtualBox with Linux on my Win10 PC. This time I tried to compile LibreELEC on my RockPro64 SBC. Unfortunately that fails during the compilation of openssl-1.0.2p with the error:

gcc: error: unrecognized command line option '-m64'

I started the make process with the following instruction:

rock64@rockpro64:~/LibreELEC.tv$ PROJECT=Rockchip DEVICE=RK3399 ARCH=arm UBOOT_SYSTEM=rockpro64 make image

To give some extra context I copied the last couple of lines from the compilation process:

Code

make[2]: Entering directory '/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/openssl-1.0.2p/.aarch64-linux-gnu/test'
make[2]: Nothing to be done for 'generate'.
make[2]: Leaving directory '/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/openssl-1.0.2p/.aarch64-linux-gnu/test'
make[1]: Leaving directory '/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/openssl-1.0.2p/.aarch64-linux-gnu'

Configured for linux-x86_64.

*** Because of configuration changes, you MUST do the following before
*** building:

    make depend
Executing (host): make 
make[1]: Entering directory '/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/openssl-1.0.2p/.aarch64-linux-gnu'
making all in crypto...
make[2]: Entering directory '/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/openssl-1.0.2p/.aarch64-linux-gnu/crypto'
/usr/bin/perl ../util/mkbuildinf.pl "/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/toolchain/bin/host-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -Wall -pipe -I/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/toolchain/include -Wno-format-security -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM" "linux-x86_64" >buildinf.h
/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/toolchain/bin/host-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -Wall -pipe -I/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/toolchain/include -Wno-format-security -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM   -c -o cryptlib.o cryptlib.c
gcc: error: unrecognized command line option '-m64'
make[2]: *** [<builtin>: cryptlib.o] Error 1
make[2]: Leaving directory '/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/openssl-1.0.2p/.aarch64-linux-gnu/crypto'
make[1]: *** [Makefile:287: build_crypto] Error 1
make[1]: Leaving directory '/home/rock64/LibreELEC.tv/build.LibreELEC-RK3399.arm-9.0-devel/openssl-1.0.2p/.aarch64-linux-gnu'
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 2

Display More

I looked for solutions on Google, but none of the suggestions were helpful for solving this LibreELEC compilation problem. I can' t believe I am the first one to try to compile LibreELEC on a RK3399 SBC so I hope there is someone out here who can give me the right directions to solve this problem.

TIA, Baderks

**Kwiboo** · October 27, 2018 at 7:46 PM

Building LibreELEC is mainly done on x86_64 hosts and not on the target devices.

I also think some of the rkbin tools used to generate bootloader/u-boot blobs only exists for x86_64.

**chewitt** · October 28, 2018 at 4:45 AM Official Post

Quote from Kwiboo

Building LibreELEC is mainly done on x86_64 hosts and not on the target devices.

I also think some of the rkbin tools used to generate bootloader/u-boot blobs only exists for x86_64.

^ building LibreELEC is *only* done x86_64 hosts

Baderks · October 28, 2018 at 4:28 PM

Quote from Kwiboo

Building LibreELEC is mainly done on x86_64 hosts and not on the target devices.

I also think some of the rkbin tools used to generate bootloader/u-boot blobs only exists for x86_64.

Quote from chewitt

building LibreELEC is *only* done x86_64 hosts

I came to the same conclusion after I solved the compilation problems of openssl-1.0.2p. The compilation process found the next problems with the compilation of the Python 2.7 package. I just removed all of LibreELEC from my RockPro64 SBC.

As arm processors are becoming more and more powerful, I believe that eventually LibreELEC will have to offer support for arm processors as building host for their already very impressive building system. Whether or not having a HOST_TARGET variable will suffice, I do not known. I do know that it will have to be a separate and well organized project, as the dangers of breaking the existing building system are huge.

For me, this subject is closed for the time being.

Baderks

**chewitt** · October 29, 2018 at 1:09 AM Official Post

The ability to compile on the target is fine for distro's like Armbian where you're only ever recompiling the kernel or building a couple of esoteric packages you need for a specific use-case. LibreELEC has ~380 packages and requires approx. 20GB disk space and 6GB RAM minimum to compile an RPi image. An educated guess based on CPU alone is 48 hours to compile an RPi image on an overclocked 3B+ and maybe 36 hours on an RK3399 board. In comparison the 7yr old quad-core i7 chip in my MacBook takes 3.5 hours if sources are pre-cached. That level of time difference guarantees only masochists would ever use the capability (project staff never would). It's a moot point though, because the average 2GB RAM limit on most ARM boards ensures you'd never get a successful build. Some of the packages that come later in the build sequence like *lots* of RAM.

**CvH** · October 29, 2018 at 9:01 AM Official Post

It was tried before and 48h are more likely 2 weeks ;D