gdb: link executables with libtool

This patch changes the GDB build system in order to use libtool to
link the several built executables.  This makes it possible to refer
to libtool libraries (.la files) in CLIBS.

As an application of the above,

  BFD              now refers to ../libbfd/libbfd.la
  OPCODES          now refers to ../opcodes/libopcodes.la
  LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
  LIBCTF           now refers to ../libctf/libctf.la

NOTE1: The addition of libtool adds a few new configure-time options
       to GDB.  Among these, --enable-shared and --disable-shared, which were
       previously ignored.  Now GDB shall honor these options when linking,
       picking up the right version of the referred libtool libraries
       automagically.

NOTE2: I have not tested the insight build.

NOTE3: For regenerating configure I used an environment with Autoconf
       2.69 and Automake 1.15.1.  This should match the previously
       used version as announced in the configure script.

NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
       libctf.so are used by gdb if binutils is installed with
       --enable-shared.

Testing performed:

- --enable-shared and --disable-shared (the default in binutils) work
  as expected: the linked executables link with the archive or shared
  libraries transparently.

- Makefile.in modified for EXEEXT = .exe.  It installs the binaries
  just fine.  The installed gdb.exe runs fine.

- Native build regtested in x86_64. No regressions found.

- Cross build for aarch64-linux-gnu built to exercise
  program_transform_name and friends.  The installed
  aarch64-linux-gnu-gdb runs fine.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
Approved-By: Simon Marchi <simon.marchi@efficios.com>

0 files changed, 0 insertions, 0 deletions