add wildcard to match the correct file

emrakyz commented 9 months ago

There is no file or link as: /cgnutools/bin/gcc/ bash: /cgnutools/bin/gcc: No such file or directory

All of the files in /cgnutools/bin/ has this prefix: "x86_64-pc-linux-musl-"

So the wildcard will match "x86_64-pc-linux-musl-gcc"

dslm4515 commented 9 months ago

If I check for gcc binaries in the cgnutools/bin that I built:

$ ls /cgnutools/bin/*gcc*
/cgnutools/bin/gcc
/cgnutools/bin/gcc-ar
/cgnutools/bin/gcc-nm
/cgnutools/bin/gcc-ranlib
/cgnutools/bin/x86_64-pc-linux-musl-gcc
/cgnutools/bin/x86_64-pc-linux-musl-gcc-12.2.0
/cgnutools/bin/x86_64-pc-linux-musl-gcc-ar
/cgnutools/bin/x86_64-pc-linux-musl-gcc-nm
/cgnutools/bin/x86_64-pc-linux-musl-gcc-ranlib

I also checked my 32-bit build on my older laptop:

$ ls /cgnutools/bin/*gcc* 
/cgnutools/bin/gcc
/cgnutools/bin/gcc-ar
/cgnutools/bin/gcc-nm
/cgnutools/bin/gcc-ranlib
/cgnutools/bin/i686-pc-linux-musl-gcc
/cgnutools/bin/i686-pc-linux-musl-gcc-12.2.0
/cgnutools/bin/i686-pc-linux-musl-gcc-ar
/cgnutools/bin/i686-pc-linux-musl-gcc-nm
/cgnutools/bin/i686-pc-linux-musl-gcc-ranlib

I think I have seen this in my past failed attempts to build cgnutools. Once, I built cgnutools, and there was no gcc binary. But there was x86_64-pc-linux-musl-gcc or x86_64-pc-linux-musl-gcc-ranlib. This was a sign that GCC in cgnutools was not built right.

dslm4515 commented 9 months ago

$ /cgnutools/bin/gcc --version
gcc (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

emrakyz commented 9 months ago

Oh, you are completely right. The compiler fails to run the dummy code. So it wasn't built correctly.

But why would it not build correctly? The script works perfectly without any errors. My environment seems ready.

What would be the problem here? I will also explain what I have done:

Here is the checks:

cmlfs@(none) /mnt/cmlfs/sources/mussel $ echo $SHELL
file /bin/sh
file /usr/bin/awk
file /usr/bin/yacc
which flex
./check.sh 
/bin/bash
/bin/sh: symbolic link to /bin/bash
/usr/bin/awk: symbolic link to gawk
/usr/bin/yacc: symbolic link to yacc.bison
/usr/bin/flex
bash:      5.2.15(1)-release
bc:        1.07.1
binutils:  2.41 p2) 2.41.0
bison:     3.8.2
bzip2:     1.0.8
ccache:    4.8.3
coreutils: 9.4
diffutils: 3.10
findutils: 4.9.0
g++:       13.2.1_p20230826
gawk:      5.2.2
gcc:       13.2.1_p20230826
git:       2.42.0
glibc:     releas
grep:      3.11
gzip:      1.13
linux:     6.5.5-gentoo
lzip:      1.23
m4:        1.4.19
make:      4.4.1
perl:      5.38.0
rsync:     3.2.7
sed:       4.9
tar:       1.35
texinfo:   7.0.3
xz:        5.4.4
zstd:      Yann

Here is my method:

cd $CMLFS/sources
git clone https://github.com/firasuke/mussel

cd mussel
git checkout 26c50d6362731bc54ca9f92ac31b3f95e885c3c7

sed -i '49d' mussel.sh && \
sed -i '49 i mpfr_url=https://ftp.gnu.org/gnu/mpfr/mpfr-$mpfr_ver.tar.xz' mussel.sh

sed -i '70d' mussel.sh && \
sed -i '70 i MPREFIX="/cgnutools"' mussel.sh && \
sed -i '71d' mussel.sh && \
sed -i '71 i MSYSROOT="/cgnutools"' mussel.sh

patch -Np0 -i ../patches/mussel-add-vendor-set-sysroot.patch

# I build ISL because I have GCC. I have also tried not building them.

patch -Np1 -i ../patches/mussel-add-missing-symlinks.patch

sudo ./mussel.sh $(uname -m) -l -o -k -p
# Everything works perfect without a problem with the above command.

sudo chown -vR cmlfs:cmlfs $CMLFS/cgnutools

mv -v /cgnutools/usr/lib/*     /cgnutools/lib/
mv -v /cgnutools/usr/include/* /cgnutools/include/
rm -rfv /cgnutools/usr/{include,lib}
ln -sv ../lib     /cgnutools/usr/lib
ln -sv ../include /cgnutools/usr/include

rm -rf  /cgnutools/share/man

# BELOW COMMAND FAILS BECAUSE THERE IS NO "/cgnutools/bin/gcc"

export MCGV=$(/cgnutools/bin/gcc  --version | sed 1q | cut -d' ' -f3- )
/cgnutools/bin/${TARGET_TUPLE}-gcc -dumpspecs | sed 's/\/lib\/ld-musl/\/cgnutools\/lib\/ld-musl/g' > /cgnutools/lib/gcc/${TARGET_TUPLE}/$MCGV/specs

emrakyz commented 9 months ago

@dslm4515

To add more context:

Here is .bash_profile: exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\n\$ ' /bin/bash

Here is .bashrc:

set +h
umask 022
CMLFS=/mnt/cmlfs
LC_ALL=POSIX
PATH=/cgnutools/bin:/llvmtools/bin:/bin:/usr/bin
export CMLFS LC_ALL PATH
unset CFLAGS
unset CXXFLAGS
export LLVMSRC="/mnt/cmlfs/sources/llvm"

export CMLFS_TARGET="x86_64-cmlfs-linux-musl"
export TARGET_TUPLE="x86_64-pc-linux-musl"
export   CMLFS_ARCH="x86"
export    CMLFS_CPU="x86-64"
export          MCA="x86_64"
export   CMLFS_HOST="x86_64-cross-linux-gnu"

mussel.sh terminates earlier I guess with no extra errors:

.. Applying 0001-pure64-for-x86-64.patch from glaucus for gcc...
=> gcc patched with 0001-pure64-for-x86-64!

.. Cleaning builds directory...
=> builds cleaned.

.. Preparing musl headers...
.. Installing musl headers...
=> musl headers finished.

.. Preparing cross-binutils...
.. Configuring cross-binutils...
.. Building cross-binutils...
.. Installing cross-binutils...
=> cross-binutils finished.

.. Preparing cross-gcc (compiler)...
.. Configuring cross-gcc (compiler)...
.. Building cross-gcc (compiler)...
.. Installing cross-gcc (compiler)...

.. Building cross-gcc (libgcc-static)...
.. Installing cross-gcc (libgcc-static)...
=> cross-gcc (libgcc-static) finished.

=> cross-gcc (compiler) finished.

.. Preparing musl...
.. Configuring musl...
.. Adding assembler link ...

dslm4515 commented 9 months ago

mussel generates a log (log.txt) at the root of the mussel directory. Check at the end of the log file to see if there are errors. You can try:

$ grep Error /mnt/cmlfs/sources/mussel/log.txt

emrakyz commented 9 months ago

Here is the actual error from the log.txt: ln: failed to create symbolic link '/cgnutools/bin/x86_64-pc-linux-musl-ar': File exists

Here is the full log.txt: http://0x0.st/HWJc.txt

dslm4515 commented 9 months ago

Interesting! Both of my build machines [a non-Intel branded NUC and an old HP laptop] required the the symlinks for "missing" binaries. For reference, commit 4a6912430ee4db54ee1a53f0db9d6263faafd2f6 . One is running CMLFS and the other an old build of MLFS.

Therefore, I propose that it be conditional: If the binaries are missing then create the links; Otherwise, do not create the links.

emrakyz commented 9 months ago

I'll try and inform you in a short time.

dslm4515 commented 9 months ago

I've been using MLFS as my daily driver since 2017, so I don't have any machines running GlibC-based distro.

emrakyz commented 9 months ago

Please continue to do so! :)

I really want to make this my daily driver. It's an extremely brilliant idea to use robust, minimal tools and combine the best aspects of specific environments together from BSD, Linux, Busybox, S6 and Musl.

By the way the last change (not using sym-link patch) worked: => Done! Enjoy your new x86-64 cross compiler targeting musl libc!

I still needed to use the wildcard though. There is still no /cgnutools/bin/gcc

I use the wildcard and it could run the dummy code.

emrakyz commented 9 months ago

Strange errors. If it would help, I can setup a clean Clang/Musl only Gentoo machine for host and start over?

cmlfs@(none) /mnt/cmlfs/sources/pkgs/llvm-project-15.0.6.src $ ninja -C build llvm-tblgen
ninja: Entering directory `build'
ninja: no work to do.

cmlfs@(none) /mnt/cmlfs/sources/pkgs/llvm-project-15.0.6.src $ ninja -C build lld build_lld.txt

dslm4515 commented 9 months ago

I think I forgot to configure the ld-musl-$ARCH.path for cgnutools.

Looks like library path not set:

Error loading shared library libstdc++.so.6: No such file or directory (needed by /mnt/cmlfs/sources/pkgs/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/pkgs/llvm-project-15.0.6.src/build/bin/llvm-tblgen)

Perhaps, the rpath was net set when running cmake?


# Built llvm-tblgen will need libstdc++.so.6 & libgcc_s.so.1.
# Set the rpath
export  CFLAGS='-fPIC -I/cgnutools/include -Wl,-rpath=/cgnutools/lib '
export CXXFLAGS=$CFLAGS

Check if libstdc++.so.6 & libgcc_s.so.1 are present in /mnt/cmlfs/cgnutools/lib

emrakyz commented 9 months ago

cmlfs@(none) /mnt/cmlfs/sources/pkgs/llvm-project-15.0.6.src $ echo $CFLAGS -fPIC -I/cgnutools/include -Wl,-rpath=/cgnutools/lib

[/mnt/cmlfs/cgnutools]$ find /mnt/cmlfs -type f -name "libgcc_s.so.1"

/mnt/cmlfs/cgnutools/x86_64-pc-linux-musl/lib/libgcc_s.so.1
/mnt/cmlfs/sources/mussel/builds/cross-gcc/gcc/libgcc_s.so.1
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-pc-linux-musl/libgcc/libgcc_s.so.1

[/mnt/cmlfs/cgnutools]$ find /mnt/cmlfs -type f -name "libstdc++.so.6" <no results>

dslm4515 commented 9 months ago

Must be why gcc is missing from your cgnutools. The standard C++ library [libstdc++] wasnt built.

Post the log.txt of your built toolchain from mussel. I might be able to find out why.

emrakyz commented 9 months ago

Here it is:

http://0x0.st/HWya.txt

dslm4515 commented 9 months ago

I ran diff to see any differences in our mussel logs Might not be useful as I was compiling on a previous build of CMLFS [Currently revising llvm-15.0.6 version of CMLFS to release CMLFS-3.0.1. Then I am going to develop CMLFS with LLVM-16.06 as either 3.1.0 or 4.0.0]

I will probably setup a glibc box and test. Then I can run diff on our logs and see what differs.

For the mean time, can you run the latest mussel script without modification? See if it lacks a built gcc and has missing libstdc++ and libgcc_s.

Side Note: You're compiling on an i7-990K! Stage 0 clang takes 70mins on my old dual core off-brand NUC. I bet takes that i7 10-15 mins to compile mussel?

emrakyz commented 9 months ago

I have overclocked i9 9900k (5.2ghz). It has 8 cores and 16 threads.

It takes couple minutes :D Fetching the packages takes longer.

I will compile Mussel main repo without any patch or anything, only using current .bashrc. Okay.

emrakyz commented 9 months ago

Still no /cgnutools/bin/gcc file. But I guess I can find related files now.

cmlfs@(none) /mnt/cmlfs/sources/mussel $ find /mnt/cmlfs/ -type f -name "*libstd*"

/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++exp.la
/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++fs.la
/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++.so.6.0.32
/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++fs.a
/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++exp.a
/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++.a
/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++.la
/mnt/cmlfs/cgnutools/x86_64-linux-musl/lib/libstdc++.so.6.0.32-gdb.py
/mnt/cmlfs/sources/mussel/sources/gcc/gcc-13.2.0/config/libstdc++-raw-cxx.m4
/mnt/cmlfs/sources/mussel/sources/gcc/gcc-13.2.0/maintainer-scripts/generate_libstdcxx_web_docs
/mnt/cmlfs/sources/mussel/sources/gcc/gcc-13.2.0/maintainer-scripts/update_web_docs_libstdcxx_git
/mnt/cmlfs/sources/mussel/sources/gcc/gcc-13.2.0/libitm/testsuite/libitm.c++/libstdc++-pr91488.C
/mnt/cmlfs/sources/mussel/sources/gcc/gcc-13.2.0/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
/mnt/cmlfs/sources/mussel/sources/gcc/gcc-13.2.0/libstdc++-v3/testsuite/lib/libstdc++.exp
/mnt/cmlfs/sources/mussel/sources/gcc/gcc-13.2.0/libstdc++-v3/po/libstdc++.pot
/mnt/cmlfs/sources/mussel/sources/binutils/binutils-2.41/config/libstdc++-raw-cxx.m4
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/libstdc++-symbols.ver
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/filesystem/libstdc++fs.la
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/filesystem/.libs/libstdc++fs.a
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/filesystem/.libs/libstdc++fs.lai
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/libstdc++convenience.la
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/libstdc++.la
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/stamp-libstdc++convenience
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/experimental/libstdc++exp.la
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/experimental/.libs/libstdc++exp.a
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/experimental/.libs/libstdc++exp.lai
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/.libs/libstdc++convenience.a
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/.libs/libstdc++.so.6.0.32
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/.libs/libstdc++.lai
/mnt/cmlfs/sources/mussel/builds/cross-gcc/x86_64-linux-musl/libstdc++-v3/src/.libs/libstdc++.a

Steps to reproduce:

su -

mkdir -pv /mnt/cmlfs
export CMLFS=/mnt/cmlfs

mkdir -v $CMLFS/cgnutools
mkdir -v $CMLFS/llvmtools
ln -sv   $CMLFS/cgnutools /
ln -sv   $CMLFS/llvmtools /

mkdir -pv $CMLFS/sources/{patches,files,pkgs}

chmod -vR a+wt  $CMLFS/sources

./download_sources.sh sources.list sources.md5

groupadd cmlfs
useradd -s /bin/bash -g cmlfs -m -k /dev/null cmlfs
passwd cmlfs

chown -v  cmlfs $CMLFS/cgnutools
chown -v  cmlfs $CMLFS/llvmtools
chown -vR cmlfs $CMLFS/sources

su - cmlfs

cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\n\$ ' /bin/bash
EOF

cat > ~/.bashrc << "EOF"
set +h
umask 022
CMLFS=/mnt/cmlfs
LC_ALL=POSIX
PATH=/cgnutools/bin:/llvmtools/bin:/bin:/usr/bin
export CMLFS LC_ALL PATH
EOF

source ~/.bash_profile

unset CFLAGS
unset CXXFLAGS
cat >> ~/.bashrc << EOF
unset CFLAGS
unset CXXFLAGS
EOF

cat >> ~/.bashrc << EOF
export LLVMSRC="/mnt/cmlfs/sources/llvm"
EOF

case $(uname -m) in
   x86_64)    export CMLFS_TARGET="x86_64-cmlfs-linux-musl"
              export TARGET_TUPLE="x86_64-pc-linux-musl"
              export   CMLFS_ARCH="x86"
              export    CMLFS_CPU="x86-64"
              export          MCA="x86_64"
          ;;
    i686)     export CMLFS_TARGET="i686-cmlfs-linux-musl"
              export TARGET_TUPLE="i686-pc-linux-musl"
              export   CMLFS_ARCH="x86"
              export    CMLFS_CPU="x86"
              export          MCA="i386"
           ;;
    aarch64 ) export  CMLFS_TARGET="aarch64-cmlfs-linux-musl"
              export  TARGET_TUPLE="aarch64-pc-linux-musl"
              export    CMLFS_ARCH="arm64"
              export     CMLFS_CPU="armv8-a"
              export           MCA="aarch64"
           ;;
    arm7*)    export  CMLFS_TARGET="armv7l-cmlfs-linux-musleabihf"
              export  TARGET_TUPLE="armv7l-pc-linux-musleabihf"
              export    CMLFS_ARCH="arm"
              export     CMLFS_CPU="armv7-a"
              export           MCA="arm"

           ;;
    arm6*)    export  CMLFS_TARGET="armv6l-cmlfs-linux-musleabihf"
              export  TARGET_TUPLE="armv6l-pc-linux-musleabihf"
              export    CMLFS_ARCH="arm"
              export     CMLFS_CPU="armv6zk"
               export           MCA="arm"
           ;;
esac

export  CMLFS_HOST="$(echo $MACHTYPE | \
        sed "s/$(echo $MACHTYPE | cut -d- -f2)/cross/")"

cat >> ~/.bashrc << EOF
export CMLFS_HOST="${CMLFS_HOST}" \
    CMLFS_TARGET="${CMLFS_TARGET}" \
    CMLFS_ARCH="${CMLFS_ARCH}" \
    CMLFS_CPU="${CMLFS_CPU}" \
    TARGET_TUPLE="${TARGET_TUPLE}"
        MCA="${MCA}"
EOF

source ~/.bashrc

cd $CMLFS/sources
git clone https://github.com/firasuke/mussel

sed -i '70d' mussel.sh && \
sed -i '70 i MPREFIX="/cgnutools"' mussel.sh && \
sed -i '71d' mussel.sh && \
sed -i '71 i MSYSROOT="/cgnutools"' mussel.sh

sudo ./mussel.sh $(uname -m) -l -o -k -p

sudo chown -vR cmlfs:cmlfs $CMLFS/cgnutools

mv -v /cgnutools/usr/lib/*     /cgnutools/lib/
mv -v /cgnutools/usr/include/* /cgnutools/include/
rm -rfv /cgnutools/usr/{include,lib}
ln -sv ../lib     /cgnutools/usr/lib
ln -sv ../include /cgnutools/usr/include

rm -rf  /cgnutools/share/man

# TRY THE COMMAND
/cgnutools/bin/gcc  --version

# TRY SEARCHING
find /mnt/cmlfs -type f -name "libstdc\*"
find /mnt/cmlfs -type f -name "libgcc_s.so.1"

dslm4515 commented 9 months ago

Fetching the packages takes longer.

Yes, its annoying if working on a failed build. No need to re-download the sources every attempt. I might suggest a conditional to that repo's author.

dslm4515 commented 9 months ago

I just remembered I have a Intel atom NUC running a forked LFS system. I could run a build on it. Might take a few hours on a dual core 1.6Ghz Atom CPU with 2GB.

dslm4515 commented 9 months ago

If you look at the uploaded cgnutools from CMLFS 2.0.0, it also lacks gcc binary in cgnutools/bin. CMLFS 2.0.0 was not built with mussel.

emrakyz commented 9 months ago

I am wondering if I can use Mussel with Clang/Musl only system?

Because check.sh looks for Glibc.

Maybe I'll try now.

dslm4515 commented 9 months ago

I am wondering if I can use Mussel with Clang/Musl only system?

Mussel should compile under Clang/Musl system... if ISL is commented out of the mussel script. For reference, my comment

emrakyz commented 9 months ago

I'll compile some 250 packages :D Then I'll start with the new system.

emrakyz commented 9 months ago

Unfortunately "mussel.sh" script terminates early while using Clang / Musl only setup. I have Clang 17.0.2 and Musl 1.2.4. Here is the log.txt: http://0x0.st/HWvO.txt

The log is from the below command: CC="/usr/lib/llvm/17/bin/clang" CXX="/usr/lib/llvm/17/bin/clang++" sudo ./mussel.sh $(uname -m) -l -o -k -p

Because this command does not even work stating "no working compiler": sudo ./mussel.sh $(uname -m) -l -o -k -p

I compiled around 300 packages also using LTO and PGO for some packages such as Python. I compiled the Linux Kernel 6.5.5 with -march=native -O3 and LTO without a problem.

So my compiler toolchain works very well.

By the way, I don't actually have GNU Binutils. I guess Clang/Musl Gentoo profile uses LLVM tools by default and for compiling kernel, it also pulls elfutils as a dependency.

cmlfs@(none) /mnt/cmlfs/sources/mussel $ ./check.sh 
bash:      5.2.15(1)-release
bc:        6.7.0
binutils:  with GNU linkers)
bison:     3.8.2
bzip2:     1.0.8
ccache:    4.8.3
coreutils: 9.4
diffutils: 3.10
findutils: 4.9.0
g++:       ./check.sh: line 34: g++: command not found
gawk:      5.2.2
gcc:       ./check.sh: line 40: gcc: command not found
git:       2.42.0
glibc:     ./check.sh: line 46: /lib/libc.so.6: No such file or directory
grep:      3.11
gzip:      1.13
linux:     6.5.5-gentoo
lzip:      1.23
m4:        1.4.19
make:      4.4.1
perl:      5.38.0
rsync:     3.2.7
sed:       4.9
tar:       1.35
texinfo:   7.0.3
xz:        5.4.4
zstd:      Yann

dslm4515 commented 7 months ago

I finished my work on CMLFS 3.0.1 (LLVM-15.0.6) ... LLVM-15.0.6 can't compile mesa-amber... so I am upgrading my system from LLVM-15.0.6 LLVM-17.0.5

Master branch has upgraded llvmtools from LLVM-15.0.6 to LLVM-17.0.5. It uses the latest mussel.sh with patches instead of sed commands. Same as before, there is gcc built in /cgnutools

$ ls /cgnutools/bin/*gcc*
/cgnutools/bin/gcc
/cgnutools/bin/gcc-ar
/cgnutools/bin/gcc-nm
/cgnutools/bin/gcc-ranlib
/cgnutools/bin/x86_64-pc-linux-musl-gcc
/cgnutools/bin/x86_64-pc-linux-musl-gcc-13.2.0
/cgnutools/bin/x86_64-pc-linux-musl-gcc-ar
/cgnutools/bin/x86_64-pc-linux-musl-gcc-nm
/cgnutools/bin/x86_64-pc-linux-musl-gcc-ranlib

$ /cgnutools/bin/gcc --version
gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dslm4515 commented 2 months ago

I finished 2 cross builds of CMLFS (i686 build on a x86_64 host) and noticed there is no /cgnutools/bin/gcc. Perhaps this is true when target build is not the same as the host... but false if doing a native build (i686 build on an i686 host).

I already made the change with commit 4b2685228b8cab6fde7a1e5e845e3aaedfd3888f

dslm4515 / CMLFS

add wildcard to match the correct file #90