Attempt to add ARM support #2647
Conversation
Signed-off-by: ossdev <ossdev@puresoftware.com>
Signed-off-by: ossdev <ossdev@puresoftware.com>
xzyfer
force-pushed
the
arm
branch
4 times, most recently
from
c155b57
to
f574be6
Compare
| case 'armv7hf': return '32-bit, ARM'; | ||
| case 'armv8': return '64-bit, ARM'; | ||
| case 'aarch64': return '64-bit, ARM'; | ||
| case 'arm64': return '64-bit, ARM'; |
There was a problem hiding this comment.
Looks like drone wont give us full ARM coverage. See https://docs.drone.io/reference/agent/drone-runner-arch/
There was a problem hiding this comment.
Here, arm means 32 bit and arm64 means 64 bit.
So, it gives full arm coverage.
There was a problem hiding this comment.
Do you know what the distinction is between armv7l, armv7hf, aarch64? I'm not sure how they map to drone.io availability
There was a problem hiding this comment.
So it looks like there's a whole bunch of issues with arm detection. I'm not sure detecting the right binary is every possible.
There was a problem hiding this comment.
Hi @xzyfer
I can understand your problem, it could be a bit tricky to provide support for ARM
As there are 2 categories of ARM machine on the basis of their architecture,
architectures like arm,armv6, armv7, armv7l, armv7hfare 32 bit and
arm64, aarch64, armv8, armv8hf are 64 bit
Releasing the binary for both type, 32 bit and 64 bit will cover all the architectures.
Please, let me know if any more information is required.
There was a problem hiding this comment.
Hi,
So there is a bit of a mix going on here, some of these are node process.arch (arm and arm64) and some of them appear to be the platform descriptions (for example as returned by linux uname).
So armv7l is little endian arm, armv7hf is hard floating point.
OTOH, its gets a bit more confusing for armv8 as that name tends to be used by linux 32-bit compatibility containers (aka running 32-bit armv7 binaries on aarch64/64 bit machine).
xzyfer
force-pushed
the
arm
branch
5 times, most recently
from
54e5dc3
to
dae3b5f
Compare
xzyfer
force-pushed
the
arm
branch
2 times, most recently
from
9e95ea3
to
ac52a44
Compare
|
Are all the 32bit architectures compatible? Will a binary compiled on one
work for all? Ditto for 64bit. This is the root of my problem ATM.
…On Mon., 29 Apr. 2019, 5:24 pm ossdev07, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lib/extensions.js
<#2647 (comment)>:
> @@ -44,6 +44,11 @@ function getHumanArchitecture(arch) {
case 'ia32': return '32-bit';
case 'x86': return '32-bit';
case 'x64': return '64-bit';
+ case 'armv7l': return '32-bit, ARM';
+ case 'armv7hf': return '32-bit, ARM';
+ case 'armv8': return '64-bit, ARM';
+ case 'aarch64': return '64-bit, ARM';
+ case 'arm64': return '64-bit, ARM';
Hi @xzyfer <https://github.com/xzyfer>
I can understand your problem, it could be a bit tricky to provide support
for ARM
As there are 2 categories of ARM machine on the basis of their
architecture,
architectures like arm,armv6, armv7, armv7l, armv7hfare 32 bit and
arm64, aarch64, armv8, armv8hf are 64 bit
Releasing the binary for both type, 32 bit and 64 bit will cover all the
architectures.
Please, let me know if any more information is required.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2647 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAENSWAUXPEMCG7HKXY352LPS2PDHANCNFSM4HIUQU4A>
.
|
|
Yes, the binary compiled for any 32 bit will work for all the 32-bit architectures and same works for 64 bit |
|
@ossdev07, this statement is likely fine for most arm environments at this point, but isn't strictly true. Particularly for older hardware platforms. Hard float little endian 32-bit binaries most definitely won't link/run in a soft float big endian environment. Even javascript passes endianess through, so its a good idea to at least consider that its possible to write javascript code that won't run on a BE arm. Its doubtful that this is a problem for the majority of this code, the only thing I would worry about is the armv8 situation because I'm not convinced that is a 64-bit environment (could be wrong) since it generally indicates a 32-bit aarch32 container on linux. |
|
@xzyfer When can we expect the binary for aarch64 to release? |
|
@xzyfer Any update on the binary release. If any help is required from my side. Please let me know. |
|
@xzyfer Let me know if I could help in any way. |
|
@xzyfer Any update? |
|
@xzyfer Is there any update regarding the release of the binary for the aarch64 platform. It will be really good, to see the release of the binary. If any help is required from my side, please let me know. |
|
It would be useful for me to see this patch merged. @xzyfer : do you have any further feedback? |
|
glad to see the solution on arm board in the future. |
|
Looks like there is a conflict with |
|
The proposed patch would delete the |
|
Travis-CI have announced AArch64 support - which may render this patch redundant? |
|
Latest work in #2783 |
|
@xzyfer, since we have support for AArch64 in Travis-CI now, can we have "linux-arm64-64_binding.node" binary available at: |
|
any chance to build it on aarch64? build from sources? |
|
@AndreV84, Yes we can build it from source code, I've tried it on my local aarch64 system, it is getting build successfully. |
|
|
This is a big issue to us trying to use GitLab Runners on a Raspberry Pi |
Yeah, just stalled my Pi projects too. |
|
@vegerot @maltebeckmann There is a compatible alternative to node-sass, called dart-sass. I'm trying to figure out if this is an easier path forward. |
|
@vielmetti is dart-sass the same thing? can I just change the node-sass dependency to dart-sass? |
|
@nrgapple I haven't tested yet but its' supposed to be a drop-in replacement |
Building off of @ossdev07's work in #2645.
Looks like we can use drone.io as a CI service for at least
some ARM variants.
See the previous discussions in issue #1340 and PR #2253.