[PATCH, V3 10/15] gdb: sim: buildsystem changes to accommodate libsframe

Jose E. Marchesi jose.marchesi@oracle.com
Wed Nov 2 19:11:27 GMT 2022


Hi Mike, Indu.

>> > On 30 Oct 2022 00:44, Indu Bhagat via Binutils wrote:
>> >> [Changes in V3]
>> >>    - Additional diff in sim/ppc/Makefile.in to accommodate libsframe.
>> >>      This is needed to ensure --enable-targets=all continues to build.
>> >>    - Addressed review comments by Mike Frysinger.
>> > 
>> > this doesn't seem to actually address my comments.  you're still poking
>> > the internals of libtool by accessing files under .libs/.
>> 
>> gdb does not use libtool yet.
>
> you have access to the source.  you can change these things.
>
> also, gdb & sim are sep projects.

I see gdb/configure.ac uses the same strategy in order to locate the
in-tree libbacktrace.a and libctf:

  if test "${enable_libbacktrace}" = "yes"; then
    LIBBACKTRACE_INC="-I$srcdir/../libbacktrace/ -I../libbacktrace/"
    LIBBACKTRACE_LIB=../libbacktrace/.libs/libbacktrace.a
    AC_DEFINE(HAVE_LIBBACKTRACE, 1, [Define if libbacktrace is being used.])
  else
    LIBBACKTRACE_INC=
    LIBBACKTRACE_LIB=
  fi

  [...]

  if test x${enable_static} = xno; then
    LIBCTF="-Wl,--rpath,../libctf/.libs ../libctf/.libs/libctf.so"
    CTF_DEPS="../libctf/.libs/libctf.so"
  else
    LIBCTF="../libctf/.libs/libctf.a"
    CTF_DEPS="$LIBCTF"
  fi

With corresponding substitutions in gdb/Makefile.in.

I agree it would be better to have GDB libtoolized so it could refer to
the .la libraries directly thus avoiding internals, but could that be
done in a separated patch set, also covering the other cases?

In the meanwhile, Indu could change her patch in order to look for
libsframe.so in gdb/configure.ac instead of gdb/Makefile.in, as it is
done for the other libs.  Then we libtoolize.

WDYT?

>> I see that opcodes/Makefile.am bfd/Makefile.am each create a 
>> opcodes/libopcodes.a and bfd/libbfd.a by copying over from the 
>> respective artifact from the .libs/ at build-time.
>
> this forces static linking of libraries that are possibly available as
> shared ones which isn't really what we want


More information about the Binutils mailing list