On 12/01/2017 03:40 AM, Robert Yang wrote:
So I don't think that it is worth to use malloc here, the similar to 2 3 5.
And we had used a few similar ways to fix this kinds of issues before.
Okay, that's fair. If there is an upper limit defined somewhere else
(kernel, glibc) and upstream
Hi Alexander,
On 11/30/2017 07:33 PM, Alexander Kanavin wrote:
On 11/30/2017 03:45 AM, Robert Yang wrote:
+- char buf[4096];
++ char buf[8192];
I understand it would take more time, but the proper way to fix this (and
similar issues in patches 2, 3, 5) is to use dynamic allocation.
On 11/30/2017 03:45 AM, Robert Yang wrote:
+- char buf[4096];
++ char buf[8192];
I understand it would take more time, but the proper way to fix this
(and similar issues in patches 2, 3, 5) is to use dynamic allocation.
Swapping one arbitrary value for another arbitrary value may
The buf is used for saving PATH, 4096 is a little small when building in deep
path, for example, it would be failed when oe-coe's len(TMPDIR) == 410, use
8192 can fix the problem.
Fixed:
$ bitbake go-native
[snip]
gcc -isystem/workspace2/lyang1//[snip]
exec gcc: No such file or directory
