SETPGRP and autoconf

SETPGRP and autoconf

[Daniel Jacobowitz]

I should have objected :)  But it'd been so long since I last saw this issue
that I forgot about it.

AC_FUNC_SETPGRP has some regrettable problems.  Witness:

checking whether setpgrp takes no argument... configure: error: cannot check
  setpgrp if cross compiling

Thus breaking all host-x-host cross builds.


This is what I really hate about autoconf.  There's no good reason for
AC_FUNC_SETPGRP to be an executed test.  If you have a prototype for
setpgrp(void),  setpgrp(1,1) won't compile, and you don't need to execute
anything at all.

What can we do about this?  Besides my usual hack: I have a huge list of
autoconf cache variables in my build environment, preset.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: SETPGRP and autoconf

[Mark Kettenis]

   Date: Wed, 25 Jul 2001 16:24:20 -0700
   From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>

   I should have objected :)  But it'd been so long since I last saw this issue
   that I forgot about it.

   AC_FUNC_SETPGRP has some regrettable problems.  Witness:

   checking whether setpgrp takes no argument... configure: error: cannot check
     setpgrp if cross compiling

   Thus breaking all host-x-host cross builds.

Bugger!

   This is what I really hate about autoconf.  There's no good reason for
   AC_FUNC_SETPGRP to be an executed test.  If you have a prototype for
   setpgrp(void),  setpgrp(1,1) won't compile, and you don't need to execute
   anything at all.

Who says you've got a prototype?  Even though GDB requires an ISO C
compiler now, this doesn't mean the host's headers have to be ISO
C-compliant.

   What can we do about this?  Besides my usual hack: I have a huge list of
   autoconf cache variables in my build environment, preset.

Dunno.  I don't think there are too many people cross-compiling GDB.
If we want to fix this, we could use an alternative check for
AC_FUNC_SETPGRP when cross-compiling based on the setpgrp prototype.
I don't think it would hurts not defining SETPGRP_VOID if no
prototypes are available, since passing the extra arguments should be
harmless.

Mark

Re: SETPGRP and autoconf

[H . J . Lu]

On Thu, Jul 26, 2001 at 12:40:02PM +0200, Mark Kettenis wrote:
> 
> Dunno.  I don't think there are too many people cross-compiling GDB.

FWIW, I do and anyone who uses my cross build envronment for
Linux/mips.


H.J.

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Thu, Jul 26, 2001 at 12:40:02PM +0200, Mark Kettenis wrote:
>    Date: Wed, 25 Jul 2001 16:24:20 -0700
>    From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
> 
>    I should have objected :)  But it'd been so long since I last saw this issue
>    that I forgot about it.
> 
>    AC_FUNC_SETPGRP has some regrettable problems.  Witness:
> 
>    checking whether setpgrp takes no argument... configure: error: cannot check
>      setpgrp if cross compiling
> 
>    Thus breaking all host-x-host cross builds.
> 
> Bugger!

Got my reaction in one.

>    This is what I really hate about autoconf.  There's no good reason for
>    AC_FUNC_SETPGRP to be an executed test.  If you have a prototype for
>    setpgrp(void),  setpgrp(1,1) won't compile, and you don't need to execute
>    anything at all.
> 
> Who says you've got a prototype?  Even though GDB requires an ISO C
> compiler now, this doesn't mean the host's headers have to be ISO
> C-compliant.

Ugh.

>    What can we do about this?  Besides my usual hack: I have a huge list of
>    autoconf cache variables in my build environment, preset.
> 
> Dunno.  I don't think there are too many people cross-compiling GDB.
> If we want to fix this, we could use an alternative check for
> AC_FUNC_SETPGRP when cross-compiling based on the setpgrp prototype.
> I don't think it would hurts not defining SETPGRP_VOID if no
> prototypes are available, since passing the extra arguments should be
> harmless.

Even if we don't require ISO C headers when building, requiring them
while cross-compiling doesn't seem too unreasonable.  I'll try to work
up a patch for this.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: SETPGRP and autoconf

[Andrew Cagney]

>> What can we do about this?  Besides my usual hack: I have a huge list of
>> autoconf cache variables in my build environment, preset.
>> 
>> Dunno.  I don't think there are too many people cross-compiling GDB.
>> If we want to fix this, we could use an alternative check for
>> AC_FUNC_SETPGRP when cross-compiling based on the setpgrp prototype.
>> I don't think it would hurts not defining SETPGRP_VOID if no
>> prototypes are available, since passing the extra arguments should be
>> harmless.
> 
> 
> Even if we don't require ISO C headers when building, requiring them
> while cross-compiling doesn't seem too unreasonable.  I'll try to work
> up a patch for this.


That is kind of what I was thinking.  I can see the following cases:

native - already covered, test works
cross debugger - N/A procfs et.al. do not need the results of the test
canadian cross - try headers; test is against the build systems 
build-X-host cross compiler and not the build systems build-X-build 
native compiler.

I can't see anyone trying to canadian-cross GDB to anything but a fairly 
modern operating system, consequently, the headers test should work.

Could I suggest only doing the test after the existing test fails to 
turn up anything useful.

	Andrew

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Thu, Jul 26, 2001 at 01:16:13PM -0400, Andrew Cagney wrote:
> I can't see anyone trying to canadian-cross GDB to anything but a fairly 
> modern operating system, consequently, the headers test should work.

Sounds right to me.

> Could I suggest only doing the test after the existing test fails to 
> turn up anything useful.

Nope.  Configure will exit with an error if you invoke AC_FUNC_SETPGRP
while cross-compiling.  We have to avoid it entirely.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer