ar in ubuntu_ltp test failed with 4.15 KVM

Bug #1765331 reported by Po-Hsu Lin on 2018-04-19
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
binutils
In Progress
High
ubuntu-kernel-tests
Undecided
Unassigned
binutils (Ubuntu)
Undecided
Unassigned
Nominated for Bionic by Po-Hsu Lin
linux (Ubuntu)
Undecided
Unassigned
Nominated for Bionic by Po-Hsu Lin
linux-kvm (Ubuntu)
Undecided
Unassigned
Nominated for Bionic by Po-Hsu Lin

Bug Description

ar tests in ubuntu_ltp has failed with 4.15.0-1004.4 kvm kernel

<<<test_start>>>
tag=ar stime=1523972462
cmdline="export TCdat=$LTPROOT/testcases/bin; ar01"
contacts=""
analysis=exit
<<<test_output>>>
ar01 1 TPASS: ar added new file after another (-a)
ar01 2 TPASS: ar moved file correctly (-ma)
ar01 3 TPASS: ar added new file before another (-b)
ar01 4 TPASS: ar moved file correctly (-mb)
ar01 5 TPASS: ar haven't produced output (-c)
ar01 6 TPASS: ar haven't produced output (-qc)
ar01 7 TPASS: ar deleted files correctly (-d)
ar01 8 TPASS: ar deleted nothing (-d with empty list)
ar01 9 TPASS: ar added new file before another (-i)
ar01 10 TPASS: ar moved file correctly (-mi)
ar01 11 TPASS: ar moved file correctly (-m)
ar01 12 TPASS: ar printed file content correctly (-p)
ar01 13 TPASS: ar appended file correctly (-q)
ar: `u' modifier ignored since `D' is the default (see `U')
ar01 14 TFAIL: ar haven't updated modified file0 (-u)
ar01 14 TPASS: ar haven't updated unmodified file1 (-u)
ar01 15 TPASS: ar verbose listing works (-tv)
ar01 16 TPASS: ar printed extracted filenames (-xv)
ar01 16 TPASS: ar extracted files correctly
ar01 17 TPASS: ar printed extracted filename (-xv)
ar01 17 TPASS: ar extracted file correctly

Summary:
passed 19
failed 1
skipped 0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=9 cstime=4
<<<test_end>>>

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-1004-kvm 4.15.0-1004.4
ProcVersionSignature: User Name 4.15.0-1004.4-kvm 4.15.15
Uname: Linux 4.15.0-1004-kvm x86_64
ApportVersion: 2.20.9-0ubuntu5
Architecture: amd64
Date: Thu Apr 19 08:24:19 2018
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
 SHELL=/bin/bash
SourcePackage: linux-kvm
UpgradeStatus: No upgrade log present (probably fresh install)

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.

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

Fair enough. Maybe this is a bug in libtool/automake/whatever it
is that runs 'ar'?

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...

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

I think the proper place for this is automake. This is triggered by any automake library build.

Still happens in Rawhide. Although I don't believe it causes any
actual problem.

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

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.

Complementary Automake patch:
ttp://<email address hidden>/msg07705.html

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" )

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

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://<email address hidden>/msg04238.html

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

Fixed in libtool, automake is not fixed yet upstream. The libtool
release 2.4.7 is expected to happen soon.

What's the status on the "expected to happen soon" libtool release?

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.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Po-Hsu Lin (cypressyew) wrote :

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. 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 '26'.

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 26 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.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1765331

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-kvm (Ubuntu):
status: New → Confirmed
Po-Hsu Lin (cypressyew) wrote :
Changed in binutils:
importance: Unknown → High
status: Unknown → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.