32-bit releases

[Coool]

Hi, aMule Staff!

Did you forgot to compile 32-bit versions? Specially I'm curious about Windows 32-bit¹ releases.

Thanks.

Footnotes

1. amule-win32 ↩

[got3nks]

Hi @Coool, thanks for raising this.

Short answer: 32-bit isn't part of our current 3.0.0 release matrix, but the door is open. The rule of thumb is how much it costs the codebase to keep working:

• If a 32-bit build can be produced by a CI workflow change alone — no source patches, no carve-outs in the build system beyond what already exists — we'd be happy to merge that workflow and ship official 32-bit binaries alongside the 64-bit ones. The maintenance cost is just "one more matrix row" and that's a fair price.
• If 32-bit compatibility starts requiring substantial source changes — type narrowings to placate size_t-vs-uint64_t mismatches, special-cased atomics beyond the existing libatomic block, Y2038 / time_t workarounds, separate code paths for the new throughput throttler etc. — then it makes more sense as a community-maintained fork. We'd be glad to link to it from the project README / amule-org.github.io documentation alongside the official downloads, with a clear note that it's community-maintained rather than an official release.

A bit of context for why we landed there:

• 32-bit consumer CPUs are essentially legacy hardware now. Desktop x86 went 64-bit with AMD64 / Intel 64 around 2003–2008, Apple dropped 32-bit macOS in Catalina (2019), and even the mobile ARM ecosystem moved to AArch64 by the mid-2010s. New aMule installs overwhelmingly land on 64-bit hosts, so our packaging matrix targets Linux x86_64 + aarch64 (AppImage / Flatpak), Windows x64 + ARM64 (MSYS2 portable + NSIS), and macOS Universal2 (x86_64 + arm64).

• The source still builds on 32-bit, nominally. Our CMake configure has an explicit CMAKE_SIZEOF_VOID_P == 4 branch that requires libatomic (the throttler uses std::atomic<int64_t>, which expands to library calls on 32-bit CPUs without native 8-byte atomics — see amule-project/amule#643 for the original report). With libatomic1-dev installed, a 32-bit Linux build should still configure and compile from current master. We just don't run it in CI, so it isn't a regression-tested platform.

• One clarification on minnyres/amule-win32 (the link in your post): it builds against the aMule 2.3.3 source tree (the download_and_prepare.sh clones --branch 2.3.3), not current master / the upcoming 3.0.0. So those binaries don't reflect the bug fixes, security patches, or throughput work landed since 2.3.3. Useful if you specifically need a 32-bit Windows port today, but not equivalent to "the 3.0.0 release on 32-bit".

If you (or someone reading this) wants to try a workflow-only path — typically mingw-w64-i686-* packages on MSYS2 for Windows, or a multilib / i686 cross-compile on Ubuntu for Linux — open a PR against amule-org/amule and we'll work through whatever comes up. If it stays clean we'll merge it; if it surfaces structural 32-bit issues we'll know we're in the second category and can plan from there.

[Coool]

@got3nks, thanks for great explanation. I will look into it. If I have any luck I will report. Are aMule builds currently build using GitHub workflow?

P.S.
Using 32-bit OS usually on Chinese (PiPO, Chuwi etc.) devices with low memory. Maybe you can suggest any good Linux 64-bit distro. Or maybe need to build from scratch. How much RAM usually small Linux distro consume?

[got3nks]

@Coool — happy to hear it.

Yes, all our official builds run on GitHub Actions — workflows live at .github/workflows/. The reusable packaging.yml does the per-target builds (Linux AppImage x86_64 / aarch64, Flatpak, Windows MSYS2 x64 / ARM64, macOS Universal2); a 32-bit Windows job would slot in alongside MINGW64 / CLANGARM64 using the MSYS2 mingw-w64-i686-* package family.

On the PiPO / Chuwi side — worth checking the CPU before reaching for a 32-bit build at all. Most budget Chinese tablets / mini-PCs from ~2014 onwards shipped Intel Bay Trail / Cherry Trail Atoms, which are actually 64-bit hardware despite usually arriving with 32-bit Windows pre-installed (Microsoft licensed 32-bit Windows cheaper for sub-2GB-RAM devices). If cat /proc/cpuinfo | grep lm shows the long-mode flag, you can run a 64-bit Linux on it without changing the hardware.

For low-RAM 64-bit Linux on that class of device:

• MX Linux (XFCE) or Lubuntu (LXQt) — both polished, low overhead, and won't surprise a typical user. ~300–500 MB idle.
• antiX if you specifically want the smallest footprint with a normal desktop.

aMule itself uses ~100–200 MB RSS for the daemon, ~250–400 MB for the full GUI — so a comfortable setup wants ~1 GB total RAM for the OS + aMule + a browser tab or two.