Re: [patch 2/2] Fix linking on non-x86* after libgdb.a removal

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Jan Kratochvil wrote:

> this is the second part for solving corelow after the s390x regression:
> 	[patch 2/2] Do not build libgdb.a by default
> 	http://sourceware.org/ml/gdb-patches/2011-12/msg00716.html
> ->
> 	corelow.o:(.bss+0x0): multiple definition of `core_gdbarch'
> 	corelow.o:(.bss+0x0): first defined here
> 	corelow.o: In function `deprecated_add_core_fns':
> 	corelow.c:(.text+0x0): multiple definition of `deprecated_add_core_fns'
> 	corelow.o:corelow.c:(.text+0x0): first defined here
> 
> 
> For targets using new set_gdbarch_regset_from_core_section it would not be
> a problem, just put corelow.o into the right entry of gdb/configure.tgt.

Huh, at least for s390 this would certainly be the correct solution; the
target actually is fully switched to modern gdbarch core handling ...

This needs to be done anyway to properly handle cross-debugging targeting
s390 core files.  Unless you already have done so, I can prepare a patch.

> But for legacy targets still using deprecated_add_core_fns (like
> sparc-solaris2.6 etc.) the addition to gdb/configure.tgt would enable
> corelow.o even for cross-targeted GDBs where there is unfortunately still no
> core files support.
> 
> Created the original configuration, just avoiding a duplicate corelow.o entry.
> A better idea is welcome.

Maybe a better way would be to just unconditionally add corelow.o to
COMMON_OBS and be done with it?  What would be the harm in having the
core target always present, even in configurations where no core file
formats will be recognized?

Or, if we want to keep the existing behaviour exactly, we could just
filter out all objects from TARGET_OBS that are already present in
NATDEPFILES (or vice versa).  This would at least avoid the ad-hoc
handling of one specific file ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com