[patch/rfc] Build inf-ptrace.o when ptrace available
Mon Oct 11 17:24:00 GMT 2004
> I still do not believe that configure testing should be used for this
> purpose. If we end up moving the knowledge of natfiles into configure,
> then we can set inf-ptrace to be included for all native GNU/Linux
> targets easily enough.
So you're not objecting to changes making configure (actually
configure.host and configure.tgt) directly handle what was previously in
the .mh file ...
> Or there are other ways to do it, as below.
> One of the reasons why I hold this position is that it lets us give a
> more useful error message if someone's system is broken and can not
> compile inf-ptrace.c for some reason that the configure script
> detected. They'll get either a link failure or a GDB which can't debug
> anything, instead of an error related to the compile problem. My
> experience with automating distribution builds tells me that someone
> will come up with a way to break their system in this fashion.
.. but rather just objecting to having inf-ptrace selected dependant on
autoconf magic? I could equally hardwire it vis:
case $host in
*-linux* | *-bsd* ) objs += inf-ptrace
Can you show us the money here - on what systems did you encounter
problems and what problems were they?
The most recent problem I can think of was with the TUI, and that was a
straight configure.in bug.
>>>>>> >>>Why is it orthogonal? If we assume that configure determines when /proc
>>>>>> >>>and ptrace() and provides both to the user it certainly isn't. Idea's
>>>>>> >>>such as Mark's and mine would make it easier.
>>>> >Why is it related? How would this make it easier? It's not hard to
>>>> >add a new backend file to all the Linux targets; it's really not much
>>>> >different in a lot of little files than in one big one. I've done this
>>>> >plenty of times.
>>> If we used configure.tgt and:
>>> switch "$target"
>>> *-*-linux* ) "objs=objs symfile-mem.c"
>>> then all GNU/Linux systems will always and consistently include
>>> symtab-mem.c. We don't, they don't ...
> This is no harder than having a common linux.mh, as GCC has done for
> years (gcc/config/t-linux). It's not a technical differece between
> configure-frobbing and makefile-fragmenting.
So initially we can migrate things to configure.host, and then, if
things prove to unwieldly, look at refactoring it. But not before.
More information about the Gdb-patches