Bug 1195883 - ar command inserting objects with wrong timestamp
ar command inserting objects with wrong timestamp
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
23
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Nick Clifton
Fedora Extras Quality Assurance
:
: 1225186 (view as bug list)
Depends On:
Blocks: 1196616
  Show dependency treegraph
 
Reported: 2015-02-24 14:08 EST by Edoardo Apra
Modified: 2016-12-20 08:17 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 08:17:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Edoardo Apra 2015-02-24 14:08:35 EST
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
Comment 1 Nick Clifton 2015-02-27 05:03:54 EST
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
Comment 2 Edoardo Apra 2015-02-27 12:34:26 EST
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
Comment 3 Nick Clifton 2015-03-03 04:45:55 EST
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
Comment 4 Paul 2015-05-26 15:08:19 EDT
*** Bug 1225186 has been marked as a duplicate of this bug. ***
Comment 5 Jakub Jelinek 2015-05-26 15:18:17 EDT
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).
Comment 6 Jan Kurik 2015-07-15 10:29:57 EDT
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
Comment 7 Tom Hughes 2015-08-26 04:37:16 EDT
Wow. It's deliberate?!? I wonder how many other build systems it breaks...
Comment 8 Magnus Fromreide 2015-09-09 15:49:18 EDT
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.
Comment 9 Nick Clifton 2015-09-10 05:37:52 EDT
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
Comment 10 Jakub Jelinek 2015-09-10 05:55:22 EDT
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.
Comment 11 Nick Clifton 2015-09-10 07:37:09 EDT
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
Comment 12 Jakub Jelinek 2015-09-10 07:44:51 EDT
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.
Comment 13 Magnus Fromreide 2015-09-10 08:32:28 EDT
(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.
Comment 14 Magnus Fromreide 2015-09-10 12:38:16 EDT
(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?
Comment 15 Nick Clifton 2015-09-11 13:22:26 EDT
(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
Comment 16 Jakub Jelinek 2015-09-11 13:25:20 EDT
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.
Comment 17 Nick Clifton 2015-09-14 06:56:09 EDT
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
Comment 18 Jakub Jelinek 2015-09-14 07:02:39 EDT
$ 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.
Comment 19 Fedora End Of Life 2016-11-24 06:29:14 EST
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.
Comment 20 Fedora End Of Life 2016-12-20 08:17:07 EST
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.

Note You need to log in before you can comment on or make changes to this bug.