Build failure on MSYS2: `cp: cannot stat 'sources/config.sub': No such file or directory`

[xobs]

When building under MSYS2, it gets somewhat far, but hits a failure when trying to do something with config.sub:

mkdir -p sources
mkdir -p sources/musl-1.2.4.tar.gz.tmp
cd sources/musl-1.2.4.tar.gz.tmp && wget -c -O musl-1.2.4.tar.gz https://musl.libc.org/releases/musl-1.2.4.tar.gz
--2023-11-22 11:47:34--  https://musl.libc.org/releases/musl-1.2.4.tar.gz
Loaded CA certificate '/usr/ssl/certs/ca-bundle.crt'
Resolving musl.libc.org (musl.libc.org)... 45.63.0.111, 2001:19f0:4009:4061:5400:ff:fe11:6da2
Connecting to musl.libc.org (musl.libc.org)|45.63.0.111|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1063758 (1.0M) [application/gzip]
Saving to: ‘musl-1.2.4.tar.gz’

musl-1.2.4.tar.gz        100%[==================================>]   1.01M   917KB/s    in 1.1s

2023-11-22 11:47:37 (917 KB/s) - ‘musl-1.2.4.tar.gz’ saved [1063758/1063758]

cd sources/musl-1.2.4.tar.gz.tmp && touch musl-1.2.4.tar.gz
cd sources/musl-1.2.4.tar.gz.tmp && sha256sum -c /e/Code/musl-cross-make/hashes/musl-1.2.4.tar.gz.sha256
musl-1.2.4.tar.gz: OK
mv sources/musl-1.2.4.tar.gz.tmp/musl-1.2.4.tar.gz sources/musl-1.2.4.tar.gz
rm -rf sources/musl-1.2.4.tar.gz.tmp
case "musl-1.2.4.orig" in */*) exit 1 ;; esac
rm -rf musl-1.2.4.orig.tmp
mkdir musl-1.2.4.orig.tmp
( cd musl-1.2.4.orig.tmp && tar zxf - ) < sources/musl-1.2.4.tar.gz
rm -rf musl-1.2.4.orig
touch musl-1.2.4.orig.tmp/musl-1.2.4
mv musl-1.2.4.orig.tmp/musl-1.2.4 musl-1.2.4.orig
rm -rf musl-1.2.4.orig.tmp
case "musl-1.2.4" in */*) exit 1 ;; esac
rm -rf musl-1.2.4.tmp
mkdir musl-1.2.4.tmp
( cd musl-1.2.4.tmp && /e/Code/musl-cross-make/cowpatch.sh -I ../musl-1.2.4.orig )
test ! -d patches/musl-1.2.4 || cat patches/musl-1.2.4/* | ( cd musl-1.2.4.tmp && /e/Code/musl-cross-make/cowpatch.sh -p1 )
if test -f musl-1.2.4.orig/configfsf.sub ; then cs=configfsf.sub ; elif test -f musl-1.2.4.orig/config.sub ; then cs=config.sub ; else exit 0 ; fi ; rm -f musl-1.2.4.tmp/$cs && cp -f sources/config.sub musl-1.2.4.tmp/$cs && chmod +x musl-1.2.4.tmp/$cs
rm -rf musl-1.2.4
mv musl-1.2.4.tmp musl-1.2.4
mkdir -p sources/gcc-13.2.0.tar.xz.tmp
cd sources/gcc-13.2.0.tar.xz.tmp && wget -c -O gcc-13.2.0.tar.xz https://ftpmirror.gnu.org/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz
--2023-11-22 11:47:40--  https://ftpmirror.gnu.org/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz
Loaded CA certificate '/usr/ssl/certs/ca-bundle.crt'
Resolving ftpmirror.gnu.org (ftpmirror.gnu.org)... 209.51.188.200, 2001:470:142:5::200
Connecting to ftpmirror.gnu.org (ftpmirror.gnu.org)|209.51.188.200|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://mirror.freedif.org/GNU/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz [following]
--2023-11-22 11:47:42--  https://mirror.freedif.org/GNU/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz
Resolving mirror.freedif.org (mirror.freedif.org)... 132.147.122.105
Connecting to mirror.freedif.org (mirror.freedif.org)|132.147.122.105|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 87858592 (84M) [application/x-xz]
Saving to: ‘gcc-13.2.0.tar.xz’

gcc-13.2.0.tar.xz        100%[==================================>]  83.79M  9.96MB/s    in 7.5s

2023-11-22 11:47:50 (11.1 MB/s) - ‘gcc-13.2.0.tar.xz’ saved [87858592/87858592]

cd sources/gcc-13.2.0.tar.xz.tmp && touch gcc-13.2.0.tar.xz
cd sources/gcc-13.2.0.tar.xz.tmp && sha256sum -c /e/Code/musl-cross-make/hashes/gcc-13.2.0.tar.xz.sha256
gcc-13.2.0.tar.xz: OK
mv sources/gcc-13.2.0.tar.xz.tmp/gcc-13.2.0.tar.xz sources/gcc-13.2.0.tar.xz
rm -rf sources/gcc-13.2.0.tar.xz.tmp
case "gcc-13.2.0.orig" in */*) exit 1 ;; esac
rm -rf gcc-13.2.0.orig.tmp
mkdir gcc-13.2.0.orig.tmp
( cd gcc-13.2.0.orig.tmp && tar Jxf - ) < sources/gcc-13.2.0.tar.xz
rm -rf gcc-13.2.0.orig
touch gcc-13.2.0.orig.tmp/gcc-13.2.0
mv gcc-13.2.0.orig.tmp/gcc-13.2.0 gcc-13.2.0.orig
rm -rf gcc-13.2.0.orig.tmp
case "gcc-13.2.0" in */*) exit 1 ;; esac
rm -rf gcc-13.2.0.tmp
mkdir gcc-13.2.0.tmp
( cd gcc-13.2.0.tmp && /e/Code/musl-cross-make/cowpatch.sh -I ../gcc-13.2.0.orig )
test ! -d patches/gcc-13.2.0 || cat patches/gcc-13.2.0/* | ( cd gcc-13.2.0.tmp && /e/Code/musl-cross-make/cowpatch.sh -p1 )
if test -f gcc-13.2.0.orig/configfsf.sub ; then cs=configfsf.sub ; elif test -f gcc-13.2.0.orig/config.sub ; then cs=config.sub ; else exit 0 ; fi ; rm -f gcc-13.2.0.tmp/$cs && cp -f sources/config.sub gcc-13.2.0.tmp/$cs && chmod +x gcc-13.2.0.tmp/$cs
cp: cannot stat 'sources/config.sub': No such file or directory
make: *** [Makefile:159: gcc-13.2.0] Error 1

[ryanwoodsmall]

I don't speak for anyone else, but I suggest: use WSL. You'll be chasing down brokenness with cl.exe/link.exe/etc. for a long while otherwise. Building GCC with MSVC at all is still somewhat painful. If you need native-to-Windows musl cross compilers, GCC (or Clang, possibly) from cygwin/mingw or similar will likely get you much farther than MSVC.

[xobs]

Thank you -- you're right, my brain auto-completed the wrong thing. I meant msys2, but I started typing "MS..." and ended up writing "MSVC".

I'm trying to replicate what musl.cc does, since those toolchains are super handy. Unfortunately they stopped releasing anything in 2021, so they're no longer an option.

I believe that error exists on the https://github.com/jthat/musl-cross-make.git branch, however now I'm running into a situation where linux-headers has symlinks, and the msys2 version of tar doesn't know how to handle them.

[xobs]

I get further if I add this to the top of the Makefile:

export MSYS = winsymlinks

Let's see how far it gets...

[xobs]

Some more information. Apparently the more precise variable should be export MSYS = winsymlinks:lnk.

From my understanding (and I've been wrong here several times before):

• MSYS2 is a Linux emulation layer where more syscalls go through msys-2.0.dll
• Mingw64 is a source-level emulation layer where calls are directly routed to Windows

As such, MSYS2 is easier to target. This explains why I'm able to build under MSYS2 but not Mingw64.

The problem seems to come down to symlinks. And there are several of them.

For starters, the MSYS variable has four states:

• unset (or invalid?) -- Symlinks are just copies
• winsymlinks or winsymlinks:lnk -- Symlinks are Windows .lnk shortcut files
• winsymlinks:native -- Symlinks use NTFS symlinks, but will fall back to .lnk files if there's a failure
• winsymlinks:nativestrict -- Symlinks must use NTFS symlinks, and will fail if the command fails

GNU tar has a problem where it will attempt to create symlinks to directories before they're extracted. For example, if your tar file has a link from a -> b, it might try to extract a as a symlink before b is extracted, but will fail because b doesn't yet exist.

Replacing tar with bsdtar solves this issue.

As a separate issue, symlinks behave differently on NTFS. When you're in a symlinked directory, it behaves as though you're actually in that directory. Here's an example session:

Sean@Ondo MSYS ~
$ mkdir a

Sean@Ondo MSYS ~
$ mkdir b

Sean@Ondo MSYS ~
$ touch this-is-the-root

Sean@Ondo MSYS ~
$ cd a

Sean@Ondo MSYS ~/a
$ ln -s ../b .

Sean@Ondo MSYS ~/a
$ cd b

Sean@Ondo MSYS ~/a/b
$ ls ..
a  b  this-is-the-root

Sean@Ondo MSYS ~/a/b
$

The tree is as follows:

+ a/
  + b -> ../a
+ b/
+ this-is-the-root

When in a/b/ the view of .. is that of the root and not of a. This is very different from Linux.

So while this could be worked around, it is questionable how interesting it is.

Overall I'm building it for msys2 which is a good middle ground. I may take time to figure out how to get it working on mingw64 for the most compatible and highest speed compiler generation.

[ryanwoodsmall]

The most compatible would be using WSL. The fact that you got anything to build at all is surprising.