musl-cross-make
musl-cross-make copied to clipboard
Build failure on MSYS2: `cp: cannot stat 'sources/config.sub': No such file or directory`
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
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.
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.
I get further if I add this to the top of the Makefile:
export MSYS = winsymlinks
Let's see how far it gets...
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
orwinsymlinks: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.
The most compatible would be using WSL. The fact that you got anything to build at all is surprising.