Python 3.8 reached end of life
Python 3.8 already reached EOL and no longer receives any security updates: https://devguide.python.org/versions/
Could you update LLVM (I think python 3.8 is used there) so that it will use latter version of it?
LLVM 18 will be available with platform tools release v1.43
Platform Tools release 1.43 still depends on libpython3.8.so.1.0:
$ ldd platform-tools-linux-x86_64/llvm/lib/liblldb.so.18.1-rust-dev
...
libpython3.8.so.1.0 => ...
...
I think it's all related to docker image being debian 9 which is also not maintained anymore: https://github.com/anza-xyz/platform-tools/blob/3837a8df7967e65c9ee3dc7a83b76293362e0836/Dockerfile#L4
I guess the reason for that is we are still using Ubuntu 20 to build the release binaries. Let me update the workflow file.
Closing it by #82.
Hey @LucasSte! Could you :pray: make a new release as well then?
Hey @LucasSte! Could you 🙏 make a new release as well then?
A new release takes between one and two months to reach developers, if you use platform tools from the Solana SDK or the Agave releases. If you need something sooner, I suggest you build the tools from source.
It would be nice to have a new release. 1.43 was released ~2 months ago and Rust now has the 1.82 version.
It would be nice to have a new release.
1.43was released ~2 months ago and Rust now has the1.82version.
There will be a new release in the coming weeks with bug fixes and better code generation. We try to update the Rust version at every four or five releases. It usually takes two weeks of work to bring these updates, so they aren't so often.
Thanks! I'm looking forward to it!
bash-5.1$ ls
clang liblldb.so liblldb.so.17-rust-dev python3.8
libc.a liblldb.so.17.0.6-rust-dev libm.a
bash-5.1$ cd python3.8/site-packages/lldb/
bash-5.1$ stat lldb-argdumper
File: lldb-argdumper -> ../../../../bin/lldb-argdumper
Size: 30 Blocks: 0 IO Block: 4096 symbolic link
Device: fc01h/64513d Inode: 86916371 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 1000/ dz) Gid: ( 1000/ dz)
Access: 2024-11-22 22:22:41.595267980 +0000
Modify: 2024-08-02 17:06:06.000000000 +0100
Change: 2024-11-22 22:22:41.595267980 +0000
Birth: 2024-11-22 22:22:41.595267980 +0000
bash-5.1$ realpath lldb-argdumper
/home/dz/github.com/Layer-N/nord/llvm/bin/lldb-argdumper
bash-5.1$ cd ..
bash-5.1$ cd ..
bash-5.1$ cd ..
bash-5.1$ cd ..
bash-5.1$ cd bin/
bash-5.1$ ls
clang llc lld-link solana_commands
clang++ lld llvm-ar solana-lldb
clang-17 lldb llvm-objcopy solana_lookup.py
clang-cl lldb_commands llvm-objdump solana_providers.py
clang-cpp lldb_lookup.py llvm-readelf solana_types.py
ld64.lld lldb_providers.py llvm-readobj
ld.lld lldb-vscode rust_types.py
bash-5.1$
also Python38 kind of was removed, there is Python38 directory in release archieve, which has broken link, which breaks some custom unpack tooling
UPDATE:
would be nice test for release to unpack and check all files resolve to something
I updated the release package, so it should have python 3.10.
Yeah, trying. But so not sure that lldb-argdumper is correct link from python 3.10 directory.
@LucasSte 1.83 has been published. Please let me know if there's anything I can do to help move the new release forward.
@c410-f3r Updating the Rust version is a very time-consuming and tedious process. We only do it at every four or five Rust releases.
Briefly speaking, you need to rebase our LLVM fork, do the same for our Rust fork and again for our compiler builtins fork. It is time consuming due to the amount of conflicts you'll need to solve. Sometimes, you need to go back to LLVM and implement missing instructions that were added, so it takes a bunch of time.
If you are interested in following this process, you are more than welcome to do it. We can exchange Discord handles, and I can give you more guidance.
@LucasSte Thank you for the explanation.
LLVM (solana-rustc/18.1-2024-05-19): This branch is 180230 commits ahead of, 6 commits behind Rust (solana-1.79.0): This branch is 149 commits ahead of, 18119 commits behind Compiler builtins (solana-0.1.112) : This branch is 3 commits ahead of, 241 commits behind
I am familiar with the rustc codebase but it seems to be the most offending synchronization.
Rebase is probably feasible on my side but I can't ensure green tests. For what it is worth, that is at least half-way done.
@c410-f3r
I apologize the bad wording. I said rebase, but you actually must fetch the newest branch from rust 1.83 and cherry pick all of our commits there. Check which llvm branch rust 1.83 is using and then cherry-pick all our commits. Likewise for compiler-builtins.
For Rust, you fetch the tag https://github.com/rust-lang/rust/tree/1.83.0 and then cherry pick all commits. For LLVM, you get the branch rustc/19.1-2024-09-17 from the rust LLVM fork and then cherry pick all commits.
Thanks! I will hopefully reach back in the near future with good news.