Adding RISC-V 64-bit Support in Chromedriver

[Jay-Lokhande]

Hello,

I’ve been working on cross-compiling CouchDB for the RISC-V 64-bit architecture. While doing so, I ran into an issue with the Fauxton web based interface, which uses Chromedriver. When I tried to compile, I got an error saying that Only Linux 64-bit is supported. To fix this, I added support for RISC-V 64-bit in the Chromedriver configuration install.js, and after making this change, I was able to successfully compile and run CouchDB on a RISC-V system.

Before I commit this change and create a pull request, I wanted to check with the maintainers to see if this is something I should proceed with. Here’s what I’d like to know:

Does adding RISC-V 64-bit support align with the project’s goals or benefit other users?
Are there any specific requirements or steps I should follow if I were to submit this change?

I’d really appreciate your feedback on whether this is a good idea to include in the repository and if I should go ahead with a pull request. Thanks so much for your time and guidance!

Best regards,
Jay

[giggio]

@Jay-Lokhande Supporting RISC-V does align with what this project does. I have a few concerns to be able to effectively add it.

1. Does the Chrome team offer the binary at Chrome for Testing? If not, how would we get it?
2. Ideally we'd need to be able to test it using Github actions, is that possible? If not, that's ok, but it will be more fragile. We could use third party free build tools, for example, I have used Azure DevOps in the past to build when Github actions did not yet have all the tools I needed.
3. Would the update make install.js much more complex?

That's about it.

[Jay-Lokhande]

@giggio Thank you for your thoughtful response

Here are my answers to your questions:

1. The Chrome team does not currently provide a binary for RISC-V 64-bit on Chrome for Testing. That page lists support for architectures like x86_64 and ARM64, but RISC-V is not included.

2. GitHub Actions does not officially support RISC-V runners, as noted in this issue (Supporting Runners on 64-bit RISC-V). However, community efforts like self-hosted runners for RISC-V indicate it’s possible with additional setup.

3. I added a check for process.arch === 'riscv64' in install.js, and with this change, the library runs without errors on my RISC-V system. However, I think this might not be a complete solution. I’d like to dive deeper into the architecture configuration across the library to ensure there are no hidden bugs or oversights.

I would appreciate guidance on specific areas of the codebase or potential edge cases that I should consider.

[Jay-Lokhande]

@giggio Thanks again for your input! I really appreciate your guidance as I work through this.

The main goal of my change is to enable the chromedriver npm package to support RISC-V 64-bit systems by modifying install.js (and other required files). Since the Chrome team doesn’t provide an official RISC-V binary through Chrome for Testing, my approach has been to compile Chromedriver from source on my RISC-V system and then integrate it into the install process. I understand this isn’t ideal for a seamless npm install experience, so I’d love your thoughts on how to make it more robust.

Here’s where I’m at:

One idea is to host a RISC-V binary somewhere reliable and update install.js (and other required files) to download it, similar to how official binaries are fetched from Chrome for Testing JSON endpoints. Alternatively, we could add a build script to compile it during installation, perhaps leveraging community efforts like StarFive’s RISC-V Chromium port, though that might add complexity and dependencies. What do you think about these options? I’d like to avoid maintainers needing to self-host anything costly.

RISC-V is increasingly used in Linux-based systems, as seen in discussions on platforms like Reddit (RISC-V on Reddit).
Reddit discussions (GitHub Actions Self-Hosted runner for RISC-V) also confirm successful runs, including building the runner itself.

My Fork (this is very little change but worked for me as I mentioned above this might not be a complete solution)

I’m hoping to keep the changes minimal and maintainable, but I’d really value your advice on how to handle the binary issue and testing in a way that fits the project’s workflow. Looking forward to your feedback thanks so much!

Best,
Jay

[giggio]

The change you made will allow the package to be installed, but it will fail when install.js tries to download the binary.

I see 2 options:

1. We could use the --chromedriver_filepath option along with it, and if it is not supplied the download will fail. We could anticipate that with a nicer error message explaining to the user what is happening so they can fix it.
2. If we have the binary being built and hosted somewhere (maybe on Github using Github actions and artifacts) we could point to it. This would be better.
   You could also ask the Chromedriver team to build a RISC-V binary, I believe they could be open to the idea. Or if Starfive would build Chromedriver along with chromium, that might work too.

[Jay-Lokhande]

Thanks for the detailed feedback and the options you’ve outlined!

I think Option 1 using --chromedriver_filepath with a nicer error message makes the most sense as a starting point. It’s a quick way to add RISC-V support without adding too much complexity, and it gives users clear instructions to supply their own binary. I think need a updatation in install.js to detect RISC-V (using process.arch === 'riscv64') and throw a helpful error if the filepath isn’t provided, something like:

"Error: RISC-V detected: No official Chromedriver binary is available for RISC-V 64-bit. Please provide a local Chromedriver binary using the --chromedriver_filepath option. Example: npm install chromedriver --chromedriver_filepath=/path/to/chromedriver You may need to build Chromedriver from source or obtain it from a third-party source."

we can also add a note to the README to explain this for RISC-V users.

That said, I agree Option 2 having a custom binary would be a better long-term solution for a seamless experience. I have explored GitHub and I got some repos which can help us for GitHub actions and artifacts

RISCV GNU toolchain binary to set up CI GitHub Action.
Prebuilt RISCV GNU toolchain
GitHub Actions Self-Hosted runner for RISC-V
RISC-V Supervisor Binary Interface
cross-platform (Windows, macOS, GNU/Linux) binary distribution of GNU RISC-V

On the official support idea, I’ll draft a feature request to the Chromedriver team on the Chromium issue tracker and reach out to Starfive to see if they’d consider building Chromedriver with their Chromium port. It’s a long shot, but I think it’s worth starting that conversation.

For now, should I prep a pull request with Option 1 ? and share a link to my fork once it’s ready. Thanks again for your support on this I’m excited to make it work for RISC-V users!

[giggio]

Yes, go ahead with option 1. You already added the option to allow RISC-V, now we need to tell the user that they need to supply --chromedriver_filepath if they forget, but only for RISC-V.
Also, change the readme to inform RISC-V users. I believe a new sub section under the installing section would be good, add it at the end.

Later, if any of those efforts for option 2 succeed, please come back to this discussion and we can discuss the next steps.

[Jay-Lokhande]

Thanks for the confirmation! I'll proceed with Option 1 and update install.js to detect RISC-V, show a clear error message if --chromedriver_filepath isn’t provided, and update the README with installation instructions for RISC-V users.

I'll submit a PR soon and share the link here for review.

For Option 2, I’ll continue exploring ways to host a prebuilt RISC-V binary and will also reach out to the Chromedriver and StarFive teams. If there are any updates, I’ll revisit this discussion.

Thanks again for your support!

[kxxt]

FYI: I am starting to release unofficial Chromium and chromedriver binaries for riscv64 at https://github.com/riscv-forks/chromium-riscv