On Thu, Mar 26, 2020 at 04:36:52PM -0400, Jacob Stiffler wrote:
>
> On 3/26/2020 3:18 PM, Denys Dmytriyenko wrote:
> >On Fri, Mar 06, 2020 at 09:53:46AM -0500, Jacob Stiffler wrote:
> >>On 3/5/2020 7:15 PM, Denys Dmytriyenko wrote:
> >>>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?
> >>This is something we want because it is required to make use of other
> >>standard model namespaces, such as OpcUaDi (device integration) and others.
> >>I can move this to the PACKAGECONFIG so it is more easily configured, but
> >>eventually we will need to determine how to make this work in our builds.
> >Jake,
> >
> >Any more updates on this one?
> >Unfortunately, the old version now breaks on master with this error:
> >cc1: error: unrecognized command line option ‘-Wno-static-in-inline’
> >[-Werror]
> >
> >And I started looking into this update again, but it's taking a very-very
> >long
> >time even when lto is disabled...
>
>
> I was waiting for a response or confirmation on the PACKAGECONFIG approach.
> I have noticed some variation in the build times, and it seems that it may
> be related to the toolchain. It seems that nativesdk builds much faster than
> target, but I haven't experimented enough to be sure. If it sounds OK, I can
> move the NAMESPACE_ZERO to a PACKAGECONFIG nad leave it disabled by default.
Yes, please, if that fixes the build issues.
--
Denys
_______________________________________________
meta-arago mailing list
[email protected]
http://arago-project.org/cgi-bin/mailman/listinfo/meta-arago
