[ISSUE] Tracking: rebuild armv7l-musl w/ musl-1.20.1

[ISSUE] Tracking: rebuild armv7l-musl w/ musl-1.20.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

New issue by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811

Description:
Based on @ericonr 's branch [musl-1.20.0](https://github.com/ericonr/void-packages/tree/musl-1.2.0), which now really is for musl-1.20.1, I found a patch to get `cross-armv7l-linux-musleabihf` built:
`srcpkgs/cross-armv7l-linux-musleabihf/patches/fix-_stat-sed,patch`
```
--- gcc-9.3.0/libgo/mksysinfo.sh        2020-11-29 23:07:46.793838127 +0100
+++ gcc-9.3.0/libgo/mksysinfo.sh        2020-11-29 23:27:18.520794067 +0100
@@ -506,9 +506,9 @@
          -e 's/st_size/Size/' \
          -e 's/st_blksize/Blksize/' \
          -e 's/st_blocks/Blocks/' \
-         -e 's/st_atim/Atim/' \
-         -e 's/st_mtim/Mtim/' \
-         -e 's/st_ctim/Ctim/' \
+         -e 's/st_atim/Atim/g' \
+         -e 's/st_mtim/Mtim/g' \
+         -e 's/st_ctim/Ctim/g' \
          -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1Timeval\2/g' \
          -e 's/\([^a-zA-Z0-9_]\)_timespec_t\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
          -e 's/\([^a-zA-Z0-9_]\)_st_timespec_t\([^a-zA-Z0-9_]\)/\1StTimespec\2/g' \
```

So basically the replacement needs to take place on the entire line. This is because before the `st_atim` etc. there is a `__st_atim32` which is replaced and the `sed` is done without modifying the interesting `st_atim` which follows.

Perhaps you @ericonr can update the branch to upstream master once more?
And we should integrate this patch with `gcc` and use the `cross-*-musl/files/something.patch` symbolic links to the `gcc/patches/something.patch` style for it.

I think I could now build all packages for `armv7l-musl` which will take about 2 days.

Re: Tracking: rebuild armv7l-musl w/ musl-1.20.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735481996

Comment:
Actually gcc-9.3.0_8 builds w/o the patch so we can keep it local to the cross compiler(s).

Re: Tracking: rebuild armv7l-musl w/ musl-1.20.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735481996

Comment:
Actually `gcc-9.3.0_8` for `armv7l-musl` builds w/o the patch so we can keep it local to the cross compiler(s).

Re: Tracking: rebuild armv7l-musl w/ musl-1.20.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735481996

Comment:
Actually `gcc-9.3.0_8` for `armv7l-musl` builds w/o the patch so we can keep it local to the cross compiler(s).

Re: Tracking: rebuild armv7l-musl w/ musl-1.20.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735573283

Comment:
I made a new branch [musl-1.2.1](https://github.com/pullmoll/void-packages/commits/musl-1.2.1) and will now build packages.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735766314

Comment:
The first bunch of packages is [available here](https://misc.voidlinux.de/binpkgs).
Note that because I built with `-N` there are also (a lot of) host packages built locally.
There is no such option as `-N for target only`...

I'm building with an `i686` environment binary-bootstrapped from the official repo.
I'm also building the `i686-musl` packages with `musl-1.2.1` because later on there are some (few) packages which cannot be built with `$XBPS_LIBC` != `$XBPS_TARGET_LIBC`.

I do not sign this temporary repo but there is a `sha256sum.txt` signed w/ my github.com signing key, just in case.

You can fetch the files with `rsync` from `voidlinux.de::` (note the double colon)
E.g. `rsync -av --progress voidlinux.de::musl-1.2.1 .` should get you a local copy.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735766314

Comment:
The first bunch of packages is [available here](https://misc.voidlinux.de/binpkgs).
Note that because I built with `-N` there are also (a lot of) host packages built locally.
There is no such option as `-N for target only`...

I'm building with an `i686` environment binary-bootstrapped from the official repo.
I'm also building the `i686-musl` packages with `musl-1.2.1` because later on there are some (few) packages which cannot be built with `$XBPS_LIBC` != `$XBPS_TARGET_LIBC`.

I do not sign this temporary repo but there is a `sha256sum.txt` signed w/ my github.com signing key, just in case.

You can fetch the files with `rsync` from `voidlinux.de::` (note the double colon)
E.g. `rsync -av --progress voidlinux.de::musl-1.2.1 .` should get you a local copy.
You can use `--exclude "**/debug"` to skip downloading the debug packages.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735766314

Comment:
The first bunch of packages is [available here](https://misc.voidlinux.de/binpkgs).
Note that because I built with `-N` there are also (a lot of) host packages built locally.
There is no such option as `-N for target only`...

I'm building with an `i686` environment binary-bootstrapped from the official repo.
I'm also building the `i686-musl` packages with `musl-1.2.1` because later on there are some (few) packages which cannot be built with `$XBPS_LIBC` != `$XBPS_TARGET_LIBC`.

I do not sign this temporary repo but there is a `sha256sum.txt` signed w/ my github.com signing key, just in case.

You can fetch the files with `rsync` from `voidlinux.de::` (note the double colon)
E.g. `rsync -av --progress voidlinux.de::musl-1.2.1 .` should get you a local copy. You can use `--exclude "**/debug"` to skip downloading the debug packages.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735766314

Comment:
The first bunch of packages is [available here](https://misc.voidlinux.de/binpkgs).
Note that because I built with `-N` there are also (a lot of) host packages built locally.
There is no such option as `-N for target only`...

I'm building with an `i686` environment binary-bootstrapped from the official repo.
I'm also building the `i686-musl` packages with `musl-1.2.1` because later on there are some (few) packages which cannot be built with `$XBPS_LIBC != $XBPS_TARGET_LIBC`.

I do not sign this temporary repo but there is a `sha256sum.txt` signed w/ my github.com signing key, just in case.

You can fetch the files with `rsync` from `voidlinux.de::` (note the double colon)
E.g. `rsync -av --progress voidlinux.de::musl-1.2.1 .` should get you a local copy. You can use `--exclude "**/debug"` to skip downloading the debug packages.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 4179 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735856513

Comment:
One observation which I think it is already known: trying to cross compile `mesa` from `glibc` to `musl` fails because host flags are leaking into the target w/ `ninja`:
```
Found ninja-1.10.1 at /usr/bin/ninja
=> mesa-20.2.3_1: running post_configure ...
=> mesa-20.2.3_1: running pre-build hook: 02-script-wrapper ...
=> mesa-20.2.3_1: running do_build ...
ninja: Entering directory `build'
ninja: error: '/usr/armv7l-linux-musleabihf/usr/lib/libm-2.30.so', needed by 'src/amd/vulkan/libvulkan_radeon.so', missing and no known rule to make it
```

Trying to build it in an `i686-musl` environment I get this:
```
[319/2314] Compiling C object src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o
FAILED: src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o 
armv7l-linux-musleabihf-gcc -Isrc/freedreno/common/libfreedreno_common.a.p -Isrc/freedreno/common -I../src/freedreno/common -Isrc/freedreno -I../src/freedreno -Isrc/freedreno/registers -I../src/freedreno/registers -Isrc/freedreno/registers/adreno -I../src/freedreno/registers/adreno -Iinclude -I../include -Isrc -I../src -I../src/gallium/include -Isrc/util -I../src/util -I/usr/armv7l-linux-musleabihf/usr/include -fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wl,--gc-sections -ffunction-sections -fdata-sections -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="20.2.3"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -D_GNU_SOURCE -DUSE_GCC_ATOMIC_BUILTINS -DUSE_ARM_ASM -DMAJOR_IN_SYSMACROS -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="11.0.0"' -DLLVM_IS_SHARED=1 -DUSE_LIBGLVND=1 -DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_LIBSENSORS=1 -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=empty-body -Werror=incompatible-pointer-types -Werror=int-conversion -Wimplicit-fallthrough -Wno-missing-field-initializers -Wno-format-truncation -fno-math-errno -fno-trapping-math -fno-common -Werror=format -Wformat-security -fstack-clash-protection -D_FORTIFY_SOURCE=2 -O2 -march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard -g -fPIC -pthread -Wno-override-init -MD -MQ src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o -MF src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o.d -o src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o -c ../src/freedreno/common/freedreno_uuid.c
../src/freedreno/common/freedreno_uuid.c:30:10: fatal error: git_sha1.h: No such file or directory
   30 | #include "git_sha1.h"
      |          ^~~~~~~~~~~~
compilation terminated.
```
So it looks like I need to resort to using `x86_64-musl` to build `mesa` for `armv7l-musl`.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 4283 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735856513

Comment:
One observation which I think it is already known: trying to cross compile `mesa` from `glibc` to `musl` fails because host flags are leaking into the target w/ `ninja`:
```
Found ninja-1.10.1 at /usr/bin/ninja
=> mesa-20.2.3_1: running post_configure ...
=> mesa-20.2.3_1: running pre-build hook: 02-script-wrapper ...
=> mesa-20.2.3_1: running do_build ...
ninja: Entering directory `build'
ninja: error: '/usr/armv7l-linux-musleabihf/usr/lib/libm-2.30.so', needed by 'src/amd/vulkan/libvulkan_radeon.so', missing and no known rule to make it
```

Trying to build it in an `i686-musl` environment I get this:
```
[319/2314] Compiling C object src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o
FAILED: src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o 
armv7l-linux-musleabihf-gcc -Isrc/freedreno/common/libfreedreno_common.a.p -Isrc/freedreno/common -I../src/freedreno/common -Isrc/freedreno -I../src/freedreno -Isrc/freedreno/registers -I../src/freedreno/registers -Isrc/freedreno/registers/adreno -I../src/freedreno/registers/adreno -Iinclude -I../include -Isrc -I../src -I../src/gallium/include -Isrc/util -I../src/util -I/usr/armv7l-linux-musleabihf/usr/include -fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wl,--gc-sections -ffunction-sections -fdata-sections -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="20.2.3"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -D_GNU_SOURCE -DUSE_GCC_ATOMIC_BUILTINS -DUSE_ARM_ASM -DMAJOR_IN_SYSMACROS -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="11.0.0"' -DLLVM_IS_SHARED=1 -DUSE_LIBGLVND=1 -DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_LIBSENSORS=1 -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=empty-body -Werror=incompatible-pointer-types -Werror=int-conversion -Wimplicit-fallthrough -Wno-missing-field-initializers -Wno-format-truncation -fno-math-errno -fno-trapping-math -fno-common -Werror=format -Wformat-security -fstack-clash-protection -D_FORTIFY_SOURCE=2 -O2 -march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard -g -fPIC -pthread -Wno-override-init -MD -MQ src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o -MF src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o.d -o src/freedreno/common/libfreedreno_common.a.p/freedreno_uuid.c.o -c ../src/freedreno/common/freedreno_uuid.c
../src/freedreno/common/freedreno_uuid.c:30:10: fatal error: git_sha1.h: No such file or directory
   30 | #include "git_sha1.h"
      |          ^~~~~~~~~~~~
compilation terminated.
```
So it looks like I need to resort to using `x86_64-musl` to build `mesa` for `armv7l-musl`.

Edit: The problem is the same with `x86_64-musl` so mesa can currently not be built for `armv7l-musl`.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-736014232

Comment:
So after running `./xbps-src -a arvm7l-musl -C -N pkg mesa` five or six times I finally got it so far that the expected file was there. This seems to be a bug in the handling of parallelism when cross compiling, or more probably a missing dependency in some place.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-735766314

Comment:
The first bunch of packages is [available here](https://misc.voidlinux.de/binpkgs).
Note that because I built with `-N` there are also (a lot of) host packages built locally.
There is no such option as `-N for target only`...

I'm building with an `i686` environment binary-bootstrapped from the official repo.
I'm also building the `i686-musl` packages with `musl-1.2.1` because later on there are some (few) packages which cannot be built with `$XBPS_LIBC != $XBPS_TARGET_LIBC`.

I do not sign this temporary repo but there is a `sha256sum.txt` signed w/ my github.com signing key, just in case.

You can fetch the files with `rsync` from `voidlinux.de::` (note the double colon)
E.g. `rsync -avH --progress voidlinux.de::musl-1.2.1 .` should get you a local copy. You can use `--exclude "**/debug"` to skip downloading the debug packages.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[fosslinux]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

New comment by fosslinux on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-738537912

Comment:
Is there a compelling reason to test the rebuild from i686? When it is actually done won't it be done from x86_64-musl?

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-738797150

Comment:
As long as the infrastructure doesn't change probably yes. I want to identify packages which don't build and i686-musl bullds more arvm7l-musl packages than x86_64-musl does.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-740214877

Comment:
Since `xbps-fbulk -a <cross-arch> ...` doesn't really work I wrote a wrapper script to collect the output of failed builds (return code == 1) and put them in per-arch subdirs in [https://misc.voidlinux.de/binpkgs/bad.*](https://misc.voidlinux.de/binpkgs/).

I'll try to fix solvable (for me) issues and the lists of files there always reflect the most recent upload of what I tried to build.

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-744558193

Comment:
Slowly finishing with building what can be built.
785GiB of packages already and only very few left which fail because of time64 issues.
https://misc.voidlinux.de/binpkgs/packages.html

Re: Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811#issuecomment-745527350

Comment:
Closing as now linux-5.10 is out and the new kernel headers should go together with the musl-1.2.1 update and perhaps even the upgrade to gcc-10.2 at the same time.

Re: [ISSUE] [CLOSED] Tracking: rebuild armv7l-musl w/ musl-1.2.1

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Closed issue by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/26811

Description:
Based on @ericonr 's branch [musl-1.2.0](https://github.com/ericonr/void-packages/tree/musl-1.2.0), which now really is for musl-1.2.1, I found a patch to get `cross-armv7l-linux-musleabihf` built:
`srcpkgs/cross-armv7l-linux-musleabihf/patches/fix-_stat-sed.patch`
```
--- gcc-9.3.0/libgo/mksysinfo.sh        2020-11-29 23:07:46.793838127 +0100
+++ gcc-9.3.0/libgo/mksysinfo.sh        2020-11-29 23:27:18.520794067 +0100
@@ -506,9 +506,9 @@
          -e 's/st_size/Size/' \
          -e 's/st_blksize/Blksize/' \
          -e 's/st_blocks/Blocks/' \
-         -e 's/st_atim/Atim/' \
-         -e 's/st_mtim/Mtim/' \
-         -e 's/st_ctim/Ctim/' \
+         -e 's/st_atim/Atim/g' \
+         -e 's/st_mtim/Mtim/g' \
+         -e 's/st_ctim/Ctim/g' \
          -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1Timeval\2/g' \
          -e 's/\([^a-zA-Z0-9_]\)_timespec_t\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
          -e 's/\([^a-zA-Z0-9_]\)_st_timespec_t\([^a-zA-Z0-9_]\)/\1StTimespec\2/g' \
```

So basically the replacement needs to take place on the entire line. This is because before the `st_atim` etc. there is a `__st_atim32` which is replaced and the `sed` is done without modifying the interesting `st_atim` which follows.

An alternative may be to replace `s/st_atim /Atim /` i.e. expect a blank after the type.

~~Perhaps you @ericonr can update the branch to upstream master once more?
And we should integrate this patch with `gcc` and use the `cross-*-musl/files/something.patch` symbolic links to the `gcc/patches/something.patch` style for it.~~ Done.

I think I could now build all packages for `armv7l-musl` which will take about 2 days.