LeanCopilot: LeanInfer could not build when tested on Github Codespace

The issues were posted on Zulip, please check there for more context.

TL;DR

  1. Github Codespace can only compile after -stdlib=libc++ is removed
  2. lake build hangs indefinitely in linking, and it’s not using much CPU

Issue Details

I’ve tried out lean4-example in Github Codespace, I got the following issues:

  1. lake build fails to compile C++ with Clang++, resolved by removing all -stdlib=libc++from the lakefile of LeanInfer
lean4-example (improve-installation) $ lake build
[23/197] Compiling ffi.cpp
error: > clang++ -c -o ./lake-packages/LeanInfer/build/ffi.o ./lake-packages/LeanInfer/ffi.cpp -fPIC -std=c++11 -stdlib=libc++ -O3 -I /home/codespace/.elan/toolchains/leanprover--lean4---v4.0.0/include
error: stderr:
In file included from ./lake-packages/LeanInfer/ffi.cpp:1:
/home/codespace/.elan/toolchains/leanprover--lean4---v4.0.0/include/lean/lean.h:14:10: fatal error: 'atomic' file not found
#include <atomic>
         ^~~~~~~~
1 error generated.
error: external command `clang++` exited with code 1

I ran bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)" from https://apt.llvm.org/ to fix it, no change. Then I test the clang++ command with extra options -E -x c++ -v at the end, it showed the following search path:

ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/codespace/.elan/toolchains/leanprover--lean4---v4.0.0/include
 /usr/local/include
 /usr/lib/llvm-10/lib/clang/10.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

which is shorter than a raw clang++ -E -x c++ - -v < /dev/null 2>&1 which shows

ignoring nonexistent directory "/include"
ignoring duplicate directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9
 /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9
 /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward
 /usr/local/include
 /usr/lib/llvm-10/lib/clang/10.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

Clearly Clang++ stop looking for the GNU C++ headers if -stdlib=libc++ is present. If Github Codespace misses it I guess it would be missed in the environments of many end-users.

  1. After resolved issue 1, I end up having the same issue fatal error: 'onnxruntime_cxx_api.h' file not found, resolved by
( cd /workspace/ && wget https://github.com/microsoft/onnxruntime/releases/download/v1.15.1/onnxruntime-linux-x64-1.15.1.tgz && tar xzvf  onnxruntime-linux-x64-1.15.1.tgz)

Then add "-I", "/workspaces/onnxruntime-linux-x64-1.15.1/include" to flags in LeanInfer lakefile or just add CPATH environment variable as instructed.

  1. Run lake build after step 2, I have the same linker error libc++abi: terminating due to uncaught exception of type lean::exception: error loading library, libonnxruntime.so.1.15.1: cannot open shared object file: No such file or directory, I tried to fix it by adding "-L", "/workspace/onnxruntime-linux-x64-1.15.1/lib/" to moreLinkArgs then
LD_LIBRARY_PATH=/workspaces/onnxruntime-linux-x64-1.15.1/lib/ lake build

But the build hangs indefinitely, and it’s not using much CPU (❤️%). So far, I’m stuck here.

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Comments: 15 (8 by maintainers)

Most upvoted comments

The scripts work great, the build is successful without hassle.

Then I try to use the built LeanInfer in lean4-example, even after I set LD_LIBRARY_PATH and LIBRARY_PATH to /workspaces/onnxruntime-linux-x64-1.15.1/lib in Lean 4 Server Env then restart Lean server, Lean InfoView still shows:

error loading library, libonnxruntime.so.1.15.1: cannot open shared object file: No such file or directory

The only way I succeeded to get around this is to manually run

cp /workspaces/onnxruntime-linux-x64-1.15.1/lib/*.so* ~/.elan/toolchains/leanprover--lean4---v4.0.0/lib/

And wait a while, then I can successfully use suggest_tactics. 🎉

EDIT: I also tried adding onnxruntime to LEAN_PATH but still no luck.

Thanks! The building process is expected, and I’ll remove lake update.

@utensil Would you like to try the simplified installation process? https://github.com/yangky11/lean4-example/tree/LeanInfer-demo

I’ve just tested on Codespace and it works smoothly. All I ever need is only the line:

git lfs install && git clone https://huggingface.co/kaiyuy/onnx-leandojo-lean4-tacgen-byt5-small

for downloading the model, the rest is handled by VSCode Lean 4 extension.

There are some observations:

  1. lake update doesn’t seem to be required. It works without it and on Zulip this is usually disencouraged due to it might update some other dependencies (like Mathlib4) accidentally then make a mess.

  2. There’s still a building process and it takes a while. Mostly it builds Std, and it also builds and links LeanInfer, as shown below. Is this expected? It went very well without any hassle though.

Finally, celebration!

image

That’s great to hear! So it may even work for WSL. We didn’t test it though…

@yangky11 Thanks for your quick response and hard work! I had previously tried out the previous version, but I ran into the similar issue of the missing libonnxruntime.so.1.15.1 library. However, the new and simplified version fixed the bug and can now correctly display the list of suggested tactics in my VS code.

image

@utensil Would you like to try the simplified installation process? https://github.com/yangky11/lean4-example/tree/LeanInfer-demo

We encountered issue 2 during development. It’s likely related to GNU’s standard libraries. That was why we only worked with Clang and added the flag -stdlib=libc++ to prevent it from using GNu’s standard libraries. So you probably shouldn’t tell clang++ to use GNU’s version.

It’s not clear to me why GCC cannot compile LeanInfer while Clang can. The compilation process is too tricky for the end-users to get right, and I think the ultimate solution should be cloud build.