From: Denys Dmytriyenko <denys@ti.com>
To: Jacob Stiffler <j-stiffler@ti.com>
Cc: meta-arago@arago-project.org
Subject: Re: [zeus/master][PATCH] open62541: upgrade to version 1.0.1, other fixes
Date: Thu, 5 Mar 2020 19:15:14 -0500 [thread overview]
Message-ID: <20200306001514.GQ1628@beryl> (raw)
In-Reply-To: <2a366adf-a32e-a1a2-3d8d-0a206b0f339e@ti.com>
On Thu, Mar 05, 2020 at 04:49:05PM -0500, Jacob Stiffler wrote:
>
> On 3/5/2020 4:24 PM, Denys Dmytriyenko wrote:
> >Jake,
> >
> >Somehow this update has a really hard time getting built - it failed in the
> >same place with what looks like an our-of-memory error:
> >
> >| src_generated/open62541/namespace0_generated.c: In function ‘namespace0_generated’:
> >| src_generated/open62541/namespace0_generated.c:113178:15: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without
> >| 113178 | UA_StatusCode namespace0_generated(UA_Server *server) {
> >| | ^
> >| arm-none-linux-gnueabihf-gcc: fatal error: Killed signal terminated program lto1
> >| compilation terminated.
> >| lto-wrapper: fatal error: /opt/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf/bin/arm-none-linux-gnueabihf-gcc returned 1 exit status
> >| compilation terminated.
> >| /opt/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf/bin/../lib/gcc/arm-none-linux-gnueabihf/9.2.1/../../../../arm-none-linux-gnueabihf/bin/ld: error: lto-wrapper failed
> >
> >It was not specific to any platform or a build node - all platforms on all
> >build nodes have failed. I had to revert the update for now, as I needed to
> >release rc3 very quickly.
> >
> >Has this been tested? Any comments?
>
> I have built this for both am57xx-evm and am65xx-evm and nativesdk. I have
> also run-time tested this on x86 and am65x IDK.
>
> I did not ice that it took a significantly longer time to build with this
> update and noticed "lto1-ltrans" as the top hog of resources. I have only
> noticed this within OE. I do not notice any performance difference in the
> standalone build.
>
> I suspect this may be a result of enabling UA_NAMESPACE_ZERO=FULL, but I do
> not know why this is isolated to OE.
Thanks. Is it possible to disable UA_NAMESPACE_ZERO=FULL to see if it improves
the build resource demands? Is it one of the required features to be enabled?
--
Denys
next prev parent reply other threads:[~2020-03-06 0:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 21:45 [zeus/master][PATCH] open62541: upgrade to version 1.0.1, other fixes Jacob Stiffler
2020-03-05 21:24 ` Denys Dmytriyenko
2020-03-05 21:49 ` Jacob Stiffler
2020-03-06 0:15 ` Denys Dmytriyenko [this message]
2020-03-06 14:53 ` Jacob Stiffler
2020-03-26 19:18 ` Denys Dmytriyenko
2020-03-26 20:36 ` Jacob Stiffler
2020-03-26 23:57 ` Denys Dmytriyenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200306001514.GQ1628@beryl \
--to=denys@ti.com \
--cc=j-stiffler@ti.com \
--cc=meta-arago@arago-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.