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.

[petpunk]

I’ve been running aMule on a 32-bit Raspberry Pi 2 for... a very long time. I know it’s difficult—@got3nks has explained it very, very well—but I’m hopeful that someday there will be a 32-bit version. 🤞

[got3nks]

Following up — I ran the experiments to pin down exactly where 32-bit stands, both for building and for distributing binaries. They have very different answers, so I'll split them.

Building

Linux i386 — the aMule code is 32-bit-clean. A full monolithic build (daemon + GUI + all tools) compiles on i386 and the unit-test suite passes 100% (11/11), Debug and Release, with zero source changes. There's one catch, and it's not in our code: aMule requires wxWebRequest, and Debian ships wxGTK built with wxUSE_WEBREQUEST=0 (Ubuntu enables it but no longer ships a 32-bit wx). So the only requirement is a wxWidgets 3.2 built from source shared, with libcurl — then everything builds and tests green. (One red herring worth noting: a static wx build segfaulted a unit test at static-init — a wx static-linking artifact on i386, not an aMule bug; a normal shared wx is clean.)

Linux armhf — same recipe, confirmed. Full monolithic build + 100% tests (11/11) with the same wx-from-source approach, validated under QEMU emulation (~3 h, so it fits CI but it's slow).

Windows 32-bit — a hard dead end for a workflow-only build. MSYS2 has removed the 32-bit (mingw-w64-i686-*) packages for our core deps — boost, wxWidgets, libgd, pupnp, libmaxminddb all return "target not found". That's why minnyres/amule-win32 works where a CI matrix row can't: it cross-compiles from Linux, builds every dependency from source with a mingw-w64 toolchain, and carries ~13 source patches on the 2.3.3 tree. That's firmly community-fork territory.

macOS 32-bit — not possible at any layer. Apple removed 32-bit support entirely in macOS 10.15 Catalina (2019): 32-bit binaries don't run, the modern toolchain/SDK can't target i386, and GitHub's macOS runners are 64-bit only. aMule already ships macOS as Universal2 (x86_64 + arm64). Nothing to build, nothing to run, no audience.

Distributing the binaries

Even with green 32-bit builds, our two official Linux channels don't extend to 32-bit:

Flatpak — not possible. aMule targets the GNOME 50 runtime, and org.gnome.Platform/org.freedesktop.Platform only publish x86_64 and aarch64 now — there's no i386 or 32-bit-arm runtime to build against (the remaining freedesktop i386 bits are a multiarch extension for running 32-bit apps on x86_64, not a 32-bit-host runtime). Flathub also wound down its 32-bit infrastructure.

AppImage — the format supports it, our pipeline doesn't. AppImage is one-file-per-arch and i686/armhf runtimes exist, but we bundle with linuxdeploy (+ GTK plugin), which ships only x86_64 and aarch64. A 32-bit AppImage would mean a separate, hand-rolled pipeline on the older/less-maintained appimagetool i686/armhf tooling — high upkeep for a shrinking audience.

Distro packages — the channel that already works. Debian/Ubuntu already build aMule for armhf and i386, so a Raspberry Pi 2 or an old i386 box gets it with apt install amule, tracking the distro's updates. For a headless amuled on a Pi (the most common 32-bit case), that fits better than a GUI AppImage anyway.

Where that leaves us

The source is genuinely 32-bit-friendly — it builds and tests clean on i386/armhf — so this isn't "aMule doesn't support 32-bit". But (a) it needs a from-source wx rather than a clean CI matrix row, and (b) our official binary channels (AppImage/Flatpak) can't carry 32-bit without new, poorly-maintained tooling. So the practical recommendation: for 32-bit Linux, use your distro's package (Debian ships armhf/i386); we can document the from-source build recipe for self-builders, and a portable tarball is an option if there's real demand. Windows 32-bit stays with the community port; macOS 32-bit is not possible.

[Coool]

@got3nks, great work. I still working on localization to Latvian in snail mode. After that I will try to find best option how to compile aMule for Windows 32-bit. Not interested in Linux 32-bit, you just install 64-bit Linux and problem solved. Maybe in some special case scenarios with some really obsolete 32-bit CPU you really need 32-bit Linux release. In such case better provide info how to compile 32-bit Linux release in documentation. Usually such people DIY anyway.

[petpunk]

Great news for me and excellent analysis for you once again. I'm now hoping it gets updated via Debian soon. 👏👏👏