[PACKAGE] musl libc

[PACKAGE] musl libc

[Vincent Legoll]

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

Hello,

Please, have a look at the attached musl libc packaging.

It may be of use for having smaller statically linked binaries
of selected packages.

Advise about how to finish the submission process, in which
scm file should this go ? I did it standalone, but it looks like
that's not the way things go in guix. Should it go with glibc ?

I'll post a sinit packaging that show how musl can be used.
The sinit package is a minimalistic /sbin/init replacement.

-- 
Vincent Legoll

[-- Attachment #2: musl.scm --]
[-- Type: text/x-scheme, Size: 1794 bytes --]

;;; GNU Guix --- Functional package management for GNU
;;; Copyright <C2><A9> 2016 Vincent Legoll <vincent.legoll@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (musl)
  #:use-module (guix download)
  #:use-module (guix packages)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages))

(define-public musl
  (package
    (name "musl")
    (version "1.1.15")
    (source (origin
              (method url-fetch)
              (uri (string-append "http://www.musl-libc.org/releases/" name "-"
                                  version ".tar.gz"))
              (sha256
               (base32
                "1ymhxkskivzph0q34zadwfglc5gyahqajm7chqqn2zraxv3lgr4p"))))
    (build-system gnu-build-system)
    (arguments `(#:tests? #f)) ; Musl has no tests

    (synopsis "New C standard library to power a new generation of Linux-based
devices")
    (description "The musl libc is lightweight, fast, simple, free, and strives
to be correct in the sense of standards-conformance and safety.")
    (home-page "http://www.musl-libc.org")
    (license (x11-style "file://COPYRIGHT"))))

Re: [PACKAGE] musl libc

[ng0]

Hi,

thanks for the work on this.

Vincent Legoll <vincent.legoll@gmail.com> writes:

> Hello,
>
> Please, have a look at the attached musl libc packaging.
>
> It may be of use for having smaller statically linked binaries
> of selected packages.
>
> Advise about how to finish the submission process, in which
> scm file should this go ? I did it standalone, but it looks like
> that's not the way things go in guix. Should it go with glibc ?

It can go standalone, I don't see any fitting file at the moment.
'base.scm' maybe, but I would just create gnu/packages/musl.scm and add
the file in 'gnu/local.mk'.

> I'll post a sinit packaging that show how musl can be used.
> The sinit package is a minimalistic /sbin/init replacement.
>
> -- 
> Vincent Legoll
> ;;; GNU Guix --- Functional package management for GNU
> ;;; Copyright <C2><A9> 2016 Vincent Legoll <vincent.legoll@gmail.com>
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> ;;; GNU Guix is free software; you can redistribute it and/or modify it
> ;;; under the terms of the GNU General Public License as published by
> ;;; the Free Software Foundation; either version 3 of the License, or (at
> ;;; your option) any later version.
> ;;;
> ;;; GNU Guix is distributed in the hope that it will be useful, but
> ;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;;; GNU General Public License for more details.
> ;;;
> ;;; You should have received a copy of the GNU General Public License
> ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
>
> (define-module (musl)
>   #:use-module (guix download)
>   #:use-module (guix packages)
>   #:use-module (guix build-system gnu)
>   #:use-module (guix licenses)
>   #:use-module (gnu packages))
>
> (define-public musl
>   (package
>     (name "musl")
>     (version "1.1.15")
>     (source (origin
>               (method url-fetch)
>               (uri (string-append "http://www.musl-libc.org/releases/" name "-"
>                                   version ".tar.gz"))
>               (sha256
>                (base32
>                 "1ymhxkskivzph0q34zadwfglc5gyahqajm7chqqn2zraxv3lgr4p"))))
>     (build-system gnu-build-system)
>     (arguments `(#:tests? #f)) ; Musl has no tests
>
>     (synopsis "New C standard library to power a new generation of Linux-based
> devices")
>     (description "The musl libc is lightweight, fast, simple, free, and strives
> to be correct in the sense of standards-conformance and safety.")
>     (home-page "http://www.musl-libc.org")
>     (license (x11-style "file://COPYRIGHT"))))
>

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [PACKAGE] musl libc

[Ricardo Wurmus]

Hi Vincent,

thank you for your efforts!

> Advise about how to finish the submission process, in which
> scm file should this go ? I did it standalone, but it looks like
> that's not the way things go in guix. Should it go with glibc ?

It’s fine to put it in a separate file “gnu/packages/musl.scm” and add
it to the list of modules in “gnu/local.mk”.

What follows is a short review with some comments.

> ;;; GNU Guix --- Functional package management for GNU
> ;;; Copyright <C2><A9> 2016 Vincent Legoll <vincent.legoll@gmail.com>
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> ;;; GNU Guix is free software; you can redistribute it and/or modify it
> ;;; under the terms of the GNU General Public License as published by
> ;;; the Free Software Foundation; either version 3 of the License, or (at
> ;;; your option) any later version.
> ;;;
> ;;; GNU Guix is distributed in the hope that it will be useful, but
> ;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;;; GNU General Public License for more details.
> ;;;
> ;;; You should have received a copy of the GNU General Public License
> ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

> (define-module (musl)
>   #:use-module (guix download)
>   #:use-module (guix packages)
>   #:use-module (guix build-system gnu)
>   #:use-module (guix licenses)
>   #:use-module (gnu packages))

> (define-public musl
>   (package
>     (name "musl")
>     (version "1.1.15")
>     (source (origin
>               (method url-fetch)
>               (uri (string-append "http://www.musl-libc.org/releases/" name "-"
>                                   version ".tar.gz"))
>               (sha256
>                (base32
>                 "1ymhxkskivzph0q34zadwfglc5gyahqajm7chqqn2zraxv3lgr4p"))))
>     (build-system gnu-build-system)
>     (arguments `(#:tests? #f)) ; Musl has no tests

>     (synopsis "New C standard library to power a new generation of Linux-based
> devices")

I would change it to just “Small C standard library”.  What do you
think?

>     (description "The musl libc is lightweight, fast, simple, free, and strives
> to be correct in the sense of standards-conformance and safety.")

How about this instead?

    “musl is a simple and lightweight C standard library.  It strives to
     be correct in the sense of standards-conformance and safety.”

“fast” is a bit of a loaded term, so we often avoid it.  Since all
packages in Guix are “free” we usually drop this term from descriptions.

>     (home-page "http://www.musl-libc.org")
>     (license (x11-style "file://COPYRIGHT"))))

This looks good.  If you agree, I’ll copy the changes and make a commit
with you as the author.

Normally, contributors send changes as patches to the mailing list.  For
future contributions it might be helpful to take a look at the
“Contributing” section in the manual:

    https://www.gnu.org/software/guix/manual/html_node/Contributing.html

This essentially describes how to get started with Guix from a git
clone, generate patches with “git format-patch” and how to send them via
email.  If anything in there is confusing to you please let us know and
we’ll try to help.  You’re also welcome to visit the #guix IRC channel
on Freenode for discussions or questions.

Welcome on board!

~~ Ricardo

Re: [PACKAGE] musl libc

[Vincent Legoll]

> It’s fine to put it in a separate file “gnu/packages/musl.scm” and add
> it to the list of modules in “gnu/local.mk”.
>
> What follows is a short review with some comments.
>
>> (synopsis "New C standard library to power a new generation of
>> Linux-based devices")
>
> I would change it to just “Small C standard library”.  What do you
> think?

As you wish I just copied it from upstream web site...

>>     (description "The musl libc is lightweight, fast, simple, free, and strives
>> to be correct in the sense of standards-conformance and safety.")
>
> How about this instead?
>
>     “musl is a simple and lightweight C standard library.  It strives to
>      be correct in the sense of standards-conformance and safety.”
>
> “fast” is a bit of a loaded term, so we often avoid it.  Since all
> packages in Guix are “free” we usually drop this term from descriptions.

Ditto

>>     (home-page "http://www.musl-libc.org")
>>     (license (x11-style "file://COPYRIGHT"))))
>
> This looks good.  If you agree, I’ll copy the changes and make a commit
> with you as the author.
>
> Normally, contributors send changes as patches to the mailing list.  For
> future contributions it might be helpful to take a look at the
> “Contributing” section in the manual:

Yes, I just wanted feedback in order to make a real patch submission afterwards,
and thought it would be more readable as is, and I didn't know in
which file to put
it anyways... But if you want to do it, go ahead...

>     https://www.gnu.org/software/guix/manual/html_node/Contributing.html
>
> This essentially describes how to get started with Guix from a git
> clone, generate patches with “git format-patch” and how to send them via
> email.  If anything in there is confusing to you please let us know and
> we’ll try to help.

This is clear enough

>  You’re also welcome to visit the #guix IRC channel
> on Freenode for discussions or questions.

Yep, even if I'm not a big fan of irc, I already came to this channel
a few times

Thanks

-- 
Vincent Legoll

Re: [PACKAGE] musl libc

[Ricardo Wurmus]

I just built musl and found that it also installs “bin/musl-gcc”, a
wrapper of sorts, but it doesn’t work as it depends on a “gcc”
executable to be available.

Is this something that needs to work in order for this package to be
useful?

~~ Ricardo

Re: [PACKAGE] musl libc

[Vincent Legoll]

On Wed, Aug 3, 2016 at 1:24 PM, Ricardo Wurmus <rekado@elephly.net> wrote:
> I just built musl and found that it also installs “bin/musl-gcc”, a
> wrapper of sorts, but it doesn’t work as it depends on a “gcc”
> executable to be available.

I did not see that as I probably had gcc installed in the profile with
which i built musl...

> Is this something that needs to work in order for this package to be
> useful?

Maybe not, but the default / documented way it is to be used is with
the wrapper, so it is nice to have...

Is this not the same with glibc, but in a more hidden way ?

-- 
Vincent Legoll

Re: [PACKAGE] musl libc

[Ricardo Wurmus]

Vincent Legoll <vincent.legoll@gmail.com> writes:

> On Wed, Aug 3, 2016 at 1:24 PM, Ricardo Wurmus <rekado@elephly.net> wrote:
>> I just built musl and found that it also installs “bin/musl-gcc”, a
>> wrapper of sorts, but it doesn’t work as it depends on a “gcc”
>> executable to be available.
>
> I did not see that as I probably had gcc installed in the profile with
> which i built musl...
>
>> Is this something that needs to work in order for this package to be
>> useful?
>
> Maybe not, but the default / documented way it is to be used is with
> the wrapper, so it is nice to have...
>
> Is this not the same with glibc, but in a more hidden way ?

We usually don’t use the “gcc” package directly in Guix.  Instead we use
“gcc-toolchain”, which also comes with a wrapper around the linker that
ensures that binaries are linked with libraries in the store, ensuring
that things generally just work™.

I think more work would be needed to ensure that packages can actually
successfully be linked with musl, but I’m not at all familiar with this.
I had mixed success with a GCC ARM cross-compiler toolchain linking with
newlib, so I know that it’s not exactly obvious how to do this right,
but I find it hard to understand this.

Have you tried building something that links with the libc provided by
this musl package instead of the GNU libc?  I’m not opposed to adding
the package, but I’d like it to be usable.

~~ Ricardo

Re: [PACKAGE] musl libc

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> Vincent Legoll <vincent.legoll@gmail.com> writes:
>
>> On Wed, Aug 3, 2016 at 1:24 PM, Ricardo Wurmus <rekado@elephly.net> wrote:
>>> I just built musl and found that it also installs “bin/musl-gcc”, a
>>> wrapper of sorts, but it doesn’t work as it depends on a “gcc”
>>> executable to be available.
>>
>> I did not see that as I probably had gcc installed in the profile with
>> which i built musl...
>>
>>> Is this something that needs to work in order for this package to be
>>> useful?
>>
>> Maybe not, but the default / documented way it is to be used is with
>> the wrapper, so it is nice to have...
>>
>> Is this not the same with glibc, but in a more hidden way ?
>
> We usually don’t use the “gcc” package directly in Guix.  Instead we use
> “gcc-toolchain”, which also comes with a wrapper around the linker that
> ensures that binaries are linked with libraries in the store, ensuring
> that things generally just work™.
>
> I think more work would be needed to ensure that packages can actually
> successfully be linked with musl, but I’m not at all familiar with this.
> I had mixed success with a GCC ARM cross-compiler toolchain linking with
> newlib, so I know that it’s not exactly obvious how to do this right,
> but I find it hard to understand this.
>
> Have you tried building something that links with the libc provided by
> this musl package instead of the GNU libc?  I’m not opposed to adding
> the package, but I’d like it to be usable.
>
> ~~ Ricardo
>
>

Is this package in a state where I can review sinit with it? It would be
good if someone can comment on sinit too, as I commented on musl in
general there too.

-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org

Re: [PACKAGE] musl libc

[Vincent Legoll]

>> We usually don’t use the “gcc” package directly in Guix.  Instead we use
>> “gcc-toolchain”, which also comes with a wrapper around the linker that
>> ensures that binaries are linked with libraries in the store, ensuring
>> that things generally just work™.
>>
>> I think more work would be needed to ensure that packages can actually
>> successfully be linked with musl, but I’m not at all familiar with this.
>> I had mixed success with a GCC ARM cross-compiler toolchain linking with
>> newlib, so I know that it’s not exactly obvious how to do this right,
>> but I find it hard to understand this.
>>
>> Have you tried building something that links with the libc provided by
>> this musl package instead of the GNU libc?  I’m not opposed to adding
>> the package, but I’d like it to be usable.

I'm not sure...

I built musl, made the sinit package use the musl-wrapper as CC,
and it worked (it builds => it works) but couldn't test that sinit as
replacement for pid 1...

-- 
Vincent Legoll

Re: [PACKAGE] musl libc

[ng0]

Hi,

Vincent Legoll <vincent.legoll@gmail.com> writes:

>>> We usually don’t use the “gcc” package directly in Guix.  Instead we use
>>> “gcc-toolchain”, which also comes with a wrapper around the linker that
>>> ensures that binaries are linked with libraries in the store, ensuring
>>> that things generally just work™.
>>>
>>> I think more work would be needed to ensure that packages can actually
>>> successfully be linked with musl, but I’m not at all familiar with this.
>>> I had mixed success with a GCC ARM cross-compiler toolchain linking with
>>> newlib, so I know that it’s not exactly obvious how to do this right,
>>> but I find it hard to understand this.
>>>
>>> Have you tried building something that links with the libc provided by
>>> this musl package instead of the GNU libc?  I’m not opposed to adding
>>> the package, but I’d like it to be usable.
>
> I'm not sure...
>
> I built musl, made the sinit package use the musl-wrapper as CC,
> and it worked (it builds => it works) but couldn't test that sinit as
> replacement for pid 1...

I was wondering what happened to musl? Are there any problems left,
anything the people you have been working with can help you to solve? I
had the impression it was almost ready.

> -- 
> Vincent Legoll

Re: [PACKAGE] musl libc

[David Craven]

> I was wondering what happened to musl? Are there any problems left,
> anything the people you have been working with can help you to solve? I
> had the impression it was almost ready.

Depends on what you consider ready. It's ready for creating a gcc6
musl toolchain... If you want to use it for guixsd you'll also need to
patch ~every package in the base system, since many packages do #ifdef
GLIBC_2.23 #elifdef GLIBC_2.24 etc... that doesn't work well with
musl.

Re: [PACKAGE] musl libc

[ng0]

David Craven <david@craven.ch> writes:

>> I was wondering what happened to musl? Are there any problems left,
>> anything the people you have been working with can help you to solve? I
>> had the impression it was almost ready.
>
> Depends on what you consider ready. It's ready for creating a gcc6
> musl toolchain... If you want to use it for guixsd you'll also need to
> patch ~every package in the base system, since many packages do #ifdef
> GLIBC_2.23 #elifdef GLIBC_2.24 etc... that doesn't work well with
> musl.
>

That's not what's needed to get the package itself into the tree.... I
know the obstacles one has with musl, from Gentoo. So if it builds, and
at least one package compiles with it, that's enough to be honest. There
will be one hell of a roadtrip if you intend to fix EVERYTHING for
musl to be satisfied enough to get it into master.
-- 

Re: [PACKAGE] musl libc

[David Craven]

I assume you didn't search for define-public musl in the guix source
tree? It's in gnu/packages/musl.scm

Re: [PACKAGE] musl libc

[ng0]

David Craven <david@craven.ch> writes:

> I assume you didn't search for define-public musl in the guix source
> tree? It's in gnu/packages/musl.scm

ha! okay, i think I had a very old branch when I searched... thanks for
clearing that up.

-- 

Re: [PACKAGE] musl libc

[David Craven]

> I just built musl and found that it also installs ?bin/musl-gcc?, a
> wrapper of sorts, but it doesn?t work as it depends on a ?gcc?
> executable to be available.

With gcc 6 the wrapper isn't necessary anymore. You can disable it
with "--disable-gcc-wrapper". Other configure-flags that we probably
want are "--enable-shared" "--enable-static".

Next step is getting a toolchain setup. Maybe you can take inspiration
from this PR here =)
https://github.com/NixOS/nixpkgs/pull/16217/files

Re: [PACKAGE] musl libc

[Ricardo Wurmus]

David Craven <david@craven.ch> writes:

>> I just built musl and found that it also installs ?bin/musl-gcc?, a
>> wrapper of sorts, but it doesn?t work as it depends on a ?gcc?
>> executable to be available.
>
> With gcc 6 the wrapper isn't necessary anymore. You can disable it
> with "--disable-gcc-wrapper". Other configure-flags that we probably
> want are "--enable-shared" "--enable-static".

Thank you for the hint.  I’ll add “--disable-gcc-wrapper” and push to
master.  We can add other configure flags once it becomes apparent that
they are needed.

Thank you, Vincent, for the contribution!

~~ Ricardo

Re: [PACKAGE] musl libc

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> David Craven <david@craven.ch> writes:
>
>>> I just built musl and found that it also installs ?bin/musl-gcc?, a
>>> wrapper of sorts, but it doesn?t work as it depends on a ?gcc?
>>> executable to be available.
>>
>> With gcc 6 the wrapper isn't necessary anymore. You can disable it
>> with "--disable-gcc-wrapper". Other configure-flags that we probably
>> want are "--enable-shared" "--enable-static".
>
> Thank you for the hint.  I’ll add “--disable-gcc-wrapper” and push to
> master.  We can add other configure flags once it becomes apparent that
> they are needed.
>
> Thank you, Vincent, for the contribution!

One more thing: I also updated the license.  Musl is released under
Expat.  Pushed to master as ce728f70e5ef8783a28652e382c2c9f61c7b4c06.

~~ Ricardo

Re: [PACKAGE] musl libc

[Vincent Legoll]

On Sat, Aug 13, 2016 at 11:32 AM, Ricardo Wurmus <rekado@elephly.net> wrote:
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> David Craven <david@craven.ch> writes:
>>
>>>> I just built musl and found that it also installs ?bin/musl-gcc?, a
>>>> wrapper of sorts, but it doesn?t work as it depends on a ?gcc?
>>>> executable to be available.
>>>
>>> With gcc 6 the wrapper isn't necessary anymore. You can disable it
>>> with "--disable-gcc-wrapper". Other configure-flags that we probably
>>> want are "--enable-shared" "--enable-static".
>>
>> Thank you for the hint.  I’ll add “--disable-gcc-wrapper” and push to
>> master.  We can add other configure flags once it becomes apparent that
>> they are needed.

Thank you

> One more thing: I also updated the license.  Musl is released under
> Expat.  Pushed to master as ce728f70e5ef8783a28652e382c2c9f61c7b4c06.

Official site pages:

http://www.etalabs.net/compare_libcs.html
http://www.musl-libc.org/intro.html

both says MIT, as does :

$ head -1 COPYRIGHT
musl as a whole is licensed under the following standard MIT license:

$ grep -ri expat *

So where do you found this expat license reference ?
I'm curious, as it looks like I wouldn't have been able to found that myself...

-- 
Vincent Legoll

Re: [PACKAGE] musl libc

[David Craven]

this is what wikipedia has to say about it:

Because MIT has used many licenses for software, the Free Software
Foundation considers "MIT License" ambiguous. "MIT License" may refer
to the "Expat License" (used for Expat) or to the "X11 License" (also
called "MIT/X Consortium License"; used for the X Window System by the
MIT X Consortium). The "MIT License" published by the Open Source
Initiative is the same as the "Expat License".

Re: [PACKAGE] musl libc

[Vincent Legoll]

On Sat, Aug 13, 2016 at 11:55 AM, David Craven <david@craven.ch> wrote:
> this is what wikipedia has to say about it:

Yes, I already knew about the MIT ambiguities, I thought (my bad) that the file
param in (x11-style "file://COPYRIGHT") was designed just for that...

But where does the disambiguation choice to expat come from ?

-- 
Vincent Legoll

Re: [PACKAGE] musl libc

[David Craven]

> But where does the disambiguation choice to expat come from ?

I'm no expert, but I think that the difference is only in that the x11
license has an amendment.

Except as contained in this notice, the name of the X Consortium shall
not be used in advertising or otherwise to promote the sale, use or
other dealings in this Software without prior written authorization
from the X Consortium.

X Window System is a trademark of X Consortium, Inc.

[0] https://en.wikipedia.org/wiki/MIT_License

Re: [PACKAGE] musl libc

[Ricardo Wurmus]

David Craven <david@craven.ch> writes:

>> But where does the disambiguation choice to expat come from ?
>
> I'm no expert, but I think that the difference is only in that the x11
> license has an amendment.

Correct.  I looked at the actual license in the COPYRIGHT file and it
looked like Expat, not like X11.  (In Guix we don’t use the name “MIT”,
because it is ambiguous.)  I added a comment to point at the COPYRIGHT
file for details of the third-party pieces under non-copyleft licenses.

~~ Ricardo

Re: [PACKAGE] musl libc

[David Craven]

Vincent, can you run file and readelf -d on the sinit binary you
compiled using the gcc-musl wrapper? That will tell us if it worked.

The output of readelf -d should look like this:

0x0000000000000001 (NEEDED)             Shared library: [libc.so]
0x000000000000001d (RUNPATH)           Library runpath:
[/nix/store/16c974l1kqra3cr475gcgy2gsii45liq-musl-1.1.14/lib]

and the output of file should look like this:

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter
/nix/store/16c974l1kqra3cr475gcgy2gsii45liq-musl-1.1.14/lib/libc.so,
not stripped

Re: [PACKAGE] musl libc

[Vincent Legoll]

> Vincent, can you run file and readelf -d on the sinit binary you
> compiled using the gcc-musl wrapper? That will tell us if it worked.
>
> The output of readelf -d should look like this:
>
> 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
> 0x000000000000001d (RUNPATH)           Library runpath:
> [/nix/store/16c974l1kqra3cr475gcgy2gsii45liq-musl-1.1.14/lib]
>
> and the output of file should look like this:
>
> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked, interpreter
> /nix/store/16c974l1kqra3cr475gcgy2gsii45liq-musl-1.1.14/lib/libc.so,
> not stripped

The default sinit build process uses -static, so I get:

$ l /gnu/store/zfbhkbcfjpmnarsid9wl0q4ssswps96p-sinit-1.0/bin/sinit
-r-xr-xr-x 2 root root 9.3K Jan  1  1970
/gnu/store/zfbhkbcfjpmnarsid9wl0q4ssswps96p-sinit-1.0/bin/sinit

$ file /gnu/store/zfbhkbcfjpmnarsid9wl0q4ssswps96p-sinit-1.0/bin/sinit
/gnu/store/zfbhkbcfjpmnarsid9wl0q4ssswps96p-sinit-1.0/bin/sinit: ELF
64-bit LSB executable, x86-64, version 1 (SYSV), statically linked,
stripped

$ readelf -d /gnu/store/zfbhkbcfjpmnarsid9wl0q4ssswps96p-sinit-1.0/bin/sinit
There is no dynamic section in this file.

And I think that shows it worked, just the static way...

Do you prefer dynamically linked ?

-- 
Vincent Legoll

Re: [PACKAGE] musl libc

[David Craven]

> Do you prefer dynamically linked ?

Usually we link stuff dynamically unless there is a reason to do
otherwise. I guess in this case it's ok... Maybe someone else wants to
answer this?