+++ This bug was initially created as a clone of Bug #1943020 +++

nas-1.9.4-24.fc35 FTBFS is triggered by upgrading binutils from 2.35.1-34.fc34 to 2.36.1-7.fc35.

[...]

The failing command is:

$ ar clq libdia.a dispatch.o dixutils.o events.o globals.o main.o resource.o swapreq.o        tables.o swaprep.o        audispatch.o auswap.o autables.o auevents.o auutil.o auconfig.o        auprocess.o  nasconf.o lex.o gram.o
ar: libdeps specified more than once

The reason is that GNU ar repurpossed an "l" option. From binutils NEWS:

* The ar tool's previously unused l modifier is now used for specifying
  dependencies of a static library. The arguments of this option
  (or --record-libdeps long form option) will be stored verbatim in the
  __.LIBDEP member of the archive, which the linker may read at link time.

--- Additional comment from Petr Pisar on 2021-03-25 17:01:27 GMT ---

The server/dia/Makefile code:

               AR = ar clq
[...]
libdia.a: $(OBJS) $(EXTRALIBRARYDEPS)
    $(RM) $@
    $(AR) $@ $(OBJS)
    $(RANLIB) $@
    $(_NULLCMD_)

is generated by xmkmf command (via imake) from server/dia/Imakefile:

NormalLibraryTarget(dia,$(OBJS))

and /usr/share/X11/config/Imake.tmpl:

#ifndef SystemV4
#define SystemV4        NO  /* SVR4 */
#endif
[...]
#ifndef HasLargeTmp
#define HasLargeTmp     NO  /* be paranoid */
#endif
[...]
#ifndef ArCmd
#if HasLargeTmp || SystemV4
#define ArCmd ArCmdBase cq
#else
#define ArCmd ArCmdBase clq
#endif
#endif

which belongs to imake-1.0.8-5.fc34.x86_64. This is a clash between imake and binutils-2.36.
-----

Who does want this ball?

imake maintainers, do you want to adapt imake templates to the new binutils (i.e. not to use "l" option), or should binutils revert the change (i.e. stop reusing "l" option)?