This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, RFA] opcodes: Use autoconf to check for `bfd_mips_elf_get_abiflags' in BFD


> Fix a regression introduced with commit 5e7fc731f80e ("MIPS/opcodes: 
> Also set disassembler's ASE flags from ELF structures"), further updated 
> with commit 4df995c77118 ("MIPS/opcodes: Also set disassembler's ASE 
> flags from ELF structures"), and use autoconf to check for the presence 
> of `bfd_mips_elf_get_abiflags' in BFD.
> 
> 	opcodes/
> 	* mips-dis.c (set_default_mips_dis_options): Use 
> 	HAVE_BFD_MIPS_ELF_GET_ABIFLAGS rather than BFD64 to guard the
> 	call to `bfd_mips_elf_get_abiflags'.
> 	* configure.ac: Check for `bfd_mips_elf_get_abiflags' in BFD.
> 	* Makefile.am (CONFIG_STATUS_DEPENDENCIES): Add `libbfd.la'.
> 	* aclocal.m4: Regenerate.
> 	* configure: Regenerate.
> 	* config.in: Regenerate.
> 	* Makefile.in: Regenerate.

Unfortunately, this change breaks the following scenario, used
by the src-release.sh script (used to produce our nightly source
packages, as well as our official releases). It also looks like
the change is in the binutils 2.28 branch as well, so if Tristan
uses that script to produce the release, it's not going to work.

The reason for the failure is the following change:

   -# development.sh is used to determine -Werror default.
   -CONFIG_STATUS_DEPENDENCIES = $(BFDDIR)/development.sh
   +# development.sh is used to determine -Werror default, libbfd.la is needed
   +# for function availability checks.
   +CONFIG_STATUS_DEPENDENCIES = $(BFDDIR)/development.sh ../bfd/libbfd.la

It causes the following scenario to fail:

   $ ./configure
   $ make configure-host
   $ make distclean

I'm pretty sure "./configure; make; make distclean" fails the same way,
but I haven't bothered trying.

The reason it fails is that "make distclean" depends on distclean-host
which then depends on:

    distclean-host: maybe-distclean-bfd
    distclean-host: maybe-distclean-opcodes

So, "make distclean" first does a "distclean" in bfd, followed by
a "distclean" in opcodes. The bfd distclean results in libbfd.la
being deleted. And because opcodes' Makefile now depends on it,
we get this error:

| make: Entering directory '/[...]/obj/opcodes'
| make: *** No rule to make target '../bfd/libbfd.la', needed by 'config.status'.  Stop.
| make: Leaving directory '/[...]/obj/opcodes'

I haven't been able to figure out how distclean depends on
CONFIG_STATUS_DEPENDENCIES, but I'm thiking it's probably one of
the implicit dependencies. But looking at the automake documentation
about CONFIG_STATUS_DEPENDENCIES, it looks like this is meant to be
listing the depedencies to re-generate the Makefile. It don't think
libbfd.a/la is in this category, is it?

I don't have a solution. Perhaps one way to approach the problem
might be to distclean in the reverse order to configure/build?
If opcodes depends on bfd and we distclean bfd, then there might
indeed be some dependencies missing.

We need a solution fairly quickly...

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]