From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4288 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Storing version information in libc.so Date: Wed, 27 Nov 2013 00:48:06 -0500 Message-ID: <20131127054806.GA11224@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" X-Trace: ger.gmane.org 1385531293 28042 80.91.229.3 (27 Nov 2013 05:48:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Nov 2013 05:48:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4292-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 27 06:48:20 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VlXz1-0008Tt-KB for gllmg-musl@plane.gmane.org; Wed, 27 Nov 2013 06:48:19 +0100 Original-Received: (qmail 5906 invoked by uid 550); 27 Nov 2013 05:48:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5898 invoked from network); 27 Nov 2013 05:48:18 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4288 Archived-At: --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --Dxnq1zWXvFF0Q93v Content-Type: application/x-sh Content-Disposition: attachment; filename="version.sh" Content-Transfer-Encoding: quoted-printable #!/bin/sh=0A=0Aver=3D$(cat VERSION)=0A=0Aif test -d .git ; then=0Aif type g= it >/dev/null 2>&1 ; then=0Atmp=3D$(git describe --tags --match v"$ver" 2>/= dev/null)=0Aif test "${tmp%%-*}" =3D "v$ver" ; then=0Atmp=3D${tmp#*-}=0Aels= e=0Atmp=3Dunknown=0Afi=0Aelse=0Atmp=3Dunknown=0Afi=0Aver=3D$ver-git-$tmp=0A= fi=0A=0Aprintf 'const char *__libc_version()\n{\n\treturn "%s";\n}\n' "$ver= "=0A --Dxnq1zWXvFF0Q93v--