Hello people!

What is the opinion of the GDB maintainers about the necessity of
libtoolizing GDB before accepting changes like the following:

In gdb/configure.ac:

  if test x${enable_static} = xno; then
    LIBSFRAME="-Wl,--rpath,../libsframe/.libs ../libsframe/libsframe.a"
    SFRAME_DEPS="../libsframe/.libs/libsframe.so"
  else
    LIBSFRAME="../libsframe/.libs/libsframe.a"
    SFRAME_DEPS="$LIBSFRAME"
  fi
  AC_SUBST([LIBSFRAME])
  AC_SUBST([SFRAME_DEPS])

In gdb/Makefile.in:

  LIBSFRAME = @LIBSFRAME@
  SFRAME_DEPS = @SFRAME_DEPS@

  [...]

  CLIBS += $(LIBSFRAME)
  CDEPS += $(SFRAME_DEPS)

Note that both the in-tree libs libctf and libbacktrace are currently
handled the same way.

I have to admit I find myself split here.

As a maintainer, I would share Mike's reservations (maybe not as
strongly, but I get it) expressed in the forwarded email below.

Corporate wise, however, we would really need to close the "add sframe
support to binutils" chapter before opening the "libtoolize GDB" chapter
or we can find ourselves in trouble.

But first things first: how do you people feel about libtoolizing the
rules in gdb/Makefile.in so GDB can handle the in-tree libtool libraries
in a more graceful way?

-------------------- Start of forwarded message --------------------
Date: Thu, 3 Nov 2022 22:27:34 +0700
From: Mike Frysinger <vapier@gentoo.org>
To: "Jose E. Marchesi" <jose.marchesi@oracle.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH, V3 10/15] gdb: sim: buildsystem changes to accommodate
 libsframe