Description of problem:
The ar command insert objects in libraries without the correct timestamp (or with a missing timestamp)
Version-Release number of selected component (if applicable):
Every time you execute the ar command, the bug shows up
Steps to Reproduce:
1. touch garbage.o
2. ar rv libdummy.a garbage.o
3. ar tv libdummy.a garbage.o
rw-r--r-- 0/0 0 Dec 31 16:00 1969 garbage.o
rw-rw-r-- 1000/1000 0 Feb 24 10:58 2015 garbage.o
ar shipped with binutils version 2.25-3.fc22 works as expected
This is a deliberate feature, not a bug.
By default the Fedora ar command creates deterministic archives, which do not contain time stamps. This means that two archives created at different times but containing the same files will compare the same. See BZ 1124342 for more details:
If you want to include the timestamps in an archive you can use the 'U' modifier, as in:
ar rvU libdummy.a garbage.o
When was this -U option first introduced in ar? Is it just in the fedora tree or is it in the mainline binutils source base?
I am a bit puzzled by the fact that 1) -U seems a new options and 2) it is needed to reproduce ar previous behavior.
The -U option was introduced in January 2013 to the mainline binutils sources, although support for deterministic archives has been in since March 2012.
There is a configure time option to make non-deterministic archives the default - and hence remove the need for the U option. I am not sure that this is such a good idea for Fedora however. Deterministic behaviour is a useful trait, whereas timestamps in archives, is, in my opinion at least, less important.
*** Bug 1225186 has been marked as a duplicate of this bug. ***
IMO it would be much better to reenable timestamps in the archives by default again, and only remove timestamps from the archives in some rpm build root policy script (like we have brp-* script that strips *.a archives, it could as well turn them into deterministic ones).
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.
(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)
More information and reason for this action is here:
Wow. It's deliberate?!? I wonder how many other build systems it breaks...
I can see how this is a nice feature for release builds but it breaks uncountable makefiles and makes fedora unfriendly for developers by the act of wasting their time.
I think it would be better to set ARFLAGS to rvD on the release build hosts where one always makes full builds and let ar work as it always have for everyone else.
OK, well the people have spoken, so I have made the change:
This binutils has an archiver that stores timestamps be default. The choice can be changed be editing the binutils.spec file at line 18, which currently has:
%define enable_deterministic_archives 0
Are there some ar flags where ar would remove timestamps etc. from existing archive? If yes, that should be something that should be run on all ar archives by some new brp-* policy.
In theory this ought to work:
ar mD libfoo.a `ar t libfoo.a`
but unfortunately there is a bug in the ar implementation which means that the non-deterministic nature of the library is not changed.
The operation could be performed by a script however:
cp libfoo.a /tmp
ar x libfoo.a
ar crD libfoo.a *
mv /tmp/libfoo.a .
The unpacking and creating the archive again is fine I think for the brp-* script, after all it is a shell script.
It will need to use mktemp, /tmp/ can contain lots of other files you don't want to add into the archives. Also, using ar t libfoo.a.orig as the list of ar crD arguments after libfoo.a is desirable, so that file ordering within the archives is preserved.
(In reply to Jakub Jelinek from comment #10)
> Are there some ar flags where ar would remove timestamps etc. from existing
> archive? If yes, that should be something that should be run on all ar
> archives by some new brp-* policy.
There is no ar flag but it seems as if
objcopy --enable-deterministic-archives libfoo.a
makes the library deterministic.
(In reply to Nick Clifton from comment #9)
> OK, well the people have spoken, so I have made the change:
> This binutils has an archiver that stores timestamps be default. The choice
> can be changed be editing the binutils.spec file at line 18, which currently
> %define enable_deterministic_archives 0
Thanks, this is excellent.
Is there any chance that these changes will be backported to fc22 and fc23?
(In reply to Magnus Fromreide from comment #14)
> Is there any chance that these changes will be backported to fc22 and fc23?
I think that I need some advice on this. Given that the patch will change the default behaviour of the archiver, is it a good idea to apply the patch to releases that have already gone out ?
I think a precondition of contemplating about backporting this is that it is dealt with on the rpm side first (starting with f24, then backported to f23 and f22), so that some brp-* policy runs that objcopy -D lib*.a on all the libraries in the install root.
Once that is done, tested and the erratas are pushed in, I would say backporting the binutils change would be appreciated.
(In reply to Jakub Jelinek from comment #16)
> I think a precondition of contemplating about backporting this is that it is
> dealt with on the rpm side first (starting with f24, then backported to f23
> and f22), so that some brp-* policy runs that objcopy -D lib*.a on all the
> libraries in the install root.
> Once that is done, tested and the erratas are pushed in, I would say
> backporting the binutils change would be appreciated.
Apologies for my ignorance, but what is a "brp-*" policy and how do I go about setting one up ? Or is this something that someone should be doing ?
$ rpm -ql rpm-build redhat-rpm-config | grep brp-
then runs the various scripts, usually from the %__os_install_post macro.
So, we need another script, which will look similarly to brp-strip-static-archive, but will not ignore usr/lib/debug libraries, and will run objdump -D on them rather than strip -g.
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 23 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.