imake: uses an argument to ar(1) which recent binutils changed in an incompatible way, causing packages using imake to FTBFS (was Re: Bug#997628: mgp: FTBFS: ar: libdeps specified more than once)
# 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:
>> ar clq libmgpimage.a imagetypes.o send.o zio.o zoom.o new.o compress.o reduce.o value.o misc.o rotate.o rle.o rlelib.o smooth.o halftone.o clip.o dither.o path.o bright.o window.o imlib_loader.o
>> ar: libdeps specified more than once
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:
>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
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
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Reply to: