Closed dslm4515 closed 11 months ago
Btw, i had use an older commit of mussel to avoid the b3sum issue:
cd mussel
git checkout 26c50d6362731bc54ca9f92ac31b3f95e885c3c7
Definitely will have to check this in the future, and update the script to work with both implementations of b3sum
.
In the meanwhile, I am keeping this open, so please let's track any updates regarding the use of LLVM/Clang with mussel here.
Stage0 LLD [of CMLFS] fails to compile:
Error loading shared library libstdc++.so.6: No such file or directory (needed by /mnt/cmlfs/sources/llvm-project-15.0.6.src/build/bin/llvm-tblgen)
Error loading shared library libgcc_s.so.1: No such file or directory (needed by /mnt/cmlfs/sources/llvm-project-15.0.6.src/build/bin/llvm-tblgen)
Looks like there are no libraries in /cgnutools/x86_64-pc-linux-musl/lib
LLD compiles if missing libraries are symlinked:
ln -sv ../../lib/libstdc++.so.6.0.30 /cgnutools/x86_64-pc-linux-musl/lib/libstdc++.so.6
ln -sv ../../lib/libgcc_s.so.1 /cgnutools/x86_64-pc-linux-musl/lib/libgcc_s.so.1
I don't remember if I had this issue on my [Forked-]LFS system... as in if those libraries were misplaced when building mussel.
Well most of your issues are related to using custom paths for your projects.
As long as the majority of the building process in the script is working, then you can modify it or fine-tune it to fit your needs.
It's a plain shell script that is documented and easy to understand.
That being said, if you can group all your changes into a patch, I can try and see if I can merge them into main or a custom branch.
I got my CMLFS system up with LLVM-15.0.6. Mussel fails at part 3, cross-gcc:
configure: error: *** A compiler with support for C+11 language features is required.
LLVM is installed in /usr
and elftoolchain installed instead of binutils.
Cross-gcc might have failed because of it expects as
from binutils. I can build GCC with clang, but it requires binutils:
GCC requires as (assembler) from binutils as LLVM's llvm-as isn't a
100% drop-in replacement for binutils' (unsupported arguments)
...as I was able to build GCC with clang and binutils
I finally got cargo+rustc to run on CMLFS [technically, rustc was precompiled from Chimera Linux: I can compile cargo, but not rustc]. Now I have b3sum... from https://blake3.io.
.. Fetching binutils-2.41.tar.lz...
binutils-2.41.tar.lz 100%[==================================>] 25.09M 9.78MB/s in 2.6s
.. Verifying binutils-2.41.tar.lz...
b3sum: Invalid space
b3sum: WARNING: 1 computed checksum did NOT match
!. binutils-2.41.tar.lz is corrupted, redownloading...
binutils-2.41.tar.lz 100%[==================================>] 25.09M 8.51MB/s in 2.9s
.. Unpacking binutils-2.41.tar.lz...
=> binutils-2.41.tar.lz prepared.
Am I using the wrong implementation of b3sum?
I finally got cargo+rustc to run on CMLFS [technically, rustc was precompiled from Chimera Linux: I can compile cargo, but not rustc]. Now I have b3sum... from https://blake3.io.
.. Fetching binutils-2.41.tar.lz... binutils-2.41.tar.lz 100%[==================================>] 25.09M 9.78MB/s in 2.6s .. Verifying binutils-2.41.tar.lz... b3sum: Invalid space b3sum: WARNING: 1 computed checksum did NOT match !. binutils-2.41.tar.lz is corrupted, redownloading... binutils-2.41.tar.lz 100%[==================================>] 25.09M 8.51MB/s in 2.9s .. Unpacking binutils-2.41.tar.lz... => binutils-2.41.tar.lz prepared.
Am I using the wrong implementation of b3sum?
That's the correct version of b3sum
, from what you posted it downloaded the file correctly again and extracted it. Perhaps a corrupted initial download?
Perhaps a corrupted initial download?
Doesn't look like it. Its a warning, so perhaps just formatting syntax.
mussel.sh
stopped at gcc-cross. Looks like ISL wont compile under clang.
So I modified mussel.sh
to not unpack ISL. ... <-- may need to detect clang in order to trigger this.
So far gcc-cross is compiling!
If successful, I'll post the edits to mussel.sh
'mussel.sh' stops at:
=> cross-gcc (compiler) finished.
.. Preparing musl...
.. Configuring musl...
.. Building musl...
Per log:
x86_64-pc-linux-musl-ar rc lib/libm.a
make: x86_64-pc-linux-musl-ar: No such file or directory
make: *** [Makefile:172: lib/libm.a] Error 127
make: *** Waiting for unfinished jobs....
x86_64-pc-linux-musl-ar rc lib/librt.a
make: x86_64-pc-linux-musl-ar: No such file or directory
make: *** [Makefile:172: lib/librt.a] Error 127
Looks like it just needs a compatibility link:
ln -sv x86_64-pc-linux-musl-gcc-ar $MPREFIX/bin/x86_64-pc-linux-musl-ar
ln -sv x86_64-pc-linux-musl-gcc-ranlib $MPREFIX/bin/x86_64-pc-linux-musl-ranlib
Here is the patch i made to allow mussel to compile under clang: mussel-dont-compile-isl.patch
It's been tested on a CMLFS system. Patch just removes the building of ISL and adds two symlinks for 'missing' ar
and ranlib
tools
Btw, i had use an older commit of mussel to avoid the b3sum issue:
cd mussel git checkout 26c50d6362731bc54ca9f92ac31b3f95e885c3c7
I think this is fixed by #15 anyway, no need to get an older version.
Fixed as of #15 (thanks @takusuman), closing...
My CMLFS system has LLVM & elftoolchain as default compiler and binary tools [and system libc is musl]. From my experience, GCC has to be built with binutils and not elftoolchain. My CMLFS system was able to build GCC with LLVM and binutils. I have not tried compiling mussel without GCC yet. Perhaps this experience of mine may be useful for this repo.
I installed GCC, mpc, mpfr, and binutils in
/opt/gnu
. GMP is installed in/usr
. CPU architecture isx86_64
. I had to do the following to compile mussel without errors:/cgnutools
, so I modified mussel script to setMPREFIX="/cgnutools"
x86_64-pc-linux-musl-ranlib
,x86_64-pc-linux-musl-ar
... these are linked tox86_64-pc-linux-musl-gcc-ar
andx86_64-pc-linux-musl-gcc-ranlib
... otherwise mussel fails to build musl libc due to 'missing' those two binaries.sudo -E CC=/opt/gnu/bin/gcc CXX=/opt/gnu/bin/g++ ./mussel.sh x86_64 -l -o -k -p
/cgnutools
I am planning to release 3.0.0 of CMLFS that uses mussel to bootstrap the toolchain. I wanted to see if a completed CMLFS system can rebuild itself...