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): 2.25-6.fc23 How reproducible: 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 Actual results: rw-r--r-- 0/0 0 Dec 31 16:00 1969 garbage.o Expected results: rw-rw-r-- 1000/1000 0 Feb 24 10:58 2015 garbage.o Additional info: ar shipped with binutils version 2.25-3.fc22 works as expected
Hi Edoardo, 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: https://bugzilla.redhat.com/show_bug.cgi?id=1124342 If you want to include the timestamps in an archive you can use the 'U' modifier, as in: ar rvU libdummy.a garbage.o Cheers Nick
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. Thanks
Hi Edardo, 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. Cheers Nick
*** 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: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
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: binutils-2.25.1-5.fc24 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 Cheers Nick
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.
Hi Jakub, No. :-( 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 pushd /tmp ar x libfoo.a rm libfoo.a ar crD libfoo.a * popd mv /tmp/libfoo.a . Cheers Nick
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: > > binutils-2.25.1-5.fc24 > > 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 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 ? Cheers Nick
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.
Hi Jakub, (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 ? Cheers Nick
$ rpm -ql rpm-build redhat-rpm-config | grep brp- /usr/lib/rpm/brp-compress /usr/lib/rpm/brp-java-gcjcompile /usr/lib/rpm/brp-python-bytecompile /usr/lib/rpm/brp-python-hardlink /usr/lib/rpm/brp-strip /usr/lib/rpm/brp-strip-comment-note /usr/lib/rpm/brp-strip-shared /usr/lib/rpm/brp-strip-static-archive /usr/lib/rpm/redhat/brp-implant-ident-static /usr/lib/rpm/redhat/brp-java-repack-jars /usr/lib/rpm/redhat/macros 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' of '23'. 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.