[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/20391] New: ar on native Windows stores localtime, not UTC
From: |
konrad.schwarz at siemens dot com |
Subject: |
[Bug binutils/20391] New: ar on native Windows stores localtime, not UTC times tamps in archives |
Date: |
Wed, 20 Jul 2016 12:25:31 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=20391
Bug ID: 20391
Summary: ar on native Windows stores localtime, not UTC times
tamps in archives
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: konrad.schwarz at siemens dot com
Target Milestone: ---
I am using a cross-compiler tool chain compiled for native Windows in a Cygwin
build environment, i.e. Cygwin make.
The tool chain is from Canonical Launchpad, version:
GNU Tools for ARM Embedded Processors 5.0
- Q4 2015
* binutils : 2.26 prerelease with mainline backports
git://sourceware.org/git/binutils-gdb.git commit
03f87942b6a216bc5cd07c5cfbb5ce5ad8185133
My makefile uses lib: lib(member) rules, i.e., make relies on
the time stamps of member files in archives. Cygwin make reports
clock skew for the member file -- typically slightly less than an hour,
and does not update the archive.
I am one hour west of UTC.
Here is the output of Cygwin ar vs. the cross-compiler's ar:
$ ar tv libarm_mp_startup.a
rw-rw-rw- 0/0 57960 Jun 23 00:21 2016 ticker.o
rw-rw-rw- 0/0 18584 Jul 20 14:38 2016 startup.o
$ arm-none-eabi-ar tv libarm_mp_startup.a
rw-rw-rw- 0/0 57960 Jun 22 23:21 2016 ticker.o
rw-rw-rw- 0/0 18584 Jul 20 13:38 2016 startup.o
$ date
Wed, Jul 20, 2016 2:22:55 PM
It seems clear that the natively compiled ar is at fault here: it is
storing localtime and not UTC as the archive member's time stamps.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug binutils/20391] New: ar on native Windows stores localtime, not UTC times tamps in archives,
konrad.schwarz at siemens dot com <=