mksnapshot-v1.6.0-linux-armv7l.zip contains x86 binary not armv7l binary

[mathuin]

• Electron version: v1.6.0
• Operating system: armv7l

Expected behavior

I downloaded https://github.com/electron/electron/releases/download/v1.6.0/mksnapshot-v1.6.0-linux-armv7l.zip and it should have contained an armv7l binary.

Actual behavior

Instead it contained an x86 binary.

How to reproduce

Click the URL, unzip the zip file, and run file mksnapshot. If it says "Intel 80386", that's bad, because it's supposed to say "ARM" instead. This problem is keeping me from building Atom on my Chromebook because I can't find an ARM binary for mksnapshot.

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[shreyneil]

A similar issue has been raised previously

electron/mksnapshot#3
and https://github.com/hypersad found a way for building
atom.
Here is the link to it.
https://github.com/hypersad/atom-armv7l
Please verify and get back.

[mathuin]

Yes, that is the same issue that I am facing. I honestly wasn't sure where to post about it, but it's affecting me for the same reason it affected them.

My first attempt to build from that user's repository (marked unmaintained last month, by the way) results in a failure with code ELIFECYCLE for chromedriver-v2.21-linux-arm.zip. The release page for electron/chromedriver only goes up to v1.7.1 and I don't know where else it might be looking. That way lies pain, especially because I do not know anything about node.

What can be done about the root cause of this issue? Is there a way to fix the problem of releasing binaries built for x86 in a tar file labeled armv7l ?

[groundwater]

Going a bit off memory of also trying to get Atom running on ARM64.

I believe mksnapshot does not work on ARM64. You have to compile it for x86/64 essentially like a cross-compiler, and the x86 version outputs the ARM64 snapshot. We never got this far, and just disabled snapshotting altogether.

As to whether the bundled x86 version actually does this is another story. I don't think it's tested, and CI has been outputting it as an artifact because that's how the scripts work.

[mathuin]

If I could successfully cross-compile Atom itself for armv7l on x86_64, that would be awesome. It's hard to find information about that because of the other relevant hits for cross-compile and Atom, and there's no info in the Flight Manual about that.

With regard to disabling snapshotting, it's still enabled in the master branch as far as I can tell. script/lib/generate-startup-snapshot.js is present and is executed (or at least its output is seen) when I try to build Atom. If there's an elegant way for me to disable that so I can skip this step, please let me know!

[ghost]

If new correct-compiled mksnapshot binaries will be released, I'll try to find my old laptop and build latest version of Atom.

[mathuin]

If new correct compiled mksnapshot binaries are released, then the branch containing atom/atom#15431 should be able to build Atom on ARM as well. In theory. :-)

[ghost]

@mathuin the main problem, as I remember, was incorrect arm architecture detection (so packages like electron can't be downloaded), currently I'm have an idea how I can fix that. This branch probably could fix one issue - creating an armhf package. Last time I'm trying to do this it was unsuccessful.

[nonnymoose]

I can confirm that @groundwater is correct.
I downloaded the mksnapshot armv7l binary and ran mksnapshot --help on my x86 machine, and here are the first few lines:

target simulator arm v7 neon hard
ARMv8=1 ARMv7=1 VFPv3=1 VFP32DREGS=1 NEON=1 SUDIV=1 USE_EABI_HARDFLOAT=1

It might be possible to run this on the target using qemu-user.

[ghost]

I don't think that is right to set the version/1.6x label because this probably affects all prebuilt mksnapshot binaries. Also, I've tried to build v8's arm.release yourself and got i386 binaries too.

[groundwater]

Thanks for checking @nonnymoose.

Unless something has changed in recent Chromium, tooling will need to run mksnapshot from an x86-64 host machine to generate and incorporate the ARM64 snapshots.

I believe the x86 binary for mksnapshot is working as intended.

[ghost]

@groundwater so, you mean we could use x86_64 mksnapshot to generate correct startup blobs from startup scripts?

[groundwater]

@hypersad I believe so, the x86_64 binaries should in theory generate the correct ARM7/ARM8 snapshots. We stumbled across this when trying to get Atom running. Everything ARM related in Chromium seems to be cross-compiled, so it makes sense they might design it this way.

Unfortunately I have not tested this, and if the generated snapshots do not work, that's definitely a valid bug, but we should perhaps deal with that in a new issue.

[ghost]

@groundwater I'm currently trying to build v8 on my Raspberry Pi 3. I've also tried to cross-compile it and end with success, but there was NO mksnapshot binary, lol. This is long process due to I can't set something like -j9 to prevent overheating. I'm really hope that it generate mksnapshot binary for itself, because when I tried to cross-compile it, it generated mksnapshot, but only for himself (i386).

Yesterday I've tried to use ia32 mksnapshot on my Windows notebook and got snapshot_blob.bin, but Atom on armv7l throw Ilegal instruction exception with this startup blob into me :(

[groundwater]

but there was NO mksnapshot binary, lol

@hypersad my recollection is that compiling chromium on ARM64 is not really supported, and that you cannot cross-compile mksnapshot. However mksnapshot can be compiled to itself be a cross-compiler. I believe the gn build tool will set all this up correctly, but the process is a little groggy. I wonder if there is also a difference between gyp and gn here. We compile v8 with libchromiumcontent which uses gn. I think most people who compile v8 in isolation use gyp. I have no insight into how up to date or in sync the two methods are.

We documented our process here atom/atom#15881 although ultimately we just removed snapshotting to get our prototype working. It's something we need to loop back on.

[ghost]

Got it!

CXX(target) /home/pi/Coding/v8/out/arm.release/obj.target/mksnapshot/src/snapshot/mksnapshot.o
LINK(target) /home/pi/Coding/v8/out/arm.release/mksnapshot

pi@raspberrypi:~/Coding/v8/out/arm.release $ file mksnapshot
mksnapshot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=78106edf61705ebf79d8206966383867009d5bb6, not stripped

pi@raspberrypi:~/Coding/v8/out/arm.release $ ./mksnapshot --help
target arm v7 neon hard
ARMv8=0 ARMv7=1 VFPv3=1 VFP32DREGS=1 NEON=1 SUDIV=1 USE_EABI_HARDFLOAT=1

[groundwater]

@hypersad that looks promising, does your mksnapshot work natively on ARM?

[ghost]

@groundwater yep, I've generated snapshot but can't test it yesterday and gonna try it today. This way for building it is so weird, but at least we know, that is possible. Could you tell me arguments with which current mksnapshot binaries built? I'd like to built similiar binaries. Is electron using clear mksnapshot code from v8 or it modified?

Update: I'm successfully cross-compiled mksnapshot binary for armv7l from amd64 machine. It was a test build, so process failed after compiling this binary. I try to optimize this and probably will upload a gist.

Update: Atom still throws Illegal instruction. I'll try to compile some binaries with different settings.

Update: I compield 3 binaries with neon vfpv3 and vfpv3-d16 settings for armfpu. They are succesfully create startup blobs, but when I launch Atom with them - I got this stack trace. I don't know how to deal with this:

pi@raspberrypi:~/Coding/atom-arm/out/atom-1.23.1-armv7l $ ./atom

#
# Fatal error in ../../v8/src/snapshot/snapshot.h, line 28
# Check failed: IsSane().
#

==== C stack trace ===============================

    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/libnode.so(+0x7b75e8) [0x769c05e8]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/libnode.so(V8_Fatal+0x4d) [0x769c1f6a]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/libnode.so(+0x783e28) [0x7698ce28]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/libnode.so(+0x783c18) [0x7698cc18]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/libnode.so(v8::Isolate::New(v8::Isolate::CreateParams const&)+0xef) [0x767a1c68]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom() [0x1155ece]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom(atom::JavascriptEnvironment::JavascriptEnvironment()+0x1b) [0x27b9382]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom(atom::AtomBrowserMainParts::PostEarlyInitialization()+0x8d) [0x27b66b8]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom() [0xebfc2e]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom() [0xeaeb12]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom() [0xd8f9ce]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom() [0xb628cc]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom() [0xb62c1a]
    /home/pi/Coding/atom-arm/out/atom-1.23.1-armv7l/atom(main+0x53) [0x27b1394]
    /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x114) [0x74ac9678]
Illegal instruction

I think, I should try to build it setting ELECTRON_MIRROR for full build with compatible mksnapshot binaries.

[ghost]

@groundwater you're right! I tried to generate startup blob from startup.js on my amd64 machine with armv7l binaries, and it works! Successfully built & launched Atom on my armv7l machine.

[mathuin]

@hypersad you are my hero! Can you tell me exactly how you did it? I would love to try your process on my Chromebook!

[ghost]

@mathuin you can find all information about building Atom for arm platforms here.

[ghost]

@groundwater mksnapshot binary for armv7l that generates proper snapshot and works natively on armv7l is ready! 😎

To get it we're just need to modify some generated ninja build files:

• Add mksnapshot target to build.ninja
• Add rule how to make mksnapshot to toolchain.ninja
• Set right arguments and sysroots in the obj/mksnapshot.ninja (they're could be taken from other files like d8.ninja)

Check it out!

[groundwater]

Fantastic @hypersad. Bringing in @jkleinsc who will be looking at this soon.

[ghost]

I hope Electron 2.0.0 will include native working mksnapshot binaries?

[jkleinsc]

@hypersad I'm working on it now. If it is ready, we certainly will include it in 2.0.

[sofianguy]

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you're still experiencing this issue in the latest version of Electron, please add a comment specifying the version you're testing with and any other new information that a maintainer trying to reproduce the issue should know.

I'm setting the blocked/need-info label for the above reasons.

Thanks in advance! Your help is appreciated.

[sofianguy]

Thank you for your issue!

We haven't gotten a response to our questions in our comment above. I'm going to close this but don't hesitate to reach out if you have or find the answers we need, we'll be happy to reopen the issue.