Re: Two observations using GDB 13 snapshot

Hannes Domani via Gdb-patches
2023-01-07T16:16:40Z

Am Samstag, 7. Januar 2023, 17:10:33 MEZ hat Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:

> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: gdb-patches@sourceware.org
> > Date: Sat, 07 Jan 2023 16:40:15 +0100
> >
> > On Jan 07 2023, Eli Zaretskii wrote:
> >
> > >> From: Andreas Schwab <schwab@linux-m68k.org>
> > >> Cc: gdb-patches@sourceware.org
> > >> Date: Sat, 07 Jan 2023 15:40:01 +0100
> > >>
> > >> On Jan 07 2023, Eli Zaretskii wrote:
> > >>
> > >> > So the problem is that we are now using libtool, and that causes the
> > >> > GDB executable to be in a directory different from where gdb-gdb.gdb
> > >> > is kept.
> > >>
> > >> That does not happen for me.  Did you configure with --enable-shared?
> > >
> > > No.  Why would I need to?
> >
> > Without it, libtool should have no reason to put gdb in .libs.
>
> I see.  Well, here it is.
>
>
> > > GDB is not a library, and doesn't build libraries that need to be
> > > installed, AFAIK.
> >
> > So why does it create the gdb binary in .libs?  It is empty for me.
>
>
> I don't know.  Any libtool experts around here?

Isn't --enable-shared the default?
Anyways, I also had this 'problem', and once I added --disable-shared,
libtool didn't put the real gdb.exe into .libs anymore.

I think this behavior is a bit different for Windows targets, because of this
part in libtool:

*cygwin* | *mingw* )
if test "$build_libtool_libs" != yes; then
wrappers_required=no
fi
;;

Hannes