wasm-ld: error: unable to find library -lc++ about wavix HOT 5 CLOSED

Hi Andrew/ Thomas,

Sorry to butt in but I happened to talk briefly with Thomas about this and thought I'd share my experience building the toolchain for my own work. Obviously YMMV and feel free to ignore me if this isn't useful!

From what I can see, the waterfall script checks out the latest version of everything, hence won't always guarantee a working toolchain (you can see the status here: https://wasm-stat.us/console, broken at time of writing). I found adding a step to check out the last good revision of all the tools helps (see here for the LKGRs), i.e.:

# Check everything out
build.py --no-build --no-tool-tests --no-test

# Do some work to check out the last known good revision

# Run the actual build
build.py --no-sync

This is a bit fiddly, so would be worth scripting somehow. Until you know you're building good revisions I found it hard to debug things.

For my own work I created a Docker image with everything pre-built. The repo and info can be found here: https://github.com/Shillaker/wasm-toolchain. The image is public so you should just be able to run something like:

docker run -v $(pwd):/work -w /work -it shillaker/wasm-toolchain

# Inside newly created container
/toolchain/bin/clang -v

This then gives easy access to a fully built wasm-ready toolchain. The downside to this approach is that it doesn't include any of the Wavix modifications as it's built for my own work on a project called "faasm" (https://github.com/lsds/Faasm) so is a bit useless, however, I thought some of the ideas/ code might be useful.

As I say, sorry to interject and ignore me if none of this is useful.

from wavix.

I'm traveling, so I can't test this hypothesis, but it looks like what it happening is that cmake is trying to test that clang can compile a trivial program. However, it hasn't yet compiled libcxx or libcxxabi, and it doesn't pass -nostdlib when compiling the trivial program, so it fails.

I think this might be because I removed something that was setting CMAKE_CXX_COMPILER_WORKS=1 in the Wavix cmake toolchain file, and it kept working for me because an old version of the library was already installed.

Try adding -DCMAKE_CXX_COMPILER_WORKS=1 to the compiler-rt, libcxxabi, and libcxx cmake configuration commands in build.py and see if that fixes the problem.

From what I can see, the waterfall script checks out the latest version of everything, hence won't always guarantee a working toolchain

This isn't a problem with the Wavix fork of the waterfall scripts, since they just build the snapshots of the upstream repos that have been pulled into subtrees of the Wavix repo. I have occasionally seen upstream breakage when pulling the master branch of the upstream repos, though. Once the LLVM WebAssembly support is more mature, I'll probably switch to pulling from the release branches of those repos.

from wavix.

I've created what should be a working Dockerfile including the CMAKE_CXX_COMPILER_WORKS tweak and a fix for a very small case-sensitivity issue in build.py.

Can be seen in this PR: #2 @thomasknauth that should work.

If the Dockerfile is useful it could be good to push the built image to Dockerhub (e.g. under wavix/toolchain) so that people can pull it directly and avoid the build process.

from wavix.

I pushed an image to Docker with the built toolchain here: https://hub.docker.com/r/wavm/wavix/

I'd like to figure how to automate keeping it up to date before directing new users to it, though. I don't think Travis allows jobs to run long enough to build the image.

from wavix.

(this issue should be fixed by 758caee)

from wavix.