[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131127054806.GA11224@brightrain.aerifal.cx>
Date: Wed, 27 Nov 2013 00:48:06 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Storing version information in libc.so
Hi,
The main agenda item I have left for the 0.9.15 release is making it
so libc.so can print its own version number. I'm attaching the
proposed build script that will generate version.c for comments on any
problems it might have or improvements to make.
At present, I have the script setup to generate a function which
returns the version string. This is in contrast to the other obvious
implementations, which would be a macro or an extern array object. The
macro is inappropriate because I don't want a large file like
dynlink.c to be recompiled each time the version changes (which, with
git, happens on each commit). The extern array is obviously nicer
looking than the function, but at the point where it needs to be used
in dynlink.c, relocations have not been performed and thus it's not
accessible. Arguably this should just be "fixed", since operating
without relocations for "usage" or "ldd" output is moderately hackish
anyway.
As for the build system, the proposed rule for generating version.c
is this:
src/internal/version.c: VERSION $(wildcard .git .git/*)
sh tools/version.sh > $@
The use of $(wildcard) should handle the case where .git does not
exist (release tarballs) and avoids gratuitous dependency on git
internals.
FYI for anyone who doesn't want to actually try running the proposed
version.sh, the output it's producing looks like:
- "0.9.14-git-79-ga663c93" (with git command available)
- "0.9.14-git-unknown" (with .git present but no git command)
- "0.9.14" (with no .git)
Rich
Download attachment "version.sh" of type "application/x-sh" (328 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
