Backport a patch from upstream to take care of build failure e.g.
| ../deps/v8/src/codegen/arm/cpu-arm.cc:38:16: error: write to reserved register 'R7'
| asm volatile("svc 0\n"
| ^
| 1 error generated.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Use system brotli via PACKAGECONFIG by default. So far,
nodejs had been built using its embedded copy of brotli,
which we generally try to avoid, for the known reasons
(independent updates, cve & license checks, etc).
The nodejs patches to enable this have been submitted.
brotli is in meta-oe, so enabling this by default should
not be a problem.
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
There are so many useful modules written for node.js I would like to use in
C++/Qt projects.
Run-tested both variants by installing node-red with npm and running it.
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This overrides yocto-provided build flags with its own, e.g we get
arm-poky-linux-musleabi-g++ -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 \
... \
-march=armv7-a -mfpu=neon -mfloat-abi=hard -marm
Causing the latter to override the former, and compiler warnings:
cc1plus: warning: switch '-mcpu=cortex-a7' conflicts with '-march=armv7-a' switch
Patch this out, so that yocto-provided flags take precedence.
Note that in reality the same should probably be done for all the other
supported architectures, too.
Note that this also switches to Thumb(2) mode (in my case). No obvious
problems have been noted during compilation or runtime.
Upstream-Status: Inappropriate [oe-specific]
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
NodeJS comes with an embedded, patched, version of gyp.
Normally, gyp supports compiling for the build machine, e.g.
native tools that need to be compiled to run during the build,
and for the host, using different variables, e.g. CC and
CC.host, etc.
Most of this has been patched out in the NodeJS version of gyp,
and essentially it only supports compiling using one compiler -
${CC}. This modification excludes LDFLAGS for native tools, and
those still evaluate LDFLAGS.host (only).
While this modified behaviour is OK for the OE use-case of building
native and target tools separately, it means that this recipe can
not work as-is with standard gyp, and wrong LDFLAGS are being used
for some of the tools compiled (torque) in either case.
By setting the make variables that gyp-generated makefiles inspect,
we support use of unpatched gyp, and we ensure that all tools
are compiled with correct LDFLAGS in either case.
This now also allows us to drop the patch that had been applied to
work-around this problem.
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
GCC 4.8 compatibility was lost moving from 10.15.1 to 10.15.3. Add
another wrapper for std::make_unique to restore it.
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
- do not drop target LDFLAGS
- even if the target LDFLAGS have been specified, tools like torque was
linked with system libraries
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
- replace all occurrences of std::make_unique with wrapper
- sync indent level
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Update nodejs to active 10.x LTS release 10.15.1.
- link atomic library
- make it compatible with gcc < 4.9
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Remove old nodejs4_0.4.12 and update nodejs_0.12.7 to the latest stable
nodejs_4.2.3.
Nodejs is picky about which architectures it supports. The supported arch
mapping required some updating to bring it up to date with the current nodejs
code. Add COMPATIBLE_MACHINE entries so it only builds for the supported
architectures.
ARM cores that don't support at least VFP2 have been dropped:
https://groups.google.com/forum/#!topic/v8-users/aSOFbaAQvMk
"Due the increasing cost of the keeping the "no-VFPv2" port of V8 working
on ARM, we are planning on making 3.17 the last V8 release that that
supports ARM chips without VFPv2. Starting with the 3.18 release, the
minimal V8 requirements will increase to ARMv6 + VFPv2. In order to
simplify maintenance, we will also remove the "pre-VFP2" ARM code from the
V8 code base."
Additionally, gcc no longer supports a VFPv2 option:
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-mfpu-1460
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
