Feature request

Feature request

[Paul Schutte]

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

Hi Guys,

Would it be possible for you to add the version of musl to the output of
libc.so ?

root@sabotage:~# /lib/libc.so
musl libc/dynamic program loader
usage: /lib/libc.so pathname [args]

I have several machines with musl on it and it will be very helpful to see
which version is installed.

Regards
Paul

[-- Attachment #2: Type: text/html, Size: 517 bytes --]

Re: Feature request

[Rich Felker]

On Mon, Oct 28, 2013 at 08:13:09PM +0000, Paul Schutte wrote:
> Hi Guys,
> 
> Would it be possible for you to add the version of musl to the output of
> libc.so ?
> 
> root@sabotage:~# /lib/libc.so
> musl libc/dynamic program loader
> usage: /lib/libc.so pathname [args]
> 
> I have several machines with musl on it and it will be very helpful to see
> which version is installed.

Indeed, this has been something I've wanted to add for a while, and
which should definitely be in for 1.0. It's just a matter of doing the
right thing in the build and release system to get the version in
there, and it's not clear what the version should read for git builds
between versions. I think this is a good chance to discuss that.

Rich

Re: Feature request

[Luca Barbato]

On 29/10/13 03:33, Rich Felker wrote:
> On Mon, Oct 28, 2013 at 08:13:09PM +0000, Paul Schutte wrote:
>> Hi Guys,
>>
>> Would it be possible for you to add the version of musl to the output of
>> libc.so ?
>>
>> root@sabotage:~# /lib/libc.so
>> musl libc/dynamic program loader
>> usage: /lib/libc.so pathname [args]
>>
>> I have several machines with musl on it and it will be very helpful to see
>> which version is installed.
> 
> Indeed, this has been something I've wanted to add for a while, and
> which should definitely be in for 1.0. It's just a matter of doing the
> right thing in the build and release system to get the version in
> there, and it's not clear what the version should read for git builds
> between versions. I think this is a good chance to discuss that.

git describe short signature might be the best option.

lu

Re: Feature request

[Rich Felker]

On Tue, Oct 29, 2013 at 03:48:21AM +0100, Luca Barbato wrote:
> On 29/10/13 03:33, Rich Felker wrote:
> > On Mon, Oct 28, 2013 at 08:13:09PM +0000, Paul Schutte wrote:
> >> Hi Guys,
> >>
> >> Would it be possible for you to add the version of musl to the output of
> >> libc.so ?
> >>
> >> root@sabotage:~# /lib/libc.so
> >> musl libc/dynamic program loader
> >> usage: /lib/libc.so pathname [args]
> >>
> >> I have several machines with musl on it and it will be very helpful to see
> >> which version is installed.
> > 
> > Indeed, this has been something I've wanted to add for a while, and
> > which should definitely be in for 1.0. It's just a matter of doing the
> > right thing in the build and release system to get the version in
> > there, and it's not clear what the version should read for git builds
> > between versions. I think this is a good chance to discuss that.
> 
> git describe short signature might be the best option.

Thanks for the git-fu help. I'm assuming you mean using something like
"git describe --tags"? Use of this could be contingent on either a
.git dir, or lack of a version file added to release tarballs. The
only thing that's not clear is how to handle non-release source trees
present on a build system that lacks a working git installation.

Rich

Re: Feature request

[Luca Barbato]

On 29/10/13 05:54, Rich Felker wrote:
> On Tue, Oct 29, 2013 at 03:48:21AM +0100, Luca Barbato wrote:
>> On 29/10/13 03:33, Rich Felker wrote:
>>> On Mon, Oct 28, 2013 at 08:13:09PM +0000, Paul Schutte wrote:
>>>> Hi Guys,
>>>>
>>>> Would it be possible for you to add the version of musl to the output of
>>>> libc.so ?
>>>>
>>>> root@sabotage:~# /lib/libc.so
>>>> musl libc/dynamic program loader
>>>> usage: /lib/libc.so pathname [args]
>>>>
>>>> I have several machines with musl on it and it will be very helpful to see
>>>> which version is installed.
>>>
>>> Indeed, this has been something I've wanted to add for a while, and
>>> which should definitely be in for 1.0. It's just a matter of doing the
>>> right thing in the build and release system to get the version in
>>> there, and it's not clear what the version should read for git builds
>>> between versions. I think this is a good chance to discuss that.
>>
>> git describe short signature might be the best option.
> 
> Thanks for the git-fu help. I'm assuming you mean using something like
> "git describe --tags"? Use of this could be contingent on either a
> .git dir, or lack of a version file added to release tarballs. The
> only thing that's not clear is how to handle non-release source trees
> present on a build system that lacks a working git installation.

    if [ -d .git ]; then
	VER=$(git describe --always | sed -e "s:v::")
	if [ x"$(git diff-index --name-only HEAD)" != x ]; then
            VER="${VER}-dirty"
        fi
    elif [ -f .version ]; then
        VER=$(< .version)
    else
        VER="Unknown"
    fi

Or something along the lines.

lu

Re: Feature request

[Ivan Kanakarakis]

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

The $(< file) syntax is bash-only iirc.
git describe --always is what I though of too ;-]
but you won't have "serial versioning".
unless there is a version numer suffixed by that.




On 29 October 2013 07:06, Luca Barbato <lu_zero@gentoo.org> wrote:

> On 29/10/13 05:54, Rich Felker wrote:
> > On Tue, Oct 29, 2013 at 03:48:21AM +0100, Luca Barbato wrote:
> >> On 29/10/13 03:33, Rich Felker wrote:
> >>> On Mon, Oct 28, 2013 at 08:13:09PM +0000, Paul Schutte wrote:
> >>>> Hi Guys,
> >>>>
> >>>> Would it be possible for you to add the version of musl to the output
> of
> >>>> libc.so ?
> >>>>
> >>>> root@sabotage:~# /lib/libc.so
> >>>> musl libc/dynamic program loader
> >>>> usage: /lib/libc.so pathname [args]
> >>>>
> >>>> I have several machines with musl on it and it will be very helpful
> to see
> >>>> which version is installed.
> >>>
> >>> Indeed, this has been something I've wanted to add for a while, and
> >>> which should definitely be in for 1.0. It's just a matter of doing the
> >>> right thing in the build and release system to get the version in
> >>> there, and it's not clear what the version should read for git builds
> >>> between versions. I think this is a good chance to discuss that.
> >>
> >> git describe short signature might be the best option.
> >
> > Thanks for the git-fu help. I'm assuming you mean using something like
> > "git describe --tags"? Use of this could be contingent on either a
> > .git dir, or lack of a version file added to release tarballs. The
> > only thing that's not clear is how to handle non-release source trees
> > present on a build system that lacks a working git installation.
>
>     if [ -d .git ]; then
>         VER=$(git describe --always | sed -e "s:v::")
>         if [ x"$(git diff-index --name-only HEAD)" != x ]; then
>             VER="${VER}-dirty"
>         fi
>     elif [ -f .version ]; then
>         VER=$(< .version)
>     else
>         VER="Unknown"
>     fi
>
> Or something along the lines.
>
> lu
>



-- 
*Ivan c00kiemon5ter Kanakarakis*  >:3

[-- Attachment #2: Type: text/html, Size: 3457 bytes --]

Re: Feature request

[Georgi Chorbadzhiyski]

Around 10/29/2013 07:06 AM, Luca Barbato scribbled:
> On 29/10/13 05:54, Rich Felker wrote:
>> On Tue, Oct 29, 2013 at 03:48:21AM +0100, Luca Barbato wrote:
>>> On 29/10/13 03:33, Rich Felker wrote:
>>>> On Mon, Oct 28, 2013 at 08:13:09PM +0000, Paul Schutte wrote:
>>>>> Hi Guys,
>>>>>
>>>>> Would it be possible for you to add the version of musl to the output of
>>>>> libc.so ?
>>>>>
>>>>> root@sabotage:~# /lib/libc.so
>>>>> musl libc/dynamic program loader
>>>>> usage: /lib/libc.so pathname [args]
>>>>>
>>>>> I have several machines with musl on it and it will be very helpful to see
>>>>> which version is installed.
>>>>
>>>> Indeed, this has been something I've wanted to add for a while, and
>>>> which should definitely be in for 1.0. It's just a matter of doing the
>>>> right thing in the build and release system to get the version in
>>>> there, and it's not clear what the version should read for git builds
>>>> between versions. I think this is a good chance to discuss that.
>>>
>>> git describe short signature might be the best option.
>>
>> Thanks for the git-fu help. I'm assuming you mean using something like
>> "git describe --tags"? Use of this could be contingent on either a
>> .git dir, or lack of a version file added to release tarballs. The
>> only thing that's not clear is how to handle non-release source trees
>> present on a build system that lacks a working git installation.
> 
>     if [ -d .git ]; then
> 	VER=$(git describe --always | sed -e "s:v::")
> 	if [ x"$(git diff-index --name-only HEAD)" != x ]; then
>             VER="${VER}-dirty"
>         fi
>     elif [ -f .version ]; then
>         VER=$(< .version)
>     else
>         VER="Unknown"
>     fi
> 
> Or something along the lines.

I'm using this in a Makefile.

VERSION = $(shell cat RELEASE)
GIT_VER = $(shell git describe --tags --dirty --always 2>/dev/null)
ifeq "$(GIT_VER)" ""
GIT_VER = "release"
endif

-- 
Georgi Chorbadzhiyski | http://georgi.unixsol.org/ | http://github.com/gfto/

Re: Feature request

[Luca Barbato]

On 29/10/13 08:12, Ivan Kanakarakis wrote:
> The $(< file) syntax is bash-only iirc.
> git describe --always is what I though of too ;-]
> but you won't have "serial versioning".
> unless there is a version numer suffixed by that.
> 

You start with a v1.0 tag so you will get something along

musl 1.0-1a2b3cf or such,

lu

Re: Feature request

[Andrew Bradford]

On 10/29/13 00:54, Rich Felker wrote:
> On Tue, Oct 29, 2013 at 03:48:21AM +0100, Luca Barbato wrote:
>> On 29/10/13 03:33, Rich Felker wrote:
>>> On Mon, Oct 28, 2013 at 08:13:09PM +0000, Paul Schutte wrote:
>>>> Hi Guys,
>>>>
>>>> Would it be possible for you to add the version of musl to the output of
>>>> libc.so ?
>>>>
>>>> root@sabotage:~# /lib/libc.so
>>>> musl libc/dynamic program loader
>>>> usage: /lib/libc.so pathname [args]
>>>>
>>>> I have several machines with musl on it and it will be very helpful to see
>>>> which version is installed.
>>>
>>> Indeed, this has been something I've wanted to add for a while, and
>>> which should definitely be in for 1.0. It's just a matter of doing the
>>> right thing in the build and release system to get the version in
>>> there, and it's not clear what the version should read for git builds
>>> between versions. I think this is a good chance to discuss that.
>>
>> git describe short signature might be the best option.
> 
> Thanks for the git-fu help. I'm assuming you mean using something like
> "git describe --tags"? Use of this could be contingent on either a
> .git dir, or lack of a version file added to release tarballs.

Linux and u-boot use a script like [1].  Assuming the makefile has the
release version numbering in it and tags to match git, results in
'dirty', 'sha' and 'commits-since-last-tag' style addons to the version
number.  Like:

U-Boot SPL 2011.09-00036-ga61c346-dirty

Dirty (uncommitted changes), 36 commits since last tag, sha of a61c346
is HEAD.  Would this kind of notation work?

[1]:https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/setlocalversion

> The
> only thing that's not clear is how to handle non-release source trees
> present on a build system that lacks a working git installation.

How often is this a concern?
How are people obtaining non-release source trees not via an scm tool?

-Andrew

Re: Feature request

[Kurt H Maier]

Quoting Andrew Bradford <andrew@bradfordembedded.com>:

>
> How often is this a concern?
> How are people obtaining non-release source trees not via an scm tool?
>

By pulling on one machine and copying it to various build hosts.  The
fewer build dependencies, the better.

khm

Re: Feature request

[Szabolcs Nagy]

* Kurt H Maier <khm@sciops.net> [2013-10-29 18:53:38 +0000]:
> Quoting Andrew Bradford <andrew@bradfordembedded.com>:
> >How often is this a concern?
> >How are people obtaining non-release source trees not via an scm tool?
> >
> 
> By pulling on one machine and copying it to various build hosts.  The
> fewer build dependencies, the better.
> 

or building in a chroot
or in qemu from a v9fs mount
..

the build should not fail if git is unavailable

otherwise the version string is not critical in that case
(if it's a make variable then it can be overridden from
config.mak or from the make cmdline anyway)

Re: Feature request

[Rich Felker]

On Tue, Oct 29, 2013 at 08:23:43PM +0100, Szabolcs Nagy wrote:
> * Kurt H Maier <khm@sciops.net> [2013-10-29 18:53:38 +0000]:
> > Quoting Andrew Bradford <andrew@bradfordembedded.com>:
> > >How often is this a concern?
> > >How are people obtaining non-release source trees not via an scm tool?
> > >
> > 
> > By pulling on one machine and copying it to various build hosts.  The
> > fewer build dependencies, the better.
> > 
> 
> or building in a chroot
> or in qemu from a v9fs mount
> ...
> 
> the build should not fail if git is unavailable

Exactly.

> otherwise the version string is not critical in that case
> (if it's a make variable then it can be overridden from
> config.mak or from the make cmdline anyway)

It's not _critical_, but if it's horribly wrong, that defeats the
purpose of being able to determine the version installed. Perhaps a
good fallback approach would be:

1. Have a version file which always contains the most recent released
   version (i.e. it's updated in the tagged commit for the release).

2. At build time, if git is available and .git exists, use git
   describe to construct the version string.

3. Otherwise, use the version file (from #1 above), and if .git
   exists, append -unknown-git or similar to it so that it's clear
   that there may be changes beyond what was in the release.

Clearly the version string should make it into the dynamic linker's
usage output, but is there anywhere else it should be visible (such as
a string in static binaries, or a confstr() string)? I don't want to
go adding bloat that makes users mad, but it also may be frustrating
not to know what version a binary was linked with, so I think this is
a question that merits some discussion.

Rich

Re: Feature request

[Luca Barbato]

On 29/10/13 22:30, Rich Felker wrote:
> On Tue, Oct 29, 2013 at 08:23:43PM +0100, Szabolcs Nagy wrote:
>> * Kurt H Maier <khm@sciops.net> [2013-10-29 18:53:38 +0000]:
>>> Quoting Andrew Bradford <andrew@bradfordembedded.com>:
>>>> How often is this a concern?
>>>> How are people obtaining non-release source trees not via an scm tool?
>>>>
>>>
>>> By pulling on one machine and copying it to various build hosts.  The
>>> fewer build dependencies, the better.
>>>
>>
>> or building in a chroot
>> or in qemu from a v9fs mount
>> ...
>>
>> the build should not fail if git is unavailable
> 
> Exactly.
> 
>> otherwise the version string is not critical in that case
>> (if it's a make variable then it can be overridden from
>> config.mak or from the make cmdline anyway)
> 
> It's not _critical_, but if it's horribly wrong, that defeats the
> purpose of being able to determine the version installed. Perhaps a
> good fallback approach would be:

Ideally you have:

- the major/minor version in an header (you can pull it a valid version
from there anytime no matter what)
- a git tag matching it
- a script to get easily how far we are from the tag

So if you checkout from git you have the full information, if you build
from a release you have the full information, if you are building from a
snapshot you have a partial but arguably valid information.

lu