On Wed, Mar 20, 2013 at 02:36:32AM -0400, Andrew Rodland wrote: > While investigating this StackOverflow question: > http://stackoverflow.com/questions/15516168/how-to-cross-compile-git-for-arm > I found that fetch-pack.c uses ST_MTIME_NSEC outside of the protection > of #ifdef USE_NSEC. This results in a broken build if > !defined(USE_NSEC) && !defined(NO_NSEC) and the target system doesn't > happen to be recent glibc. Right; the point of NO_NSEC is to tell git that your libc does not have those fields. If it's not set, then it is a bug in your config.mak (or in the autoconf script, if you are using it). That being said, I really don't see the point of having both USE_NSEC and NO_NSEC. If you do not set USE_NSEC (which most people do not; it is off by default), what is the point of not setting NO_NSEC? As far as I can tell, it means we will copy stat information out "struct st" into the index, but we will not actually _use_ it for anything. Should there just be a single option USE_NSEC that defaults to off? And if it is not set, we do not even bother caring whether libc provides nsec fields, since we are not going to use them for anything (i.e., we just do the equivalent of NO_NSEC now). Which I think is the direction you are proposing with your patches below, but the rationale should be "why bother requiring users to use the NO_NSEC knob explicitly when we know we do not care about its value anyway". But maybe there is some subtle reason I'm missing for having the two options separate. Or maybe it's just a historical accident that we ended up here. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html