Re: RFA: libunwind basic support

[Andrew Cagney <ac131313@redhat.com>]

> It is possible for the user to enable libunwind but the header files are not there.  I am guessing you would prefer compilation to fail in this case so I have removed the check.

Yes.  If the user forces the use of libunwind, but it isn't there, the 
user should loose.

> I have added comments for the search unwind table call.

Thanks.


> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/configure.in,v
> retrieving revision 1.132
> diff -u -r1.132 configure.in
> --- configure.in    3 Sep 2003 15:02:48 -0000    1.132
> +++ configure.in    22 Oct 2003 23:36:21 -0000
> @@ -192,6 +192,33 @@
>      enable_gdbtk=no ;;
>  esac
> 
> 
> Based on 12.1 Working With External Software
> http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_12.html#SEC130
> 
> I suspect that this should be --with (external libunwind software), and not --enable (gdb feature), although, to be honest, its hard to tell which it should be.
> 
> Anyone?
> 
> 
> From discussions with Jeff Law when I was doing configuration for newlib, he told me that --enable should be used for on/off decisions in preference to --with.  I don't personally care so I have switched to --with.

Thanks.

You're right that the lines are blured.  enable/disable is for 
controlling the presence of an internal feature while with/without is 
for controlling a dependency/use of an external program, or library. 
Unfortunatly, here the decision to build GDB with/without the external 
libunwind library has the consequence of determining if GDB should 
enable/disable the internal (but not user visible) libunwind unwinder. 
I think, based on the presence of X as an example in the manual, the 
with/without takes precidence.

So, yes all ok.
Andrew



> Index: libunwind-frame.c