Hello,

I want to rebuild the packages in the `skarnet` module to be statically
linked with musl libc. I don't mind if my C/C++ toolchain itself does
not use musl libc, so initially, I tried simply modifying the packages
and their direct dependencies, like so:

	(define (compose . fns)
	  (let ((call (lambda (f x) (f x))))
	    (lambda (p) (fold-right call p fns))))
	
	(define (static-link p)
	  (package/inherit p
	    (arguments
	      (substitute-keyword-arguments (package-arguments p)
	        ((#:configure-flags flags ''())
	        `(cons* "LDFLAGS=-static" "--disable-shared" ,flags))))))
	
	(define replace-glibc
	  (package-input-rewriting `((,glibc . ,musl)) #:deep? #t))
	
	(define (append-name suffix)
	  (lambda (p)
	    (package/inherit p
	      (name (string-append p suffix)))))
	
	(define package-with-musl
	  (package-mapping
	    (compose static-link replace-glibc) #:deep? #f))
	
	(define hello-musl    (package-with-musl hello))
	(define execline-musl (package-with-musl execline))

Then I tested with 

	$ guix build -L /path/to/module -e '(@ (module path) hello-musl)'

This worked with simple packages like `hello`, but other packages
like `execline` still ended up with dynamically linked binaries:

	$ out=$(guix build -L $(pwd) -e '(@ (aqwari packages skaware) execline-musl)')
	$ file $out/bin/fdmove
	/gnu/store/82r5ilk3jir7cssmhc8bi87qqj46p29h-execline-2.8.1.0/bin/fdmove: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
	
	$ guix gc --requisites $out
	/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8
	/gnu/store/hxxbjrm4iw6aj203zli6hj4ds1l27s3k-skalibs-2.11.0.0
	/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33
	/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8
	/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib
	/gnu/store/82r5ilk3jir7cssmhc8bi87qqj46p29h-execline-2.8.1.0

I don't know how gcc and glibc ended up in there. I tried reading the
code, but I am not familiar enough with it to follow it yet. I think
they may get added as implicit inputs by gnu-build-system, and I might
not be using the package-input-rewriting transform correctly.

On my second try, I tried to create a GCC+musl toolchain and use that
I tried to create a toolchain like so:

	(define my-toolchain (make-gcc-toolchain gcc musl))

But this failed with the error:

	guix build: error: reference to invalid output 'static' of derivation '/gnu/store/jmp8rccdwnrnl9x947xp7a75kmgdhylp-musl-1.2.2.drv'

This is because the musl package does not have a "static" output, which
the package builder in `make-gcc-toolchain` tries to access. To work
around that issue, I added empty outputs to the musl package:

	(define musl-fix-outputs
	  (package
	    (inherit musl)
	    (outputs '("out" "static" "debug"))
	    (arguments
	      (list
	        #:phases
	          #~(modify-phases %standard-phases
	              (delete 'check)
	              (add-after 'build 'ensure-outputs
	                (lambda _
	                  (mkdir-p #$output:static)
	                  (mkdir-p #$output:debug))))))))
	
	(define my-toolchain
	  (make-gcc-toolchain gcc musl-fix-outputs))

Then I tried to build the `hello` package:

	(package-with-c-toolchain hello my-toolchain)

This rebuilds the musl package, and gets to the 'patch-source-shebangs
phase of the gcc rebuild, where it fails with the error:

	error: in phase 'patch-source-shebangs': uncaught exception:
	encoding-error "scm_to_stringn" "cannot convert narrow string to output locale" 84 #f #f

I've attached the full error trace to this email. I am not sure what to
make of this error, or whether it is a red herring or not. Does anyone
see what I'm doing wrong? Or does anyone have an example of building a
non-trivial package against musl?

Thanks,
David