platform support megaticket

Windows (started: v1 wip libpkgx#48)
iOS Jailbreak (discussion Future support: (jailbroken) iOS? #182)
Android
Umbrel
i686 32 bit (attempting to run pkgx on iShell i686 32-bit architecture on iOS #886)

Maybe

WSL1 (discussion WSL1 #493)

Architectures

What do we need? Let us know.

Supported

macOS >= 11
- aarch64
- x86-64
Linux (glibc >= 2.28)
- aarch64
- x86-64
WSL2
- x86-64

Having native Windows support would be massive! Can't wait.

Deno supports Ubuntu 16.04, but Tea does not (because of the old version of glibc).

I'm just wondering... would it be too hard to add support for older versions of GLIBC?

I'm just wondering... would it be too hard to add support for older versions of GLIBC?

Yes, extremely. ;)

If you're interested, I've been working on getting a build of glibc we can inject for tea binaries on pkgxdev/pantry#147. glibc is a tricky beast, since it's all the way at the bottom of the stack. If you have insights or assistance to offer, it's always greatly appreciated.

(I won't badger you to move to an LTS that's still in standard support, even though 16.04 is over 7 years old. I want to, because it's easier for me, but I'm too nice to do it.)

It's entirely possible, of course, that you can build tea and many packages manually on 16.04. But our bottles are built against a debian buster GLIBC (2.28) and ubuntu 16.04 is 2.23, it looks like.

Alright, it's perfectly understandable.

My needs to use Ubuntu 16.04 are beyond me, thanks for understanding that. And I wanted to use Tea on Ubuntu 16.04 to make that less painful (e.g. I need to install Python 3.10 on Ubuntu 16.04).

If you're interested, I've been working on getting a build of glibc we can inject for tea binaries on pkgxdev/pantry#147. glibc is a tricky beast, since it's all the way at the bottom of the stack.

Nevertheless this sounds amazing. If someday it gets done, I suppose curl -fsS https://tea.xyz | sh could handle it as well (i.e. installing tea's glibc manually before invoking tea itself).

If you have insights or assistance to offer, it's always greatly appreciated.

Sorry but I have no assistance to offer at this point. I can just say that I think you are doing the right thing. :)

Well, I appreciate the encouragement, except for the fact that working at the glibc level is utterly painful and I'd love to bin the whole idea. 😆

There are a non-zero number of people using Alpine or Amazon Linux 2 who also need this, so it should be figured out.

i don't recall, per se. My gut says it's not tiny. probably in the 10-100MB range, if i were doing fermi approximation.

Sorry, for context I had asked:

Out of curiosity, do you know how big (MB) a bottle of glibc would look like?

But I deleted it from here and posted in pkgxdev/pantry#147 instead. Now that you asked, I deleted it from pkgxdev/pantry#147 too.

i don't recall, per se. My gut says it's not tiny. probably in the 10-100MB range, if i were doing fermi approximation.

That's not bad at all, I was just wondering since you mentioned Alpine users. lol

Is freebsd supported if compile from source?

this is a fantastic question. in theory, supporting it should be trivial, since it uses most of the same low-level tools. patches would be needed to libpkgx and pkgx to recognize the platform, and there would probably be some changes needed to deal with libc differences. but if deno/rust work on freebsd (and i assume they do), a port isn't a big deal (until we get to building the entire pantry. that is a big deal. ;) )

if you get libpkgx/pkgx working, we'd love to support freebsd.

Is freebsd supported if compile from source?

We would love to support freebsd.

Sadly, it is not currently trivial to boostrap the key packages required to build the rest.

install deno with the freebsd system package manager
clone pkgx
deno task install
pkgx integrate (required to easily use the pantry, sorry, will fix eventually)
clone the pantry
In the clone: dev
pkg edit llvm.org remove deps (install them from system)
pkg build llvm.org

then work from there.

what we need is some kind of “bootstrap pkgx for a new system” manual with helper scripts. Let me put that on my TODO list. We'll need it for Windows native anyway.

Once we have verified a new system can be supported we will put it into our CI/CD so that all packages are built and hosted on our infra.

First steps for native Windows are almost complete, just got some npm build issues pkgxdev/libpkgx#48)

I recently learned about Pixi at https://prefix.dev (not affiliated, and I'm sorry to post a competitor here). It supports Windows and all the other platforms, and because they are based on Conda packages, they already have pretty good collection of existing packages.

Would be great for you guys to join forces, because the world would be a better place :)

Thanks for the correction — my probe was on the v1-layout root prefix and completely missed v2/. Re-running against the right path now, the picture is much friendlier than my comment suggested:

15 of 88 packages under v2/ have a windows/ subdir today (all built artifacts, two versions in some cases, e.g. v2/bun.sh/windows/x86-64/v1.2.5.tar.xz and …/v1.2.10.tar.xz):

v2/bun.sh/          v2/libarchive.org/   v2/python.org/
v2/cmake.org/       v2/nasm.us/          v2/rust-lang.org/
v2/curl.se/         v2/ninja-build.org/  v2/sqlite.org/
v2/deno.land/       v2/openssl.org/      v2/zlib.net/
v2/git-scm.org/     v2/perl.org/
v2/go.dev/

That's a coherent toolchain layer — language runtimes (deno, bun, go, rust, python, perl), build tools (cmake, ninja, nasm), and base libs (openssl, sqlite, zlib, libarchive, curl). Enough that, with the manifest infrastructure revived, application-layer Windows packages could plausibly come back online via cross-compile (Go/Rust toolchains are right there).

That reframes the picture: the missing piece isn't a Windows build path from scratch — it's reviving (or replacing) the manifest work that was rolled back a year ago. Two questions on that:

What did the rolled-back work actually do? Was it a brewkit branch, a pantry-side change, or a separate manifest-generator pipeline? Any pointer (PR, branch, even an internal note) would help anyone trying to pick it up understand what regressed vs. what was a design dead-end.
Was the rollback motivated by something fundamental (signing, security, dependency-resolution semantics that didn't work out on Windows) or operational (cost, runner availability, prioritisation)? That changes whether a clean reattempt is even sensible.

If the second answer is "operational, no fundamental block" then I think the proposal in my previous comment still stands — pilot a cross-compile-from-Linux path for the application-layer packages on top of the v2 toolchain you've already got. If the first answer surfaces a specific brewkit-side prototype, the right move might be to rebase that rather than reinvent.

(Updating my pkgm draft and my pantry PR notes to refer to v2/<pkg>/windows/ correctly. Sorry for the noise on the first round.)

What did the rolled-back work actually do? Was it a brewkit branch, a pantry-side change, or a separate manifest-generator pipeline? Any pointer (PR, branch, even an internal note) would help anyone trying to pick it up understand what regressed vs. what was a design dead-end.

Was the rollback motivated by something fundamental (signing, security, dependency-resolution semantics that didn't work out on Windows) or operational (cost, runner availability, prioritisation)? That changes whether a clean reattempt is even sensible.

this is the commit that removed the v2 pantry-style work: pkgxdev/manifests@37ff43e

without having access to the specific dev notes from that date, my suspicion is that the more flexible programmable build manifests needed to support windows were suffering from exploding complexity.

so, the scope of the project have changed or do we still want native windows support?

I think the goal of windows builds is a good idea. possibly we need a different approach. The underlying driver for the manifests work was that bash scripts worked poorly in native windows, and therefore brewkit was unsuitable. perhaps the answer is have a brewkit-like tool that will work for windows, and a build.windows pantry key for whatever script that entails.

feat(matrix): allow pkg.yml to opt in to windows/x86-64

@mxcl

Picking the Windows-native thread back up — opened pkgxdev/brewkit#346 with a concrete architecture sketch + first-deliverable proposal (cross-compile jq from Linux runners via llvm-mingw, produce a .tar.xz, smoke-test on Win11).

Builds on the patterns converged on last week's brewkit issues:

bklibcvenv: hermetic glibc helper (analogue to bkpyvenv) brewkit#344 (bklibcvenv) → port to bkwinvenv for hermetic DLL bundling
fix-elf: don't write RPATH onto ld-linux-*.so.* (loader SIGSEGVs at startup) brewkit#345 (per-package build.skip: fix-patchelf) → applies directly to a fix-pe analog
feat(build-script): linux-sysroot: directive for host-independent builds brewkit#343 (linux-sysroot) → sibling windows-sdk directive

@mxcl re. your note about needing a bootstrap procedure for new platforms — this RFC sketches one for Windows. Happy to drive it if there's appetite.

@jhheider

Regarding Android support, I'm trying to run the pkgx binary compiled for aarch64 on Termux (https://play.google.com/store/apps/details?id=com.termux), but I haven't been successful so far.

Are there any plans to build pkgx binaries for this platform? Is there anything I can do to help with this? @jhheider @mxcl @tannevaled
Thanks!

That's the first request I remember for android support. Where is it failing on you? Patches are certainly welcome.

@jhheider

Where is it failing on you?

@jhheider This is the architecture of my Android phone:

uname -a
Linux localhost 5.4.289-qgki-gfba839b572c0 #1 SMP PREEMPT Mon Dec 29 14:29:58 UTC 2025 f2fs-hash:2f5bc4e005 aarch64 Android

I tried running pkgx on Termux, but got the following error:

./pkgx
error: "/data/data/com.termux/files/home/.local/opt/pkgx/pkgx": executable's TLS segment is underaligned: alignment is 8, needs to be at least 64 for ARM64 Bionic
Aborted                    ./pkgx

I then installed termux-elf-cleaner to fix the pkgx binary:

pkg install termux-elf-cleaner

And ran it on the binary:

termux-elf-cleaner pkgx
termux-elf-cleaner: Changing TLS alignment for 'pkgx' to 64, instead of 8
termux-elf-cleaner: Replacing unsupported DF_1_* flags 134217729 with 1 in 'pkgx'

However, when trying to run pkgx again, I encountered missing shared library errors:

./pkgx
CANNOT LINK EXECUTABLE "/data/data/com.termux/files/home/.local/opt/pkgx/pkgx": library "libgcc_s.so.1" not found: needed by main executable

I then checked which shared libraries the pkgx binary requires:

readelf -d ./pkgx | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]

I couldn't find these libraries in a standard Termux installation.

Wouldn't it be better to build the pkgx binary with static linking rather than dynamic linking? This could potentially improve compatibility with environments like Termux, where the required shared libraries may not be available.

it's almost impossible to statically link those particular libraries. if you install rustc on your phone, are you able to build pkgx?

my guess is that it will require building most of the ecosystem from scratch if there's binary alignment issues. but you may be able to manually build packages on your system, if it is powerful enough.

Unfortunately, Termux does not provide the "rustc" package in its standard repositories, so I cannot directly test building pkgx on my phone using the native Rust compiler.

Perhaps you could try installing Termux on your Android phone and testing pkgx yourself to reproduce the issue. Termux is available on the Google Play Store, is very lightweight, and is easy to use.

This would help confirm whether the issue is specific to my device or a broader compatibility problem with Android.

@sabamdarif

@sabamdarif @agnostic-apollo @fornwall Could you help us to run the pkgx on Termux? Thanks!

This is completely unrelated to Termux, but I just wanted to say that whenever I need to run terminal and any other desktop programs in Android, I use DroidDeck nowadays.

It runs a Ubuntu "container" where pretty much everything works as expected (including pkgx).

Can make glibc work with pkg install glibc-repo and then pkg install glibc, but executable is probably not gonna work unless built for Android/Termux. I dont have experience with glibc, we normally compile packages against bionic, often packages require patches for Android too.

Termux does provide rust package with rustc compiler.

https://github.com/termux/termux-packages/tree/master/packages/rust

@cfgnunes

@cfgnunes , as agnostic-apollo explained earlier that you need to build all the packages against bionic libc and if pkgx wants to do that then they have to do the same things what termux is doing in the https://github.com/termux/termux-packages/, which will just duplicate the work, also building desktop linux package with bionic libc needs a lot of patching to do as this packages are meant to run on a glibc (or musl libc ) because a lot of glibc's features just doesn't exist on bionic libc, like for example locale.

And yes you can use the glibc-runner that termux have and might be able to run a lot of packages but it will not work in all cases.

so idk what will be best approach here to support pkgx.

Idk how pkgx actually works, but for android if they download the packages from termux's repo then it might work.

Navigation Menu

Repository navigation

platform support megaticket #607

Maybe

Architectures

Supported

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

platform support megaticket #607

Description

Maybe

Architectures

Supported

Activity

burdiyan commented on Jun 20, 2023

felipecrs commented on Sep 13, 2023

jhheider commented on Sep 13, 2023

felipecrs commented on Sep 13, 2023

jhheider commented on Sep 13, 2023

jhheider commented on Sep 13, 2023

felipecrs commented on Sep 13, 2023

Trung0246 commented on Oct 4, 2023

jhheider commented on Oct 4, 2023

mxcl commented on Oct 5, 2023

mxcl commented on Oct 17, 2023

burdiyan commented on Oct 18, 2023

13 remaining items

tannevaled commented on May 18, 2026

jhheider commented on May 18, 2026

tannevaled commented on May 19, 2026

jhheider commented on May 19, 2026

tannevaled commented on May 22, 2026

cfgnunes commented on Nov 13, 2026

jhheider commented on Nov 13, 2026

cfgnunes commented on Nov 13, 2026

jhheider commented on Nov 13, 2026

cfgnunes commented on Nov 13, 2026

cfgnunes commented on Nov 13, 2026

felipecrs commented on Nov 14, 2026

agnostic-apollo commented on Nov 14, 2026

sabamdarif commented on Nov 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions