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.