[PROBLEM SOLVED] Distcc Help

[cooker]

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.

[cooker]

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

[cooker]

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.

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