Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build error with wasm32-wasi: system `wasi' not recognized #271

Open
brandonchinn178 opened this issue Jan 30, 2023 · 11 comments
Open

Build error with wasm32-wasi: system `wasi' not recognized #271

brandonchinn178 opened this issue Jan 30, 2023 · 11 comments

Comments

@brandonchinn178
Copy link

I'm trying to build unix with wasm32-wasi-cabal using my new ghc-wasm-backend Docker image, and I'm getting this error:

checking host system type... Invalid configuration `wasm32-wasi': system `wasi' not recognized
configure: error: /bin/bash //tmp/cabal-install.-10744/dist-newstyle/tmp/src-10745/unix-2.8.0.0/config.sub wasm32-wasi failed

Any idea what's wrong?

Repro:

  1. docker pull brandonchinn178/ghc-wasm-backend:2b62739d7e6cc65f444029f252578f2dddb95ce3
  2. docker run --rm -it --entrypoint bash brandonchinn178/ghc-wasm-backend:2b62739d7e6cc65f444029f252578f2dddb95ce3
  3. wasm32-wasi-cabal update
  4. wasm32-wasi-cabal install ormolu --allow-newer='template-haskell' --allow-newer=base --allow-newer=ghc-prim --allow-newer=unix (or install some other library depending on unix)
@Bodigrim
Copy link
Contributor

Does the CI configuration we use shed any light? Can you run it in your environment?

- name: setup-ghc-wasm32-wasi
run: |
pushd $(mktemp -d)
curl -L https://gitlab.haskell.org/ghc/ghc-wasm-meta/-/archive/master/ghc-wasm-meta-master.tar.gz | tar xz --strip-components=1
./setup.sh
~/.ghc-wasm/add_to_github_path.sh
popd
- uses: actions/checkout@v3
- name: test
run: |
cp ~/.ghc-wasm/wasi-sdk/share/misc/config.* .
autoreconf -i
wasm32-wasi-cabal --project-file=cabal.project.wasm32-wasi build
./test-wasm32-wasi.mjs

CC @TerrorJack

@brandonchinn178
Copy link
Author

I saw that, but I don't think it does. Because I'm on aarch64, I can't use setup.sh, but I followed the manual instructions in ghc-wasm-meta to create the Dockerfile; I linked it above, feel free to audit.

I get the error whether or not I source ~/.ghc-wasm/env, which is the only thing I can think of.

I didn't do these steps though:

cp ~/.ghc-wasm/wasi-sdk/share/misc/config.* .
autoreconf -i

I'm not sure how I would do it manually, since I'm not configuring unix myself; Cabal should be doing that

@Bodigrim
Copy link
Contributor

Could you try and build unix alone from the source code, same as our CI does? That might be a helpful data point, proving that your setup is correct and that unix itself has not been broken by recent changes.

Another question is why your build is reinstalling unix at all? It's a boot package and it should come preinstalled with GHC. Could you be more precise with allow-newer?

@brandonchinn178
Copy link
Author

I tried, but wasm32-wasi-cabal install --lib unix exits immediately with "Up to date", which is probably what you're alluding to in the second point.

I was also curious about that. Maybe I need to point to some package db? Let me investigate more when I'm back at my computer

@Bodigrim
Copy link
Contributor

Try wasm32-wasi-cabal install ormolu -w ghc-9.6 --dry-run --allow-newer='template-haskell' --allow-newer=base --allow-newer=ghc-prim --allow-newer=unix --constraint 'unix installed' --allow-newer='ghc-lib-parser:transformers' or similar. The key point is to pass --constraint 'unix installed'.

@bgamari
Copy link
Contributor

bgamari commented Jan 30, 2023

checking host system type... Invalid configuration `wasm32-wasi': system `wasi' not recognized

I am nearly certain that this is an autoconf error; specifically the configure script does not recognize the host system triple. I would guess that this is because the configure script currently in the tree is too old to have wasi support.=

I didn't do these steps though: ...

My guess is that one of these two steps will fix your issue. @TerrorJack, I'm a bit unclear on why these manual steps are necessary; can't we simply update to autoconf 2.70, which should already have wasi support?

@hasufell
Copy link
Member

can't we simply update to autoconf 2.70, which should already have wasi support?

Note that there were several issues with autoconf 2.70 in the network package. Although they seem to be mostly windows related, I'd be careful with bumping either way: haskell/network#508

@brandonchinn178
Copy link
Author

I think I got it working with both --allow-newer='ghc-lib-parser:transformers' and --constraints='unix installed'. Why isn't the solver using unix installed by default? I would expect that if CMD --constraints='PKG installed' works, CMD by itself would use PKG installed.

@TerrorJack
Copy link
Contributor

I do believe we need to bump the autoconf scripts in this repo. Or land a wasi-specific patch, but that's much less ideal..

@bgamari
Copy link
Contributor

bgamari commented Jan 30, 2023

I think I got it working with both --allow-newer='ghc-lib-parser:transformers' and --constraints='unix installed'. Why isn't the solver using unix installed by default?

@brandonchinn178, my understanding is that the solver should use the pre-existing package by default if the plan's constraints will allow it. I would try looking at cabal-install's -v3 output to see why the pre-existing package is ruled out

@brandonchinn178
Copy link
Author

Ok got it working with

--allow-newer=Cabal-syntax
--constraint='transformers installed'
--allow-newer=ghc-lib-parser:transformers

Firstly, Cabal-syntax currently pins unix < 2.8 on Hackage, so --allow-newer=Cabal-syntax is needed to allow using the installed unix-2.8.0.0.

Secondly, we need to explicitly constraint transformers installed because apparently GHC is using transformers-0.6.0.4 as a boot library, but 0.6.0.4 is a deprecated version, so Cabal doesn't include it in the constraint solver.

Lastly, ghc-lib-parser currently has transformers < 0.6, so --allow-newer=ghc-lib-parser:transformers is necessary


But it also sounds like there's an issue with the autoconf script in this repo, so I'll leave this issue open. Feel free to close when appropriate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants