Created attachment 13183 [details]
tarball of possibly relevant configs, Makefiles

Added tarball of these files.  Let me know if any others would be helpful.

auge12> tar czf relevant.tgz intl/Makefile intl/config.* libctf/Makefile libctf/config.* libctf/libctf*.la libctf/.libs/libctf.a
auge13> v relevant.tgz 
-rw-r--r--+ 1 casner  staff  999896 Jan 30 23:19 relevant.tgz

git bisect finds this is the commit where the problem began:

commit 1038406a8f6609ad0a449746da70393b0835f699
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Jan 5 13:25:56 2021 +0000

    libctf: rip out BFD_DEPENDENCIES / BFD_LIBADD
    
    This complex morass inherited from libopcodes, which endeavours to
    implement the effect of specifying ../bfd/libbfd.la in _LIBADD without
    actually doing so, appears to be working around a libtool bug which as
    far as I can see is no longer present (i.e., the install directory no
    longer appears in -L arguments in libtool link-mode invocations, so
    there is no danger of picking up old libbfds or other dependent
    libraries).
    
    Replaced with a simple reference to libbfd.la in the appropriate place.
    Also adjusted things a little more so that libctf.la and libctf-nobfd.la
    are self-contained, even when linking statically.  This opens up the
    possibility of running libtool to link against libctf from inside the
    (upcoming) testsuite.
    
    libctf/ChangeLog
    2021-01-05  Nick Alcock  <nick.alcock@oracle.com>
    
            * configure.ac (BFD_LIBADD): Remove.
            (BFD_DEPENDENCIES): Likewise. Remove associated cases.
            (SHARED_LIBADD): Rename to...
            (CTF_LIBADD): ... this.  Stick in a suitable libiberty even when
            linking statically.
            * Makefile.am (libctf_nobfd_la_LIBADD): Adjust accordingly.
            libctf uses libintl.
            (libctf_la_LIBADD): Reference libbfd.la directly, not via
            BFD_LIBADD.
            (libctf_la_DEPENDENCIES): Remove.
            * Makefile.in: Regenerate.
            * configure: Likewise.

Replicated. Working on a fix.

Bug 27360 appears to be related, but I'm not sure if they can be called duplicates.

Fixed (some time back, but couldn't update the bug) in master in a series in which the most important commits are these:

(not sure if it is worthy of going back into 2.36. The commits it relies on are quite big and invasive.)

commit 95148614026da7353721411dd020d024667e3482
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Wed Feb 3 18:42:06 2021 +0000

    bfd, opcodes, libctf: support --with-included-gettext
    
    Right now, these libraries hardwire -L../intl -lintl on a few fixed
    platforms, which works fine on those platforms but on other platforms
    leads to shared libraries that lack libintl_* symbols when configured
    --with-included-gettext, and/or static libraries that contain libintl as
    *another* static library.  If we instead use the LIBINTL variable
    defined in ../intl/config.intl, this gives us the right thing on all
    three classes of platform (gettext in libc, gettext in system libintl,
    gettext in ../intl/libintl.a)..  This also means we can rip out some
    Darwin-specific machinery from configure.ac and also simplify the Cygwin
    side.
    
    This also means that the libctf testsuite (and other places that include
    libbfd, libopcodes or libctf) don't need to grow libintl dependencies
    just on account of those libraries (though they still need such
    dependencies if they themselves use gettext machinery).
    
    bfd/ChangeLog
    2021-02-03  Nick Alcock  <nick.alcock@oracle.com>
    
            * configure.ac (SHARED_LIBADD): Remove explicit -lintl population in
            favour of LIBINTL.
            * configure: Regenerated.
    
    libctf/ChangeLog
    2021-02-02  Nick Alcock  <nick.alcock@oracle.com>
    
            * configure.ac (CTF_LIBADD): Remove explicit -lintl population in
            favour of LIBINTL.
            * Makefile.am (libctf_nobfd_la_LIBADD): No longer explicitly
            include $(LIBINTL).
            (check-DEJAGNU): Pass down to tests as well.
            * configure: Regenerated.
            * Makefile.in: Likewise.
    
    opcodes/ChangeLog
    2021-02-04  Nick Alcock  <nick.alcock@oracle.com>
    
            * configure.ac (SHARED_LIBADD): Remove explicit -lintl population in
            favour of LIBINTL.
            * configure: Regenerated.




commit aee224d6434c08a1404a4357cf0a664a4c2f02eb
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Thu Feb 4 16:58:35 2021 +0000

    intl: turn LIBINTL into -L / -l form
    
    This variable currently refers directly, not to a .la file, but to an .a
    file.  This produces wrong results when building into a library on some
    platforms: so convert it to the general form "-L${top_builddir}../intl
    -lintl ..." ... so that both libtool and non-libtool builds will always
    do the right thing for both static and shared links.
    
    intl/ChangeLog
    2021-02-04  Nick Alcock  <nick.alcock@oracle.com>
    
            * configure.ac (LIBINTL): Transform into -L/-lintl form.
            * configure: Regenerate.

commit 53d4244ec0ac70438d75abf3326cb3392bb9c828
Author: Nick Alcock <nick.alcock@oracle.com>
Date:   Tue Feb 2 15:39:26 2021 +0000

    intl: always picify
    
    libintl is included in several shared libraries (at least
    libinproctrace.so and libctf.so): unconditionally picify with code
    borrowed from libiberty configure.  (It's not performance-critical, so
    don't bother making separate PIC and non-PIC libraries like libiberty
    does.)
    
    intl/ChangeLog
    2021-02-02  Nick Alcock  <nick.alcock@oracle.com>
    
            * aclocal.m4: include picflag.m4.
            * configure.ac (PICFLAG): Add and substitute.
            * Makefile.in (PICFLAG): New.
            (COMPILE): Use it.
            * configure: Regenerate.

Does any of the patches also fixed https://sourceware.org/bugzilla/show_bug.cgi?id=27360 ?

Quite possibly, or at least I don't see that failure with the reported replication mechanism on binutils master: I'll update that bug too.

Now I know the cause of that bug: no, these are unrelated (and a separate fix is needed for that bug).