[PROBLEM SOLVED] Distcc Help - Printable Version

[PROBLEM SOLVED] Distcc Help - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: Linux on Rock64 (https://forum.pine64.org/forumdisplay.php?fid=88)
+--- Thread: [PROBLEM SOLVED] Distcc Help (/showthread.php?tid=6017)

[PROBLEM SOLVED] Distcc Help - cooker - 04-30-2018

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-build/blob/master/recipes/configure-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.

RE: Distcc Help - cooker - 05-01-2018

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

RE: Distcc Help - cooker - 05-01-2018

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