Fabre

#981072 binutils: 'ar clq' does not longer work in latest binutils #981072

Package:: binutils

Source:: binutils

Description:: GNU assembler, linker and binary utilities

Submitter:: Robert Luberda

Date:: 2021-11-07 00:51:05 UTC

Severity:: important

Tags:

#981072#5

Date:: 2021-01-25 23:33:12 UTC

From:

To:

Hi,

I've recently noticed that my afterstep package failed to build on
Ubuntu, with the following error (see [1] for full log):

  ar clq libAfterBase.a ashash.o aslist.o asvector.o audit.o fs.o layout.o mystring.o os.o output.o parse.o regexp.o safemalloc.o selfdiag.o sleep.o socket.o timer.o trace.o xml.o xprop.o xwrap.o
  ar: libdeps specified more than once

After spending some time on finding the cause of it (and to be honest
the "libdeps specified more than once" error is pretty confusing),
I've discovered that Ubuntu uses the latest binutils. I installed
binutils from experimental, and was able to reproduce afterstep's build
failure. It turned out that the latest 'ar' started re-using  the
previously ignored 'l' option for different purposes. According
to ar(1), the 'l' now option is:

  l   Specify dependencies of this library.  The dependencies must immediately follow this option
    character, must use the same syntax as the linker command line, and must be specified within a
    single argument.  I.e., if multiple items are needed, they must be quoted to form a single command
    line argument.  For example L "-L/usr/local/lib -lmydep1 -lmydep2"
                               ^^^
                                |
                                +--- BTW. there is a typo here

Quick search on sources of packages showed that there are about 30
other packages that also call "ar clq", see [2] - that's why I'm writing
this bug report to let you know about this.


BTW. I've just tried to fix the issue in afterstep by replacing calls to "ar clq"
with "ar cq", but I got some strange 'debug-file-with-no-debug-symbols'
or 'shared-library-lacks-prerequisites' lintian warnings on the resulted
package, but I don't know the reason of these yet.


[1] https://launchpadlibrarian.net/512884696/buildlog_ubuntu-hirsute-amd64.afterstep_2.2.12-14_BUILDING.txt.gz
[2] https://codesearch.debian.net/search?q=ar+clq&perpkg=1

Regards,
robert

#981072#10

Date:: 2021-02-19 17:29:48 UTC

From:

To:

Control: tags -1 + wontfix

I brought that up with upstream, but it wasn't ack'd as too important.

If you've done this analysis already, please could you file bug reports for the
affected packages, maybe with a usertag?

thanks, Matthias

#981072#17

Date:: 2021-09-23 15:10:38 UTC

From:

To:

Hi all,

I realise I am very much resurrecting an old bug with +wontfix added, but this issue turns out to be the root cause of a rather frustrating bug I have been tracking down in libafterimage, found while compiling gamos-geant4, an open-source radiation / medical physics simulation monte carlo package that is mostly developed in CERN.

Can I be so rude as to ask those very much more knowledgable than I for an unambiguous statement of what "ar clq" historically did and if replacing it with "ar cq" is acceptable?

Previous man-pages state "this modifier is accepted but not used" [1; v. 2.10] and I note that FreeBSD's ar states that it is accepted and ignored for compatibility with GNU ar (!) [2] whilst MacOS's man page states that -L is "Used the extended format to allow long archive member names.  This is the default." [3].

Alternatively, might I be so heretical to suggest that -L (in the new usage) becomes case sensitive?

I suspect others like me in the future may find this bug (as I did!) with the "ar: libdeps specified more than once" error? There are at least 147 packages affected downstream in Debian [4] and presumably a lot more "in the wild".

Thanks again to whoever is reading this for their effort and work for the open source community.

All the best,

#981072#22

Date:: 2021-10-23 21:56:21 UTC

From:

To:

# imake
reassign 997628 xutils-dev
found 997628 1:7.7+5
retitle 997628 imake: uses “ar clq” by default, which recent binutils broke in an incompatible way
# causes an FTBFS, cannot be workarounded in mgp
affects 997628 src:mgp
# root bug is in binutils
block 997628 by 981072
# at least, if not more
severity 981072 important
thanks

Lucas Nussbaum dixit:

WTF, what does that even mean? *researches*

This is #981072, an incompatible(!) change in binutils, which I’d
consider of a rather serious severity but is tagged wontfix.

Basically, ar(1) in bullseye documents the ‘l’ modifier as…

l This modifier is accepted but not used.

… and ar(1) in sid reuses it in an incompatible way, with no
deprecation/warning period, instead of doing the sensible thing
and using a different, not currently used, flag.

Robert Luberda dixit:

No, it’s far more than your search shows.

I’m tempted to reassign to binutils, but this would probably
be ignored. But I’ve got to reassign it anyway since the clq
is injected by imake(1). Which version(s) of binutils contain
this breaking change? (That is, does imake need a change in a
stable release?)

Doko, I urge you to request the upstream developers to change
this and use a currently-unused flag for their new feature. I
know getting them to do that, therefore admitting a mistake,
is going to be hard, but considering this is embedded in *so*
many build systems, they’re not going to make any friends by
breaking this.

bye,
//mirabilos

#981072#29

Date:: 2021-10-23 21:56:21 UTC

From:

To: