Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Nov 2013 00:48:06 -0500
From: Rich Felker <>
Subject: Storing version information in


The main agenda item I have left for the 0.9.15 release is making it
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

As for the build system, the proposed rule for generating version.c
is this:

src/internal/version.c: VERSION $(wildcard .git .git/*)
	sh tools/ > $@

The use of $(wildcard) should handle the case where .git does not
exist (release tarballs) and avoids gratuitous dependency on git

FYI for anyone who doesn't want to actually try running the proposed, 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)


Download attachment "" 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.