haiwen / seafile-rpi

Seafile server package for Raspberry Pi.
Other
559 stars 89 forks source link

running on arm64 architecture #36

Closed unDocUMeantIt closed 5 years ago

unDocUMeantIt commented 5 years ago

i understand this binary package is copiled for armhf, am i correct?

i recently installed seafile server 6.3.4 on a nanopi M4 running armbian, which is a arm64 distribution. the installation of seafile itself was a bit of a rough ride; e.g., the ccnet-init binary failed with an error that the file didn't exist, and i figured that was because of a missing 32 bit environment. in case anyone is reading this because google pointed you here in an attempt to solve the same issue, this is what worked for me:

sudo dpkg --add-architecture armhf
sudo apt install libc6:armhf libselinux1:armhf libssl1.1:armhf libstdc++6:armhf

so far so good, installation was successful and the server software runs like a charm.

however, i came to notice there's tons of warnings in the system log files like these:

[30564.167369] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca0
[30564.167382] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca8
[30564.167396] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca0
[30564.167406] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca8
[30564.167417] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca0
[30564.167426] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca8
[30564.167437] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca0
[30564.167446] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca8
[30564.167458] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca0
[30564.167467] "seaf-server" (1799) uses deprecated CP15 Barrier instruction at 0xf6f4cca8
[30574.474537] cp15barrier_handler: 60 callbacks suppressed
[30574.474554] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c278
[30574.474567] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c294
[30574.474579] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c2a4
[30574.474591] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c278
[30574.474601] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c294
[30574.474619] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c2a4
[30574.474628] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c278
[30574.474638] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0c294
[30574.474647] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0bca0
[30574.474656] "seafile-control" (1724) uses deprecated CP15 Barrier instruction at 0xf6e0bca8
[30584.480686] cp15barrier_handler: 36 callbacks suppressed

i figured this is also due to the fact that the binaries were built for a 32 bit environment. is there anything i can do about this, except compiling from source?

of course, in the long run, it would be great if there was also a arm64 build. i wouldn't be surprised if devices like the M4 became more popular soon (e.g., support for multiple harddrives at real SATA speed, so RAID is possible, which is a godsend for running services like seafile).

jobenvil commented 5 years ago

I agree, try in the Seafile Forum to rise the arm64 question. Since I don't have possibility to compile for arm64.

unDocUMeantIt commented 5 years ago

assuming you're running a 64 bit linux operating system on your desktop machine, you should be able to crosscompile for arm64 in a chroot (e.g., with the help of crossbuild-essential-arm64 on debian based distros).

jobenvil commented 5 years ago

My compiling environment is a ARMv7 environment, not 64 at all and no intention to build up a vm for that. Just enough switching my ARMv7 with the old ARMv6, for compiling with jessie and ARMv6.

unDocUMeantIt commented 5 years ago

for the time being, it looks like i was able to work around the issue by enabling cp15_barrier support.

temporarily:

echo 2 | sudo tee /proc/sys/abi/cp15_barrier

permanently (e.g., survive a reboot):

echo "abi.cp15_barrier = 2" | sudo tee --append /etc/sysctl.conf
jobenvil commented 5 years ago

I will notice it and if somebody asks, I will refer to your 32 bit environment findings. Thanks a lot for sharing :-)

burnbabyburn commented 5 years ago

Have a look here: https://forum.seafile.com/t/compilation-arm64-done/6170/35

GioF71 commented 9 months ago

Also is there any particular reason for not using Libreelec which seems to be still supporting S905? https://libreelec.tv/downloads/amlogic/