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.
Automake/Libtool upstream discussion: http://lists.gnu.org/archive/html/bug-automake/2015-03/msg00004.html http://lists.gnu.org/archive/html/bug-libtool/2015-02/msg00014.html
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://www.mail-archive.com/automake-patches/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://www.mail-archive.com/bug-automake@gnu.org/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
Any update?
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'.
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 package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
According to the low priority of this request and as it did not bother any user for years, I am closing this tracker. If you think this issue should be handled and investigated, feel free to reopen it.