Per-package SDK and target directories

I have seen your mail on the buildroot mailing list.
I download your buildroot branch 'ppsh' and test it with my configurations.

Test environment:
when using your buildroot, I will execute the parallel build command 'make -j8'. when using mainstream buildroot, I will execute 'make -j1'.
config?
1\ qemu_x86_defconfig
2\ my_private_configuration(it is ok in mainstream buildroot)

Q1: Compatibility Issues
In qemu_x86_defconfig, mainstream and 'ppsh' is all ok because it is simple.
In my private, if using 'make -j8' in the 'ppsh', there still has the first question as shows in lines 103-116 of the top-level Makefile. i.e.

Quoted 1 line

Quoted 1 line

Quoted 1 line

openssl Configuring

checking whether we are using A... yes(A has been compiled)/no(A has not been compiled)

in mainstream buildroot, the order of package A is before openssl. So openssl is always support A.
but in 'ppsh', openssl is always not support A. if once 'ppsh' is merged into the mainstream, there will cause software inconsistencies.

Q2: Space Expension
in qemu_x86_defconfig, the size of output increased from 3.4G to 3.6G between mainstream with 'ppsh'.
in my private, the rate of space occupancy growth is higher. it`s crazy from 3.6G to 9G .This obviously can not accept. (A large part of reason is that I use a very large toolchain-external which about 1.5G) Before a package only consumes one space, but now a package maybe reoccupied space below per-package.
BEFORE(mainstream):
1.7G ./build
115M ./images
37M ./target
1.8G ./host
3.6G .

NOW('ppsh')

1.7G    ./build
5.5G    ./per-package
115M    ./images

37M ./target
1.8G ./host
8.9G .

Q3: ERROR: Could not generate syscalls.(uclibc_error.log)
I have not solved this problem, I put the error message in the attachment

Q4: Ccache path needs to be fixed(ccache_error.log)
When ccache is enabled, it will generate the 'command not found' error like below.
make: /home/zhulianc/inprogress/orig/tpbuildroot/output/host/bin/ccache: Command not found this issue has been fix.

package/ccache/ccache.mk BR_CCACHE_INITIAL_SETUP = $(call qstrip,$(BR2_CCACHE_INITIAL_SETUP)) · line 56

Quoted 12 lines

package/ccache/ccache.mk +1 -0

index afbec44..66bfcad 100644
@@ -50,6 +50,7 @@ BR_CCACHE_INITIAL_SETUP = $(call qstrip,$(BR2_CCACHE_INITIAL_SETUP))
 ifneq ($(BR_CCACHE_INITIAL_SETUP),)
 define HOST_CCACHE_DO_INITIAL_SETUP
     @$(call MESSAGE,"Applying initial settings")
+    rsync -au --link-dest=$(HOST_DIR) $(HOST_DIR) $(call qstrip,$(BR2_HOST_DIR))
     $(CCACHE) $(BR_CCACHE_INITIAL_SETUP)
     $(CCACHE) -s
 endef

I don't think that's what we want. The global HOST_DIR (output/host) should basically be empty during the entire build process. Instead, what we want is to have the ccache host tools installed in the per-package SDK. This means that all packages have to have a dependency on host-ccache, which is not currently the case. So we probably instead want something like:

ifeq ($(BR2_CCACHE),y)
$(2)_DEPENDENCIES += host-ccache
endif

in package/pkg-generic.mk. But of course, we need to exclude the host-ccache package from this, otherwise we would have a circular dependency. Do you want to try something like this?

Quoted 3 lines

in package/pkg-generic.mk. But of course, we need to exclude the host-ccache package from this, otherwise we would have a circular dependency. Do you want to try something like this?

Ha, I didn't understand the original problem but now I see. The issue is that
ccache is part of DEPENDENCIES_HOST_PREREQ, and DEPENDENCIES_HOST_PREREQ is *not* added to each package's DEPENDENCIES,

instead it is added to the
core-dependencies target and each package depends on that. It's an easy way to avoid circular dependencies, I guess.

So I think the proper solution would be to add DEPENDENCIES_HOST_PREREQ to the
dependencies of all packages except themselves, similar to how it's done for toolchain.

Hello,

Quoted 7 lines · Arnout Vandecappelle

Quoted 3 lines

in package/pkg-generic.mk. But of course, we need to exclude the host-ccache package from this, otherwise we would have a circular dependency. Do you want to try something like this?

Ha, I didn't understand the original problem but now I see. The issue is that
ccache is part of DEPENDENCIES_HOST_PREREQ, and DEPENDENCIES_HOST_PREREQ is *not* added to each package's DEPENDENCIES,

Exactly.

Quoted 4 lines

instead it is added to the
core-dependencies target and each package depends on that. It's an easy way to avoid circular dependencies, I guess.

Quoted 3 lines

So I think the proper solution would be to add DEPENDENCIES_HOST_PREREQ to the
dependencies of all packages except themselves, similar to how it's done for toolchain.

Isn't this DEPENDENCIES_HOST_PREREQ thing a bit crappy in the first place?

Why isn't host-ccache simply added as a dependency of all packages, except itself?

Another example is that today, host-lzip is always built at the beginning of build, even if you're not building any package that needs the lzip "decompressor".

So perhaps this calls for a little bit of rework in this area, no?

By the way there will also be a problem when host-tar is part of
DEPENDENCIES_HOST_PREREQ: ccache needs host-tar to be able to build, but there is no explicit dependency between them, it relies purely on left-to-right order.

package/ccache/ccache.mk BR_CCACHE_INITIAL_SETUP = $(call qstrip,$(BR2_CCACHE_INITIAL_SETUP)) · line 56

Quoted 12 lines

package/ccache/ccache.mk +1 -0

index afbec44..66bfcad 100644
@@ -50,6 +50,7 @@ BR_CCACHE_INITIAL_SETUP = $(call qstrip,$(BR2_CCACHE_INITIAL_SETUP))
 ifneq ($(BR_CCACHE_INITIAL_SETUP),)
 define HOST_CCACHE_DO_INITIAL_SETUP
     @$(call MESSAGE,"Applying initial settings")
+    rsync -au --link-dest=$(HOST_DIR) $(HOST_DIR) $(call qstrip,$(BR2_HOST_DIR))
     $(CCACHE) $(BR_CCACHE_INITIAL_SETUP)
     $(CCACHE) -s
 endef

I don't think that's what we want. The global HOST_DIR (output/host) should basically be empty during the entire build process. Instead, what we want is to have the ccache host tools installed in the per-package SDK. This means that all packages have to have a dependency on host-ccache, which is not currently the case. So we probably instead want something like:

ifeq ($(BR2_CCACHE),y)
$(2)_DEPENDENCIES += host-ccache
endif

in package/pkg-generic.mk. But of course, we need to exclude the host-ccache package from this, otherwise we would have a circular dependency. Do you want to try something like this?

Hello,

Quoted 3 lines

By the way there will also be a problem when host-tar is part of
DEPENDENCIES_HOST_PREREQ: ccache needs host-tar to be able to build, but there is no explicit dependency between them, it relies purely on left-to-right order.

the host-ccache mainly because its directory is defined in the top-level Makefile as below.

453 ifeq ($(BR2_CCACHE),y)
454 CCACHE := $(HOST_DIR)/bin/ccache
455 BR_CACHE_DIR ?= $(call qstrip,$(BR2_CCACHE_DIR)) 456 export BR_CACHE_DIR
457 HOSTCC := $(CCACHE) $(HOSTCC)
458 HOSTCXX := $(CCACHE) $(HOSTCXX)

459 else
460 export BR_NO_CCACHE
461 endif

In the top Makefile, $(CCACHE) is defined as 'output/host/bin/ccache'. So during the compilation process, the $(CCACHE) will do not be found.

In fact, its real location is in output/per-package/host-ccache/host/bin/ccache. The path to host-tar is not defined in top Makefile, So host-tar did not report the same error.

Hello,

On Tue, 7 Nov 2017 11:48:17 +0000, Chu, Zhuliang (NSB - CN/Shanghai) wrote:

Quoted 2 lines

I have seen your mail on the buildroot mailing list.
I download your buildroot branch 'ppsh' and test it with my configurations.

First of all, thanks a lot for taking the time to test my patches and reporting the issues. It is very, very useful feedback, so many thanks!

Unfortunately, your e-mail was too large to make it to the mailing list, due to the huge attached file you had. Next time, it would be better if you could upload the log file somewhere, and just give a link in your e-mail.

See below my replies for the different issues your report.

Quoted 3 lines

in mainstream buildroot, the order of package A is before openssl. So openssl is always support A.
but in 'ppsh', openssl is always not support A. if once 'ppsh' is merged into the mainstream, there will cause software inconsistencies.

I don't understand this problem. Which "package A" are you referring to ? Could you describe in more details the problem you're seeing?

Which tool (and options) have you used to calculate this size?

Indeed, we are using hardlinks, so files are not duplicated. Only files that are overwritten get de-duplicated. Could you investigate this a bit more, checking first if the tool you use to calculate the size properly accounts for hard links ?

Hello Thomas Petazzoni, All,

Quoted 4 lines

Hello,

On Tue, 7 Nov 2017 11:48:17 +0000, Chu, Zhuliang (NSB - CN/Shanghai) wrote:

Quoted 5 lines

Quoted 2 lines

in mainstream buildroot, the order of package A is before openssl. So openssl is always support A.
but in 'ppsh', openssl is always not support A. if once 'ppsh' is merged into the mainstream, there will cause software inconsistencies.

I don't understand this problem. Which "package A" are you referring to ? Could you describe in more details the problem you're seeing?

Sorry my introduction is too simple to cause ambiguity in my first email. This issue is only my worries but don`t be verified in my test.

My worries:
When I am a customer, I always use current buildroot.
In current buildroot, the build order guarantee is very import and the order is determined after many times of testing by customer.

Example package 'A', it is not explicitly expressed in openssl`s .mk file. But in current build order, 'A' is before openssl. So in the configuring step of openssl,the openssl will check that 'A' has been installed. So I am sure that the final result is the openssl support 'A'.
If per-package gets to the point where it can be merged and it will be pushed into buildroot mainstream. In customers, they will find the buildroot can be parallel compilation now. They will be very happy to use this feature. So they will use make -j8 instead of 'make -j1'. If they dont explicitly describe the dependency 'A' in openssls .mk file. And now the openssl don`t support 'A'. But this is not expected behavior for customer.

Q1: rsync conflicts
I want to generate this conflicts in testing but this is difficult. So this is also only my worries.
At the same time in parallel compilation, different threads want to modify the same file of a package in different per-package/package directory and modify the content isn`t the same. This will generate conflicts. How to solve this problem?
I.E. thread t1 modify file A in per-package/package/A, t1 want to modify A content from 'TEXT' to 'EXIT'. At the same time, thread t2 also modify A content from 'TEXT' to 'TXXT'.

And I think rsync has enough power to handle such parallel changes in this situation. but after the successful modify there is still problem. for example, rsync make the content as 'TXXT' and this result is suitable thread t2. But the thread t1 wants to 'EXIT'.

I know this probability is minimal. But what should we do if such a conflict arises?

Q2: toolchain HOST_DIR
I use external custom toolchain. 'BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y'
line 66 of pkg-toolchain-external.mk66 in toolchain/toolchain-external/ is 'TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR = $(HOST_DIR)/opt/ext-toolchain '. this $(HOST_DIR) is also 'output/host/' rather than 'output/per-package/....'.

Actually, I checked, and rsync has no protection at all against parallel execution.
E.g. it will first test if a directory exists already and then create it; if another rsync is at the same time creating that directory, one of the directory creations will fail. So all the rsync's into the same (per-package) directory have to be serialised.

Quoted 1 line

I know this probability is minimal. But what should we do if such a conflict arises?

As I said: error out.

Quoted 3 lines

Q2: toolchain HOST_DIR
I use external custom toolchain. 'BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y' line 66 of pkg-toolchain-external.mk66 in toolchain/toolchain-external/

Do you have an actual example of that? The toolchain is just a package, so in all
places where this variable is used, HOST_DIR should expand into output/per-package/.... The except is the definition of TOOLCHAIN_EXTERNAL_BIN, but that was fixed in patch 3/4.

So, for your further testing, can you try without CCACHE and without patches that
attempt to fix it? Thanks to your testing we found out that ccache is problematic, and it will take a bit of time to fix that. As you have noticed, fixing it correctly is not trivial :-)

-----Original Message-----
From: Arnout Vandecappelle [mailto:arnout at mind.be]
Sent: 2017?11?11? 18:37
To: Chu, Zhuliang (NSB - CN/Shanghai) <[email protected]>; Thomas Petazzoni <[email protected]>
Cc: buildroot at uclibc.org; yann.morin.1998 at free.fr; peter at korsgaard.com; patrickdepinguin+buildroot at gmail.com
Subject: Re: [Buildroot] [RFCv1 0/4] Per-package SDK and target directories

Quoted 6 lines · Zhuliang (NSB - CN/Shanghai)

Hello Thomas Petazzoni, All,

Quoted 4 lines

Hello,

On Tue, 7 Nov 2017 11:48:17 +0000, Chu, Zhuliang (NSB - CN/Shanghai) wrote:

[snip]

Quoted 1 line

Quoted 1 line

Quoted 1 line

in mainstream buildroot, the order of package A is before openssl. So openssl is

always support A.

Quoted 1 line

Quoted 1 line

Quoted 1 line

but in 'ppsh', openssl is always not support A. if once 'ppsh' is merged into the

mainstream, there will cause software inconsistencies.

Quoted 10 lines

Quoted 3 lines

I don't understand this problem. Which "package A" are you referring to ? Could you describe in more details the problem you're seeing?

Sorry my introduction is too simple to cause ambiguity in my first email. This issue is only my worries but don`t be verified in my test.

My worries:
When I am a customer, I always use current buildroot.
In current buildroot, the build order guarantee is very import and the order is

determined after many times of testing by customer.

No, we don't guarantee the build order, it just happens to work that way.

Quoted 1 line

Example package 'A', it is not explicitly expressed in openssl`s .mk file. But in

current build order, 'A' is before openssl. So in the configuring step of openssl,the openssl will check that 'A' has been installed. So I am sure that the final result is the openssl support 'A'.

Quoted 1 line

If per-package gets to the point where it can be merged and it will be pushed into

buildroot mainstream. In customers, they will find the buildroot can be parallel compilation now. They will be very happy to use this feature. So they will use make -j8 instead of 'make -j1'. If they dont explicitly describe the dependency 'A' in openssls .mk file. And now the openssl don`t support 'A'. But this is not expected behavior for customer.

If a dependency is not tracked in the .mk file, you can't count on it. Now already it
is possible that the order changes due to other dependencies (e.g. package C gets an optional dependency on openssl in the new Buildroot version, and package C comes alphabetically before package A, then the new Buildroot version will build openssl before package A instead of after.

[snip]

Quoted 2 lines

Q1: rsync conflicts
I want to generate this conflicts in testing but this is difficult. So this is also only

my worries.

Quoted 1 line

At the same time in parallel compilation, different threads want to modify the

same file of a package in different per-package/package directory and modify the content isn`t the same.

Quoted 2 lines

This will generate conflicts. How to solve this problem?
I.E. thread t1 modify file A in per-package/package/A, t1 want to modify A content

from 'TEXT' to 'EXIT'. At the same time, thread t2 also modify A content from 'TEXT' to 'TXXT'.

Yes, this is a problem and potential showstopper. We discussed it at length at the
last BR developer meeting [1]. The conclusion is that we simply cannot support packages that edit existing files in top-level parallel build context - they would have to encode their dependencies explicitly to force a specific build order. To detect how bad the problem is for in-tree packages, Yann posted a series [2] that allows to detect it. The idea is that we will turn that detection into an error when PPS is merged.

Quoted 1 line

And I think rsync has enough power to handle such parallel changes in this situation.

but after the successful modify there is still problem. for example, rsync make the content as 'TXXT' and this result is suitable thread t2. But the thread t1 wants to 'EXIT'.

Actually, I checked, and rsync has no protection at all against parallel execution.
E.g. it will first test if a directory exists already and then create it; if another rsync is at the same time creating that directory, one of the directory creations will fail. So all the rsync's into the same (per-package) directory have to be serialised.

Quoted 1 line

I know this probability is minimal. But what should we do if such a conflict arises?

As I said: error out.

Quoted 3 lines

Q2: toolchain HOST_DIR
I use external custom toolchain. 'BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y' line 66 of pkg-toolchain-external.mk66 in toolchain/toolchain-external/ is

'TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR = $(HOST_DIR)/opt/ext-toolchain '.

Quoted 1 line

this $(HOST_DIR) is also 'output/host/' rather than 'output/per-package/....'.

Do you have an actual example of that? The toolchain is just a package, so in all
places where this variable is used, HOST_DIR should expand into output/per-package/.... The except is the definition of TOOLCHAIN_EXTERNAL_BIN, but that was fixed in patch 3/4.

So, for your further testing, can you try without CCACHE and without patches that
attempt to fix it? Thanks to your testing we found out that ccache is problematic, and it will take a bit of time to fix that. As you have noticed, fixing it correctly is not trivial :-)

Regards,
Arnout

[1] https://elinux.org/Buildroot:DeveloperDaysELCE2017#Top-level_parallel_build
[2] http://patchwork.ozlabs.org/project/buildroot/list/?series=10725

--

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Q3: ERROR: Could not generate syscalls.(uclibc_error.log)
I have not solved this problem, I put the error message in the attachment

Q3: ERROR: Could not generate syscalls.(uclibc_error.log)
I have not solved this problem, I put the error message in the attachment

I have seen your mail on the buildroot mailing list.
I download your buildroot branch 'ppsh' and test it with my configurations. After my test, I will report about 4 problem under below.

Test environment:
when using your buildroot, I will execute the parallel build command 'make -j8'. when using mainstream buildroot, I will execute 'make -j1'.
config?
1\ qemu_x86_defconfig
2\ my_private_configuration(it is ok in mainstream buildroot)

Q1: Compatibility Issues
In qemu_x86_defconfig, mainstream and 'ppsh' is all ok because it is simple.
In my private, if using 'make -j8' in the 'ppsh', there still has the first question as shows in lines 103-116 of the top-level Makefile.
i.e.

Quoted 1 line

Quoted 1 line

Quoted 1 line

openssl Configuring

checking whether we are using A... yes(A has been compiled)/no(A has not been compiled)

in mainstream buildroot, the order of package A is before openssl. So openssl is always support A. but in 'ppsh', openssl is always not support A. if once 'ppsh' is merged into the mainstream, there will cause software inconsistencies.

Q2: Space Expension
in qemu_x86_defconfig, the size of output increased from 3.4G to 3.6G between mainstream with 'ppsh'.
in my private, the rate of space occupancy growth is higher. it`s crazy from 3.6G to 9G .This obviously can not accept. (A large part of reason is that I use a very large toolchain-external which about 1.5G)
Before a package only consumes one space, but now a package maybe reoccupied space below per-package. BEFORE(mainstream):
1.7G ./build
115M ./images
37M ./target
1.8G ./host
3.6G .

NOW('ppsh')

1.7G    ./build
5.5G    ./per-package
115M    ./images

37M ./target
1.8G ./host
8.9G .

Q3: ERROR: Could not generate syscalls.(uclibc_error.log)
I have not solved this problem, I put the error message in the attachment

Q4: Ccache path needs to be fixed(ccache_error.log)
When ccache is enabled, it will generate the 'command not found' error like below.
make: /home/zhulianc/inprogress/orig/tpbuildroot/output/host/bin/ccache: Command not found this issue has been fix.

patch(0001-ccache-fix-ccache-HOST_DIR.patch):
-----------------------------------------------------------------------------------
From 2e60c344a47fe64d92b3d29af8143d73802e71c4 Mon Sep 17 00:00:00 2001
From: Zhuliang Chu <[email protected]>
Date: Tue, 7 Nov 2017 19:23:46 +0800
Subject: [PATCH 1/1] ccache: fix ccache HOST_DIR

The ccache binary is located in the per-package directory when ccache is installed. But it is set at '$(HOST_DIR)/usr/bin/ccache' in top-level Makefile as below:
CCACHE := $(HOST_DIR)/usr/bin/ccache

Hello Chu, Zhuliang; All,

On 2017-11-07 11:48 +0000, Chu, Zhuliang (NSB - CN/Shanghai) spake thusly:

Quoted 3 lines

I have seen your mail on the buildroot mailing list.
I download your buildroot branch 'ppsh' and test it with my configurations. After my test, I will report about 4 problem under below.

Thanks for the feedback on this early series, very valuable indeed! :-)

Quoted 7 lines

Test environment:
when using your buildroot, I will execute the parallel build command 'make -j8'. when using mainstream buildroot, I will execute 'make -j1'.
config?
1\ qemu_x86_defconfig
2\ my_private_configuration(it is ok in mainstream buildroot)

Quoted 7 lines

Q1: Compatibility Issues
In qemu_x86_defconfig, mainstream and 'ppsh' is all ok because it is simple.
In my private, if using 'make -j8' in the 'ppsh', there still has the first question as shows in lines 103-116 of the top-level Makefile.
i.e.

Quoted 1 line

Quoted 1 line

Quoted 1 line

openssl Configuring

checking whether we are using A... yes(A has been compiled)/no(A has not been compiled)

This does not look like this is opensl configure messages...

Here, openssl (really, libopenssl nowadays) configure step says things like:

---8<---
Configuring for linux-armv4
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-rc5 [option] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl2 [default] OPENSSL_NO_SSL2 (skip dir)
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir)
no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
IsMK1MF=0
CC =/home/ymorin/dev/buildroot/O/host/bin/arm-linux-gnueabihf-gcc
CFLAG =-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
EX_LIBS =-ldl
CPUID_OBJ =armcap.o armv4cpuid.o
BN_ASM =bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM =
DES_ENC =des_enc.o fcrypt_b.o
AES_ENC =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC =bf_enc.o
CAST_ENC =c_enc.o
RC4_ENC =rc4_enc.o rc4_skey.o
RC5_ENC =rc5_enc.o
MD5_OBJ_ASM =
SHA1_OBJ_ASM =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o RMD160_OBJ_ASM=
CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =ghash-armv4.o ghashv8-armx.o
ENGINES_OBJ =
PROCESSOR =
RANLIB =/home/ymorin/dev/buildroot/O/host/bin/arm-linux-gnueabihf-ranlib
ARFLAGS =
PERL =/usr/bin/perl
THIRTY_TWO_BIT mode
DES_UNROLL used
DES_INT used
BN_LLONG mode
RC4 uses uchar
RC4_CHUNK is unsigned long
BF_PTR used
created directory `include/openssl'
e_os2.h => include/openssl/e_os2.h
making links in crypto...
crypto.h => ../include/openssl/crypto.h
[...]
---8<---

So, I wonder what openssl you are using... :-/

Quoted 3 lines

in mainstream buildroot, the order of package A is before openssl. So openssl is always support A. but in 'ppsh', openssl is always not support A. if once 'ppsh' is merged into the mainstream, there will cause software inconsistencies.

This behavioural change is expected, indeed. Top-level parallel build can no longer guarantee the build order, by the mere fact of being parallel. Whatever currently depends on the build order will indeed be broken once top-level parralel build is merged.

The solution is to correctly express dependencies in the .mk files.

Now, if your 'A' package is not something that is known to buildroot, but changes the way a package known to buildroot behaves, there is not much we in Buildroot can do, unless you submit the 'A' package for inclusion in Buildroot...

Quoted 12 lines

Q2: Space Expension
in qemu_x86_defconfig, the size of output increased from 3.4G to 3.6G between mainstream with 'ppsh'.
in my private, the rate of space occupancy growth is higher. it`s crazy from 3.6G to 9G .This obviously can not accept. (A large part of reason is that I use a very large toolchain-external which about 1.5G)
Before a package only consumes one space, but now a package maybe reoccupied space below per-package. BEFORE(mainstream):
1.7G ./build
115M ./images
37M ./target
1.8G ./host
3.6G .

Quoted 7 lines

NOW('ppsh')

1.7G    ./build
5.5G    ./per-package
115M    ./images

37M ./target
1.8G ./host
8.9G .

As others already stated, in may depend on the tools you use to report the disk usage, but can also depend on the type of filesystem.

What filesystem are you using: ext3/4, btrfs, xfs, other?

What command did you run to come up with those numbers?

Quoted 15 lines

Q3: ERROR: Could not generate syscalls.(uclibc_error.log)
I have not solved this problem, I put the error message in the attachment

Q4: Ccache path needs to be fixed(ccache_error.log)
When ccache is enabled, it will generate the 'command not found' error like below.
make: /home/zhulianc/inprogress/orig/tpbuildroot/output/host/bin/ccache: Command not found this issue has been fix.

patch(0001-ccache-fix-ccache-HOST_DIR.patch):
-----------------------------------------------------------------------------------
From 2e60c344a47fe64d92b3d29af8143d73802e71c4 Mon Sep 17 00:00:00 2001
From: Zhuliang Chu <[email protected]>
Date: Tue, 7 Nov 2017 19:23:46 +0800
Subject: [PATCH 1/1] ccache: fix ccache HOST_DIR

Quoted 3 lines

The ccache binary is located in the per-package directory when ccache is installed. But it is set at '$(HOST_DIR)/usr/bin/ccache' in top-level Makefile as below:
CCACHE := $(HOST_DIR)/usr/bin/ccache

I wonder on what version of Buildroot you applied the patches: we no longer have the usr directory in $(HOST_DIR) now.

So, I wonder what openssl you are using... :-/

Quoted 5 lines

Q2: Space Expension
in qemu_x86_defconfig, the size of output increased from 3.4G to 3.6G between mainstream with 'ppsh'.
in my private, the rate of space occupancy growth is higher. it`s crazy from 3.6G to 9G .This obviously can not accept. (A large part of reason is that I use a very large toolchain-external which about 1.5G)
Before a package only consumes one space, but now a package maybe reoccupied space below per-package.

As others already stated, in may depend on the tools you use to report the disk usage, but can also depend on the type of filesystem.

What filesystem are you using: ext3/4, btrfs, xfs, other?

What command did you run to come up with those numbers?