does oxlint support 32-bit x86 GNU/Linux, or is this an unsupported platform for which issues should not be reported?

[robertkirkman]

Hi, I wanted to use oxlint on 32-bit x86 GNU/Linux, but this error occurred:

   Compiling oxc_tasks_common v0.0.0 (/home/tacokoneko/oxc/tasks/common)
   Compiling supports-color v3.0.2
   Compiling idna v1.1.0
error[E0080]: evaluation panicked: assertion failed: size_of::<Quantifier>() == 48
   --> crates/oxc_regular_expression/src/generated/assert_layouts.rs:211:5
    |
211 |     assert!(size_of::<Quantifier>() == 48);
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `generated::assert_layouts::_` failed here

   Compiling ignore v0.4.23
For more information about this error, try `rustc --explain E0080`.
error: could not compile `oxc_regular_expression` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

Is this an error you would want to fix, or do you prefer that all owners of 32-bit-only devices do not use oxlint, or at least do not report errors that appear on their devices when compiling oxlint?

oxlint version: 1.15.0 and git main

Operating system:

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.1
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
$ uname -a
Linux debian 6.1.0-32-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) i686 GNU/Linux
$ cargo --version
cargo 1.89.0 (c24e10642 2025-06-23)
$ rustc --version
rustc 1.89.0 (29483883e 2025-08-04)
$ 

[overlookmotel]

@robertkirkman I must admit we don't put a huge amount of effort to support 32-bit platforms, aside from WASM32. To be honest, we kind of assumed it was unlikely there was a need for it.

But Oxc should work on 32-bit systems, and bug reports like this are welcome and helpful. I hope you can understand, however, that niche use cases are not always going to be top of the list for support, and we can't promise to maintain support forever if the maintenance ends up outweighing the usefulness. But so far, so good...

Can I ask: What's your use case for running Oxc on 32-bit platforms? From the linked issue, I see this is related to Termux. Of course, it would make sense that Termux itself wants to support 32-bit, but from what I can see, termux-packages is used to build Termux, rather than being the application itself. Is it desirable to build Termux on an Android phone??

I imagine I'm misunderstanding. Would appreciate it if you could satisfy my curiosity with the rationale?

[overlookmotel]

#13716 should fix this, but I've not been able to test that. Please can you confirm @robertkirkman?

[robertkirkman]

Can I ask: What's your use case for running Oxc on 32-bit platforms?

Personally, sometimes I like to use 32-bit GNU/Linux because I have several 32-bit GNU/Linux computers that I occasionally use for development or other tasks, which I like to keep up-to-date with the latest software, and this occasionally includes various Rust projects, including oxc.

Here are two of my 32-bit GNU/Linux computers that I would find this support helpful for:

• Texas Instruments BeagleBone Black with Sitara AM3358 32-bit ARM SoC (off-brand Raspberry Pi competitor, released 2013)
• Acer Aspire One ZA3 AO751h with Intel Atom Z510 32-bit x86 CPU (small laptop, released 2008)

From the linked issue, I see this is related to Termux. Of course, it would make sense that Termux itself wants to support 32-bit, but from what I can see, termux-packages is used to build Termux, rather than being the application itself. Is it desirable to build Termux on an Android phone??

I imagine I'm misunderstanding. Would appreciate it if you could satisfy my curiosity with the rationale?

Regarding Termux, Termux is a project that focuses on porting software directly to Android that was originally written only for other UNIX-like operating systems that are not Android, like GNU/Linux, FreeBSD, MacOS, OpenBSD, Alpine Linux, Chimera Linux, DragonflyBSD and others.

Termux should primarily be thought of first as the leading community port of all of these very famous softwares directly to Android, and I think the relevance and applicability of all other softwares you could imagine becomes logically clear if you begin with this understanding:

• Terminal Emulator frontend
• bash
• coreutils
• dpkg
• apt
• vim
• neovim
• emacs
• clang
• binutils
• cargo
• rustc
• openssh
• git
• X11 server and frontend layer (allowing X11 server to display inside of the Android default display server, which is called "SurfaceFlinger", and Android touchscreen inputs to reach the X11 server which is nested inside the "SurfaceFlinger" server)
• XFCE desktop environment
• MATE desktop environment
• LXQt desktop environment
• Cinnamon desktop environment
• code-oss
• firefox (including 100% of all GUI buttons not present in the Google Play build of Firefox)
• chromium (including 100% of all open source GUI buttons not present in the Google Play build of Google Chrome)
• thunderbird (including 100% of all GUI buttons not present in the Google Play build of Thunderbird)
• over 2500 other community ports of softwares that were originally written for non-Android UNIX-like operating systems, directly to Android, including oxlint version 1.14.0 (which was the last version of oxlint that I've currently been able to build successfully for 32-bit Android)

The internal architecture of Termux is very convoluted compared to other Linux distributions and is complicated to explain, so usually, when communicating with upstream developers, I tend to reproduce the relevant problems/errors I am having trouble with on a target platform that is officially supported by and familiar to the upstream developers, of which common examples typically include GNU/Linux, MacOS, or FreeBSD. I assume that this practice usually helps the upstream developers understand the problem clearly and makes it so that they do not have to try to calculate the cause of the problem in the context of Android, which usually would add an unnecessary layer of complexity and confusion to the problem from the perspective of any developers who are not necessarily familiar with and dedicated to Android development.

After I see the code that's necessary to fix the errors on a very popular UNIX-like development platform, like GNU/Linux, usually I am then able to use my experience with Android to adapt the necessary changes to Termux and its convoluted internal architecture, without needing to have too much additional help from upstream in that department.

Currently, I have written a packaging script, which I am maintaining within the Termux project repositories, that has no problems building and providing oxlint and oxfmt for the operating systems 64-bit ARM Android and 64-bit x86 Android through Termux.

However, where I have been increasingly encountering some problems, is with building and packaging the same package for the operating systems 32-bit ARM Android and 32-bit x86 Android. I have unfortunately been encountering an increasingly large number of errors only when building Oxc for the 32-bit Android targets, which have been becoming more and more difficult for me to work around downstream as time goes on and I attempt to update ("bump") the package to newer versions of Oxc.

Usually, when this situation happens, I discover that am able to reproduce similar build errors when compiling the same source code on GNU/Linux, FreeBSD or another non-Android UNIX-like operating system, and when that is the case, I usually take it to mean that the problems in the software are most likely not unique to Android, but are probably related to an issue affecting many operating systems that could be traced to one or more bugs somewhere in the upstream code itself.

That is the basic explanation of why I believe that successfully building Oxc on a 32-bit GNU/Linux device, then copying and pasting the same fixed version of the project's code into the Termux project and recompiling it there, will most likely result in much fewer errors when attempting to build Oxc targeting 32-bit Android.

[robertkirkman]

#13716 should fix this, but I've not been able to test that. Please can you confirm @robertkirkman?

Thank you, I will test very soon on my 32-bit GNU/Linux device and report the results and any further messages I see next.

[robertkirkman]

Is it desirable to build Termux on an Android phone??

Technically, that task, interpreted literally from your question, is possible, and some people do have a need/desire/history of doing that, however, that particular case is a bit of a "niche of a niche" use case/project that I believe is not necessarily particularly relevant to specifically Oxc on Android, from the perspective of the topic in this issue. That is a bit of a different subject, but if you are really interested I could link other resources related to that.

The entire Termux Application does not actually need to be recompiled every time that a new software "package" is added. Instead, the apt package management system has been 100% fully ported directly to Android, where it functions as an addon manager that adds additional softwares into one's Termux installation as "packages" in almost exactly the same way that Debian or Ubuntu do (except that Debian/Ubuntu .deb packages are for the operating system GNU/Linux, while Termux .deb packages are for the operating system Android)

Usually, the technology involved with producing these individual "packages" for Android, which are then installed as addons/plugins into Termux, is "cross-compilation". However, cross-compilation is not the only supported compilation method, since "non-cross-compilation" is also supported.

Very few other UNIX-like operating systems, with some possible exceptions like Gentoo, have the same kind of "cross-compilation" environment and infrastructure that Android+Termux has, so it would take quite a long time to explain every single detail of how Termux internally works and is different from other Linux distributions, but I could explain further details if they become relevant on an as-needed basis.

[robertkirkman]

I have several results to report:

• Firstly, the most relevant result, which is important to this issue, is that on 32-bit x86 GNU/Linux, there is no longer any error in the main branch with the debug build, so I can confirm that the PR has fixed this issue completely, assuming that it is OK to disable the assertion as the solution (as your comments and commit message have explained). Therefore, this issue can be closed as completed by me or you whenever you are ready.

• Secondly, in oxlint version 1.15.0 (not the main branch), there is this error next, in the build for 32-bit x86 GNU/Linux:

error[E0432]: unresolved import `oxc_allocator::free_fixed_size_allocator`
  --> napi/oxlint2/src/lib.rs:13:32
   |
13 | use oxc_allocator::{Allocator, free_fixed_size_allocator};
   |                                ^^^^^^^^^^^^^^^^^^^^^^^^^ no `free_fixed_size_allocator` in the root

error[E0599]: no method named `fixed_size_metadata_ptr` found for reference `&oxc_allocator::Allocator` in the current scope
   --> napi/oxlint2/src/lib.rs:134:43
    |
134 |     let metadata_ptr = unsafe { allocator.fixed_size_metadata_ptr() };
    |                                           ^^^^^^^^^^^^^^^^^^^^^^^
    |
help: there is a method `set_data_ptr` with a similar name, but with different arguments
   --> /home/tacokoneko/oxc/crates/oxc_allocator/src/from_raw_parts.rs:239:5
    |
239 |     pub unsafe fn set_data_ptr(&self, ptr: NonNull<u8>) {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Some errors have detailed explanations: E0432, E0599.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `oxc_linter_napi` (lib) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

When I originally opened my issue 17 hours ago, my original plan was to let you fix the first error, and then after that was fixed, I would have posted the second error and said something like "the first error is fixed, but this other error is now happening instead on the same computer".

However, after very careful inspection of your repository's git history, I have come to the realization that today, you have actually fixed that error too, already, and you did it in this PR, which has occurred after the release of oxlint version 1.15.0:

• fix(napi/oxlint): prevent compilation failure on WASM32 #13711

and because I did not mention that other error at first, making my "xyproblem" very unclear at first, in retrospect it makes me look kind of manipulative for opening an issue about one error, with a plan to dump a different "xyproblem" error into the same issue quickly afterward. I am very, very sorry about that, and in the future I will not do this again and instead I will make sure to have more patience, and wait just a little while in case you are already fixing errors after the release, and I will make sure to check open PRs and recent commits regularly.

Most likely, in Termux, I will skip packaging oxlint version 1.15.0, and just keep Termux users on version 1.14.0, until the next stable release of oxlint comes which will have both of the fixes that you have very helpfully made for 32-bit platforms!

[overlookmotel]

Thank you for the comprehensive explanation!

in retrospect it makes me look kind of manipulative

No, please don't worry, it doesn't!

Glad we've fixed the problem(s). Going to close this.