[PROBLEM SOLVED] Distcc Help
#1
I want to enable AppArmor on 4.4.77-rockchip-ayufan-136 on Rock64.  To do that, I need to compile into kernel two more lines:
Code:
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_DEFAULT_SECURITY_APPARMOR=y

For learning purpose, I use distcc this time.  It will also enhances the usability of Rock64 if (test) compile of kernel can be a bit easier job.
For easy execution, I freshly build a Stretch VM on PC as distcc helper.  Because
1. it has exactly the same gcc --version as of the 136build : "gcc (Debian 6.3.0-18+deb9u1)"
2. no firewall on both VM and Rock64

I follow exactly the recipes here
https://github.com/ayufan-rock64/linux-b...-distcc.md
but things do not happen magically.

When running "top" on the VM, one or two "distcc" blinks shortly on the list around every 5 mins.
The /var/log/distccd.log consists a long list of
Code:
distccd[399] (dcc_job_summary) client: 192.168.0.52:54524 COMPILE_ERROR exit:1 sig:0 core:0 ret:0 time:412ms cc drivers/base/devcoredump.c

While on the terminal to Rock64 where I fired
Code:
make -j 9 CC=distcc
it is fluid with
Code:
distcc[32589] (dcc_build_somewhere) Warning: failed to distribute, running locally instead

Can I conclude that network connection is established but something else is wrong?  Or, there is still some permission issues or what?

Or there is some compiler-related outstanding settings on the VM to fulfill the magic?
(gentoo and some other tutorials do quite some soft-link for gcc,..,g++;  not on the recipe here.)
When I run gcc -v, VM shows Target: x86_64-linux-gnu on VM, while Rock64 shows Target: aarch64-linux-gnu.  Do I need to align them, or output of gcc -v does not matter here?  If I do, what exactly should I do?  Run on VM a "export CROSS_COMPILES=??" or what?

Or, what else should I look into?

Thanks for your help.
  Reply
#2
Seems that I should not include CC=distcc in the "make -j9" command because of the /etc/environment.  However, when I run merely "make -j9", things get from bad to worse.  Not a single sign of distcc-in-use is observed on both Rock64 & the distcc helper VM.
- Output of 'top' at VM shows no "distcc".
- The progress on the terminal where I fire "make -j9" shows no distcc activity.
- I added to /etc/environment
Code:
DISTCC_VERBOSE=1
DISTCC_LOG=/tmp/distcc.log
I can see /tmp/distcc.log is created but nothing is logged (except the very first line when it is created).

I can see those DISTCC CC CXX variables when I run printenv.  But they are just being ignored by "make".

How can I enforce the /etc/environment to be applied?
Or, what can be stopping it from being used?
Any idea?

Thanks

edit-----------------------
/tmp/distcc.log begin to work after a reboot
  Reply
#3
Be fair, Rock64 is perfect for NAS, and that's all.  I have a 1G board running 7x24 since the first week I received it.  Absolutely no complain.

Back to distcc, unless there is a bug somewhere confounding the result, I always need to include CC=distcc in "make -j 9 CC=distcc" to make distcc run and get the /tmp/distcc.log to read.  Could it be the reason why the recipes here avoid this part?

I have tried in /etc/environment
CC="ccache aarch64-linux-gnu-gcc"
CC="ccache arm-linux-gnueabi-gcc"
CC="ccache arm-linux-gnueabihf-gcc" (not on recipe, I make it, just in case, no harm to do one more test anyway)
(with their g++ counterpart of course)
What I see on the /tmp/distcc.log is mostly
Code:
(dcc_scan_args) gcc's -x handling is complex ; running locally

I had no problem running Gentoo distcc on my PC(vm) to help compile kernel for my eeepc901 years ago.  Doing similar thing here is a nightmare.

I know ayufan has been doing a remarkable job here, otherwise I will not have USB3.0 and gigalan for my NAS.  Thanks ayufan for that.  On the other hand, frankly, his github pages have not help me to solve a single problem in the last 10 weeks.  It only portray a beautiful picture that you can achieve a lot of things with rock64.  I did get some useful tips from this forum.

I hope Rock64 will has an extensively long life cycle so that it's development can has chance to reach a more mature status. Angel

Problem is solved because I give up.  Enable apparmor is the last thing I want to do on my NAS.  Dare not to expect HDMI issues will be resolved soon.

Good Lucks Gentlemen
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Rock64 Debian 11 (Bullseye) install problem jbize 15 7,963 10-12-2023, 05:14 PM
Last Post: tpaul
  External hard drive problem k8Va 17 22,156 03-09-2021, 02:31 PM
Last Post: calinb
  Arch Linux Arm - external RTC problem max 1 2,906 08-17-2020, 10:35 AM
Last Post: max
  Read-only problem mikedhoore 5 6,730 07-14-2020, 11:41 AM
Last Post: zein
  Display limited to 800x600 [SOLVED] Averell 16 18,321 06-05-2020, 11:07 PM
Last Post: ab1jx
Question bluetooth rock64 problem deta 3 4,957 05-06-2020, 11:29 PM
Last Post: deta
  Fedora 31 crosscompilation fdt problem mimics debian 888789 kf5zmi 2 4,076 01-20-2020, 12:25 PM
Last Post: kf5zmi
Question [SOLVED] Alpine Linux won't boot rock7 1 5,674 10-22-2019, 04:30 PM
Last Post: rock7
  ROCK64 Kernel compilation problem cao 0 2,427 01-21-2019, 01:21 AM
Last Post: cao
Lightbulb Wifi problem Nether494 13 17,153 11-28-2018, 01:48 PM
Last Post: Nether494

Forum Jump:


Users browsing this thread: 1 Guest(s)