Re: SETPGRP and autoconf

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Thu, Jul 26, 2001 at 01:16:13PM -0400, Andrew Cagney wrote:
> 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.

How does this look?

Only gotcha - I regenerated configure (not included) with autoconf
2.13, and the existing one claims to be autoconf 2.13, but they have
some noticeable differences - -site-file for instance.  Is there a
particular autoconf I should be using?

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

2001-07-27  Daniel Jacobowitz  <drow@mvista.com>

	* configure.in: Only invoke AC_FUNC_SETPGRP if not cross-compiling.
	Check for SETPGRP_VOID separately if cross-compiling and ISO C
	headers are available.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.68
diff -u -r1.68 configure.in
--- configure.in	2001/07/27 16:35:27	1.68
+++ configure.in	2001/07/27 17:14:08
@@ -134,7 +134,24 @@
 AC_CHECK_FUNCS(setpgid setpgrp sbrk sigaction isascii bzero bcopy btowc poll sigprocmask)
 AC_FUNC_VFORK
 AC_FUNC_ALLOCA
-AC_FUNC_SETPGRP
+dnl AC_FUNC_SETPGRP does not work if cross compiling
+dnl Instead, assume we will have a prototype for setpgrp if cross compiling.
+if test "$cross_compiling" = no; then
+  AC_FUNC_SETPGRP
+else
+  AC_CACHE_CHECK([whether setpgrp takes no argument], ac_cv_func_setpgrp_void,
+    [AC_TRY_COMPILE([
+#include <unistd.h>
+], [
+  if (setpgrp(1,1) == -1)
+    exit (0);
+  else
+    exit (1);
+], ac_cv_func_setpgrp_void=no, ac_cv_func_setpgrp_void=yes)])
+if test $ac_cv_func_setpgrp_void = yes; then
+  AC_DEFINE(SETPGRP_VOID, 1)
+fi
+fi
 
 # Check if sigsetjmp is available.  Using AC_CHECK_FUNCS won't do
 # since sigsetjmp might only be defined as a macro.

Re: SETPGRP and autoconf

[Andrew Cagney]

> 
> How does this look?
> 
> Only gotcha - I regenerated configure (not included) with autoconf
> 2.13, and the existing one claims to be autoconf 2.13, but they have
> some noticeable differences - -site-file for instance.  Is there a
> particular autoconf I should be using?


People alternate between 2.13 and 
ftp://sources.redhat.com/pub/binutils/???/autoconf*.tar.gz .

Strictly speaking I don't know of a reson for GDB to use the latter (BFD 
needs it due to bugs).

	Andrew

Re: SETPGRP and autoconf

[Andrew Cagney]

> +dnl AC_FUNC_SETPGRP does not work if cross compiling
> +dnl Instead, assume we will have a prototype for setpgrp if cross compiling.
> +if test "$cross_compiling" = no; then


Suggest:
AC_FUNC_SETPGRP does not work when cross compiling GDB.

BTW, I suspect the outcome of the test on modern OS's doesn't matter - 
the better defined setpgid() is used first anyway.

As for approval, anyone can update configure.in, just be careful to get 
feedback from any potentially interested parties.

	Andreww

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Fri, Jul 27, 2001 at 04:31:51PM -0400, Andrew Cagney wrote:
> > +dnl AC_FUNC_SETPGRP does not work if cross compiling
> > +dnl Instead, assume we will have a prototype for setpgrp if cross compiling.
> > +if test "$cross_compiling" = no; then
> 
> 
> Suggest:
> AC_FUNC_SETPGRP does not work when cross compiling GDB.
> 
> BTW, I suspect the outcome of the test on modern OS's doesn't matter - 
> the better defined setpgid() is used first anyway.

Hey, I missed this when going over the logic.  We don't even care about
SETPGRP_VOID if HAVE_SETPGID.  I'm still going to check it this way,
though, just in case we have a system modern enough to have the headers
and odd enough not to define setpgid.

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

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Fri, Jul 27, 2001 at 04:31:51PM -0400, Andrew Cagney wrote:
> > +dnl AC_FUNC_SETPGRP does not work if cross compiling
> > +dnl Instead, assume we will have a prototype for setpgrp if cross compiling.
> > +if test "$cross_compiling" = no; then
> 
> 
> Suggest:
> AC_FUNC_SETPGRP does not work when cross compiling GDB.

I left it as:
dnl AC_FUNC_SETPGRP does not work when cross compiling

It's in no way related to what we're cross compiling; it just checks if
$cross_compiling and errors.

> BTW, I suspect the outcome of the test on modern OS's doesn't matter - 
> the better defined setpgid() is used first anyway.
> 
> As for approval, anyone can update configure.in, just be careful to get 
> feedback from any potentially interested parties.

Since no one objected, I've committed this to the trunk.  I don't know
what rules we're using for the branch; can I just move it there too?

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

Re: SETPGRP and autoconf

[Andrew Cagney]

> Since no one objected, I've committed this to the trunk.  I don't know
> what rules we're using for the branch; can I just move it there too?


Does it fix a real bug?

	Andrew

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Mon, Jul 30, 2001 at 06:48:23PM -0400, Andrew Cagney wrote:
> 
> > Since no one objected, I've committed this to the trunk.  I don't know
> > what rules we're using for the branch; can I just move it there too?
> 
> 
> Does it fix a real bug?

Yes; without it we can not build host-x-host native debuggers (i.e.
build = i386-linux, host=mipsel-linux).

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

Re: SETPGRP and autoconf

[Andrew Cagney]

> On Mon, Jul 30, 2001 at 06:48:23PM -0400, Andrew Cagney wrote:
> 
>> 
> 
>> > Since no one objected, I've committed this to the trunk.  I don't know
>> > what rules we're using for the branch; can I just move it there too?
> 
>> 
>> 
>> Does it fix a real bug?
> 
> 
> Yes; without it we can not build host-x-host native debuggers (i.e.
> build = i386-linux, host=mipsel-linux).


Didn't previous e-mail conclude that for such a case setpgid() would be 
used so there wasn't a problem?

	Andrew

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Mon, Jul 30, 2001 at 06:58:24PM -0400, Andrew Cagney wrote:
> > On Mon, Jul 30, 2001 at 06:48:23PM -0400, Andrew Cagney wrote:
> > 
> >> 
> > 
> >> > Since no one objected, I've committed this to the trunk.  I don't know
> >> > what rules we're using for the branch; can I just move it there too?
> > 
> >> 
> >> 
> >> Does it fix a real bug?
> > 
> > 
> > Yes; without it we can not build host-x-host native debuggers (i.e.
> > build = i386-linux, host=mipsel-linux).
> 
> 
> Didn't previous e-mail conclude that for such a case setpgid() would be 
> used so there wasn't a problem?

The results of the test are not important, but configure will fail to
run at present.

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

Re: SETPGRP and autoconf

[Andrew Cagney]

> Didn't previous e-mail conclude that for such a case setpgid() would be 
>> used so there wasn't a problem?
> 
> 
> The results of the test are not important, but configure will fail to
> run at present.


Ah!  In that case ... (yes, why not).

	Andrew

Re: SETPGRP and autoconf

[Daniel Jacobowitz]

On Tue, Jul 31, 2001 at 11:51:15AM -0400, Andrew Cagney wrote:
> > Didn't previous e-mail conclude that for such a case setpgid() would be 
> >> used so there wasn't a problem?
> > 
> > 
> > The results of the test are not important, but configure will fail to
> > run at present.
> 
> 
> Ah!  In that case ... (yes, why not).

OK, moved to the branch too.

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