Re: supporting deterministic 'ar'

[Cary Coutant <ccoutant at google dot com>]

> Wasn't sure if this would be acceptable.  I didn't find any other uses
> of LONG_MAX in bfd, and only one of INT_MAX... and libiberty rolls its
> own, so i figured i'd check.

It's not clear to me that just setting the timestamps to 0 wouldn't be
sufficient. Neither gnu ld nor gold seem to complain if the file's
timestamp is newer than that of the symbol table. The code in BFD that
jumps through hoops to make sure that doesn't happen is for the
benefit of other linkers that, arguably, are checking the wrong thing
-- they really should be comparing the symbol table's timestamp with
those of the archive members rather than that of the file itself. It
should be acceptable to say "don't use this option if you're using one
of those linkers" (or get the vendor to at least fix the linker so
that a timestamp of 0 is always treated as OK).

The tool we're currently using internally at Google to patch the
archives after the fact just sets the timestamp to 0 with no ill
effects.

Alternatively, you could punt the problem to the user, and add a
--timestamp=str option, where str is a getdate()-compatible date
string. (And add --uid=n and --gid=n options as well. That would solve
your problem of what to call the option.)

-cary