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 :)

so how do i install it?

lol, what do you mean? pkgx is not supported on Windows yet. I supposed you knew that already since you said:

would be great if you can mention windows isn't supported on the site.

Your best bet for windows support at present is WSL2; since it's a full (enough) linux environment running inside your windows, everything we know of works in the appropriate linux way.

lol, what do you mean? pkgx is not supported on Windows yet. I supposed you knew that already since you said:

oh i thought since you mentioned curl.exe exists, so i thought installation worked haha.

yeah i dont use wsl2. i tried setting up one-time but gave up bcz of some errors. didnt try again. i'll wait for windows support without wsl like bun.sh :)

I was hoping that pkgx v2 would work on Alpine, but unfortunately it doesn't yet:

➜  ~ curl https://pkgx.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4805  100  4805    0     0   7547      0 --:--:-- --:--:-- --:--:--  7543
installing: /usr/local/bin/pkgx
######################################################################## 100.0%
Error relocating /usr/local/bin/pkgx: __res_init: symbol not found
Error relocating /usr/local/bin/pkgx: fcntl64: symbol not found

Coming at this from the consumer end: I just ported pkgm to Windows in pkgxdev/pkgm#87 and hit the wall that pkgm install <anything> returns Error: CmdNotFound("...") regardless of what pkgm itself does. Probed the dist bucket exhaustively — 0 of 842 top-level prefixes under dist.tea.xyz have a windows/ subdir, so pkgx on Windows can only fetch pkgx.exe itself (from pkgx.sh/Windows/x86_64.zip) and nothing else.

Wanted to share a snapshot of where each downstream piece sits so the discussion has concrete state to point at, and propose a pilot path.

Current state, layer by layer

Layer	State	Notes
`pkgx` CLI (Rust)	✅ Windows-ready	`#[cfg(windows)]` branches in `execve.rs` (Command::spawn replaces execve), `install.rs` (lockfile), `utils.rs::find_program` (looks up .exe→.bat→.cmd).
`libpkgx` (Rust)	⚠️ WIP per this ticket (libpkgx#48 v1-wip)	Used by `pkgx` itself with cfg-guards; the Deno bindings at `deno.land/x/libpkgx@v0.21.0` work on Windows for read-only operations (verified: `pkgm --version` runs end-to-end on `windows-latest`).
`pkgxdev/setup`	✅ Windows-ready	`installer.ps1` installs to `$env:LOCALAPPDATA\pkgx` and adds it to the user `PATH`. No system install, no UAC.
`pkgxdev/pantry` `get-matrix.ts`	❌ Hard veto	Throws `invalid platform` for any `windows/*` entry. PR proposed: pkgxdev/pantry#12946 — accept the opt-in without changing default behaviour. No-op for every package currently in the pantry.
`pkgxdev/brewkit` `build@v1`	⚠️ POSIX-shaped	Action uses `shell: bash` throughout (Git Bash works on Windows runners), but every script downstream assumes coreutils, codesign branches for macOS, etc. Not catastrophic but real porting work.
`dist.tea.xyz`	❌ Zero Windows artifacts	Direct consequence of brewkit not running on Windows runners.
`pkgm`	✅ Windows-ready (per #87)	`%LOCALAPPDATA%\pkgm` prefix, hardlink fallback for symlinks, `.cmd` stub wrappers, `PATH_SEP` awareness, `pkgx.exe` lookup. Smoke tests green.

So the order of operations is roughly: pantry planner → brewkit build → dist artifact → pkgx resolution → pkgm install. Today everything except brewkit-and-the-planner is essentially ready; the artefact pipeline is the choke point.

Concrete sub-tasks worth splitting out of this megaticket

pkgxdev/pantry — accept windows/x86-64 in get-matrix.ts (PR proposed). Risk-free, opt-in only.
pkgxdev/brewkit — add a Windows codepath to build@v1. The hard one. Open question: is the goal feature-parity with the POSIX build (autoconf/cmake-style pkgs), or only a subset?
pkgxdev/dist infrastructure — once brewkit can emit Windows tarballs, confirm the S3 bucket layout follows the same <project>/windows/x86-64/v<version>.tar.xz convention pkgx already expects.
libpkgx Resumable, parallel downloads #48 — status update would help downstream porters know what to expect.

Pragmatic pilot: cross-compile-friendly seed packages

Rather than a full brewkit-on-Windows port (which is months of work), a "Windows mini-build" path could unblock useful packages quickly. Packages whose package.yml build: script is essentially go build or cargo install --target x86_64-pc-windows-msvc cross-compile from a Linux runner without needing Windows at all — Go and Rust ship cross-compilers in their standard toolchain, and the GHA ubuntu-latest runner has both.

Candidate seed packages (all currently in pantry, all pure-Go or pure-Rust):

charm.sh/gum, sharkdp/fd, sharkdp/hyperfine, taskfile.dev, BurntSushi/ripgrep, bat, crates.io/zoxide, crates.io/dust

If brewkit grew a "cross-compile to Windows from Linux" mode for these, ~30-50% of the pantry's pure-Go/Rust packages could ship Windows builds without a Windows runner being involved at all. Real-Windows-runner work would then only be needed for C/C++/autoconf packages.

Happy to take on the pantry planner PR (already drafted), and to prototype the cross-compile pilot for one Go pkg if useful. The brewkit-side work is too deep into pkgxdev internals for me to volunteer blind — but if there's an existing design direction, pointers welcome.

cc: pkgxdev/pkgm#87

Probed the dist bucket exhaustively — 0 of 842 top-level prefixes under dist.tea.xyz have a windows/ subdir, so pkgx on Windows can only fetch pkgx.exe itself (from pkgx.sh/Windows/x86_64.zip) and nothing else.

the available windows packages are under v2/: https://dist.pkgx.dev/?prefix=v2/ . note that the work in manifests seems to have been rolled back a year ago, so we don't currently have infrastructure for building more.

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.)

ci(windows): correct comment block re: dist Windows state

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.

Navigation Menu

Repository navigation

platform support megaticket #607

Maybe

Architectures

Supported

4 remaining items

Current state, layer by layer

Concrete sub-tasks worth splitting out of this megaticket

Pragmatic pilot: cross-compile-friendly seed packages

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

4 remaining items

deadcoder0904 commented on Nov 17, 2023

felipecrs commented on Nov 17, 2023

jhheider commented on Nov 17, 2023

deadcoder0904 commented on Nov 18, 2023

felipecrs commented on Feb 13, 2025

tannevaled commented on May 18, 2026

Current state, layer by layer

Concrete sub-tasks worth splitting out of this megaticket

Pragmatic pilot: cross-compile-friendly seed packages

jhheider commented on May 18, 2026

tannevaled commented on May 18, 2026

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

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions