Bug 1155273 - ar: `u' modifier ignored since `D' is the default (see `U') [NEEDINFO]
ar: `u' modifier ignored since `D' is the default (see `U')
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: automake (Show other bugs)
26
All Linux
high Severity high
: ---
: ---
Assigned To: Pavel Raiskup
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ARMTracker 1216905
  Show dependency treegraph
 
Reported: 2014-10-21 15:01 EDT by Richard W.M. Jones
Modified: 2017-02-28 04:38 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1216905 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pbrobinson: needinfo? (praiskup)
pbrobinson: needinfo? (praiskup)


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2014-10-21 15:01:06 EDT
Description of problem:

During linking(?) 'ar' prints a few warnings like this:

ar: `u' modifier ignored since `D' is the default (see `U')

Example:

libtool: link: ar cru .libs/liberrnostring.a .libs/liberrnostring_la-errnostring-gperf.o .libs/liberrnostring_la-errnostring.o 
ar: `u' modifier ignored since `D' is the default (see `U')

Version-Release number of selected component (if applicable):

binutils-2.24-23.fc22.aarch64

How reproducible:

100%

Steps to Reproduce:

Seems to happen when linking any static libs.
Comment 1 Nick Clifton 2014-10-24 12:00:00 EDT
Hi Richard,

  The warning message is correct.  Deterministic archives do not store file timestamps, so the 'u' option to only replace newer files cannot work.  If you are able to modify the build machinery for your project you can fix the problem by either using "ar cr ..." or "ar crUu ..." depending upon whether you want to maintain the deterministic nature of the libraries or not.  (I recommend the former).

Cheers
  Nick

PS.  Deterministic libraries were made the default when the binutils rpm is built because of this BZ:

  bugzilla.redhat.com/show_bug.cgi?id=1124342
Comment 2 Richard W.M. Jones 2014-10-24 12:02:19 EDT
Fair enough.  Maybe this is a bug in libtool/automake/whatever it
is that runs 'ar'?
Comment 3 Jakub Jelinek 2014-10-24 12:10:25 EDT
I'd think ar cruv being used widely everywhere.  If the problem is just that you want *.a libraries packaged in the distro without timestamps/uids/gids in them, perhaps some rpm macro/script (like the brp-strip-comment-note etc.) that would remove that from the *.a files that are going to be packaged would be a better solution...
Comment 4 Jaroslav Reznik 2015-03-03 11:23:23 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 5 Nathaniel McCallum 2015-03-26 14:20:57 EDT
I think the proper place for this is automake. This is triggered by any automake library build.
Comment 6 Richard W.M. Jones 2015-03-26 16:09:21 EDT
Still happens in Rawhide.  Although I don't believe it causes any
actual problem.
Comment 8 Petr Pisar 2015-04-28 08:29:10 EDT
I can see this warning even on x86_64 when building pcre-8.37 with these packages:

automake-1.15-1.fc22.noarch
libtool-2.4.6-4.fc23.x86_64
binutils-2.25-8.fc23.x86_64
Comment 9 Karel Zak 2015-05-28 06:05:30 EDT
Well, after upgrade from f21 to f22 I see the message too. 

Please, fix it ASAP. It's pretty annoying to have extra warnings generated by build-system.
Comment 10 Pavel Raiskup 2015-06-02 10:27:12 EDT
Complementary Automake patch:
ttp://www.mail-archive.com/automake-patches@gnu.org/msg07705.html
Comment 11 Peter Robinson 2015-06-16 10:16:03 EDT
What's the status on this? It's causing issues on building pixman too.

/bin/sh ../libtool  --tag=CC   --mode=link gcc -fopenmp -flto -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -pthread -flto -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -Wdeclaration-after-statement -fno-strict-aliasing -fvisibility=hidden -fopenmp  -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -pthread -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libutils.la  utils.lo utils-prng.lo   -lm 
libtool: link: ar cru .libs/libutils.a .libs/utils.o .libs/utils-prng.o 
ar: `u' modifier ignored since `D' is the default (see `U')
BFD: .libs/utils.o: plugin needed to handle lto object
BFD: .libs/utils-prng.o: plugin needed to handle lto object
libtool: link: ranlib .libs/libutils.a
BFD: utils.o: plugin needed to handle lto object
BFD: utils-prng.o: plugin needed to handle lto object
libtool: link: ( cd ".libs" && rm -f "libutils.la" && ln -s "../libutils.la" "libutils.la" )
Comment 12 Nick Clifton 2015-06-16 13:04:59 EDT
Hi Guys,

  The current status is that this is considered to be an automake bug not a binutils bug.  The patch referred in to comment #10 should fix automake, but I do not know if this is being considered for inclusion in the Fedora automake package.

Cheers
  Nick
Comment 13 Pavel Raiskup 2015-06-17 03:35:41 EDT
Peter, I'm waiting for (a) upstream inclusion in case of automake, (b) for
some comment on upstream libtool bug (and patch).

With autotools, it is always risky to patch downstream .. because the changes
we make downstream will affect not only Fedora (via 'make dist' you could
produce broken tarballs for everybody).

And note, even if I backpatch fixes from upstream, the warning will still
exist until we run autoreconf in each affected package.  Give me a day or two,
I pinged upstream once more.

Also, there is a workaround mentioned in thread [1] (to specify ARFLAGS &
AR_FLAGS to 'cr').

[1] https://www.mail-archive.com/bug-automake@gnu.org/msg04238.html
Comment 14 Jan Kurik 2015-07-15 10:37:08 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 15 Nathaniel McCallum 2016-03-08 17:28:49 EST
Any update?
Comment 16 Pavel Raiskup 2016-03-09 01:29:46 EST
Fixed in libtool, automake is not fixed yet upstream.  The libtool
release 2.4.7 is expected to happen soon.
Comment 17 Peter Robinson 2016-08-31 08:01:52 EDT
What's the status on the "expected to happen soon" libtool release?
Comment 18 Fedora End Of Life 2016-11-24 06:15:37 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 19 Fedora End Of Life 2017-02-28 04:38:10 EST
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

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