configure --disable-threads

configure --disable-threads

[Steven Parkes]

It looks to me like --disable-threads has itself been disabled.  In
configure, it looks like $enable_threads is supposed to take on one of
three states but if you use --disable-threads or --enable-threads=no,
later code changes the value back to '' which causes it to default
which, in the case of hpux, brings in dce threads.

The patch below isn't clean, but it shows where the issue occurs.

*** configure.orig	Sat Oct 17 15:37:14 1998
--- configure	Sat Oct 17 15:53:00 1998
***************
*** 825,831 ****
  if test "${enable_threads+set}" = set; then
    enableval="$enable_threads"
    if test x$enable_threads = xno; then
! 	enable_threads=''
  fi
  else
    enable_threads=''
--- 825,831 ----
  if test "${enable_threads+set}" = set; then
    enableval="$enable_threads"
    if test x$enable_threads = xno; then
! 	enable_threads='no'
  fi
  else
    enable_threads=''

Re: configure --disable-threads

[Jeffrey A Law]

  In message < 199810271529.HAA03941@monterey.sierravista.com >you write:
  > It looks to me like --disable-threads has itself been disabled.  In
  > configure, it looks like $enable_threads is supposed to take on one of
  > three states but if you use --disable-threads or --enable-threads=no,
  > later code changes the value back to '' which causes it to default
  > which, in the case of hpux, brings in dce threads.
  > 
  > The patch below isn't clean, but it shows where the issue occurs.
  > 
  > *** configure.orig	Sat Oct 17 15:37:14 1998
  > --- configure	Sat Oct 17 15:53:00 1998
  > ***************
  > *** 825,831 ****
  >   if test "${enable_threads+set}" = set; then
  >     enableval="$enable_threads"
  >     if test x$enable_threads = xno; then
  > ! 	enable_threads=''
  >   fi
  >   else
  >     enable_threads=''
  > --- 825,831 ----
  >   if test "${enable_threads+set}" = set; then
  >     enableval="$enable_threads"
  >     if test x$enable_threads = xno; then
  > ! 	enable_threads='no'
  >   fi
  >   else
  >     enable_threads=''
I don't see how that can be happening.  Look at the case statement immediately
below the code in question.


enable_threads_flag=$enable_threads
# Check if a valid thread package
case x${enable_threads_flag} in
        x | xno)
                # No threads
                target_thread_file='single'
                ;;
        xyes)
                # default
                target_thread_file=''
                ;;
        xdecosf1 | xirix | xmach | xos2 | xposix | xpthreads | xsingle | \
        xsolaris | xwin32 | xdce | xvxworks)
                target_thread_file=$enable_threads_flag
                ;;
        *)
                echo "$enable_threads is an unknown thread package" 1>&2
                exit 1
                ;;
esac


It seems to me that without your patch x${enable_threads_flag} will expand
to "x", which should match the No threads clause.  If that's not working
correctly, you need to explain why.

Also, do not send patches to configure, it is a generated file from 
configure.in and other files.

jeff

Re: configure --disable-threads

[Steven Parkes]

    I don't see how that can be happening.  Look at the case statement
    immediately below the code in question.

	enable_threads_flag=$enable_threads
	# Check if a valid thread package
	case x${enable_threads_flag} in
		x | xno)
			# No threads
			target_thread_file='single'
			;;
		xyes)
			# default
			target_thread_file=''
			;;
		xdecosf1 | xirix | xmach | xos2 | xposix | xpthreads | xsingle | \
		xsolaris | xwin32 | xdce | xvxworks)
			target_thread_file=$enable_threads_flag
			;;
		*)
			echo "$enable_threads is an unknown thread package" 1>&2
			exit 1
			;;
	esac


	It seems to me that without your patch x${enable_threads_flag} will expand
	to "x", which should match the No threads clause.  If that's not working
	correctly, you need to explain why.

It does pass through those lines leaving target_thread_file as 'single'.
However, down in the configuration-specific area, under hppa1.1-*-hpux10*,
$enable_threads gets looked at again:

                if test x$enable_threads = x; then
                    enable_threads=$have_pthread_h
                fi
                if test x$enable_threads = xyes; then
                        thread_file='dce'
                        tmake_file="${tmake_file} pa/t-dce-thr"
                fi

The hppa code wants to let the thread package default, depending on the
environment.  The configure.in code
    if test x$enable_threads = xno; then
	    enable_threads=''
    fi,
throws away the `no' too early.  The way it's written, --enable-threads=no
means the same thing as --enable-threads, which I don't think is intended
semantics.

    Also, do not send patches to configure, it is a generated file from 
    configure.in and other files.

It wasn't meant to be an applied patch, since the patch itself is rather
silly.  Here it is against comfigure.in, but I'm sure that someone who
understands autoconf better than I can create a more straightfoward version.

*** configure.in.orig   Mon Nov  2 14:47:28 1998
--- configure.in        Mon Nov  2 15:00:01 1998
***************
*** 235,241 ****
  [  --enable-threads        enable thread usage for target GCC.
    --enable-threads=LIB    use LIB thread package for target GCC.],
  if test x$enable_threads = xno; then
!       enable_threads=''
  fi,
  enable_threads='')
  
--- 235,241 ----
  [  --enable-threads        enable thread usage for target GCC.
    --enable-threads=LIB    use LIB thread package for target GCC.],
  if test x$enable_threads = xno; then
!       enable_threads='no'
  fi,
  enable_threads='')
  

Re: configure --disable-threads

[David S. Miller]

   Date: Tue, 03 Nov 1998 21:02:52 -0700
   From: Jeffrey A Law <law@upchuck.cygnus.com>

   David -- the issue at hand is if --disable-threads or
   --enable-threads=no is specified that the sparc & PA port will try
   to use pthreads if pthread.h exists because enable_threads as an
   empty value in the configure cases for the sparc & PA targets.

   It sounds a little backwards to me, but I don't know if that was
   the behavior you intended or not :-)

It does indeed seem hokey.

What I imagine is being attempted is that if nothing was specified
about the matter on the configure command line, and pthread.h exists,
the user probably wants thread support enabled in the build  by
default.

I suppose there is a better way to achieve this than what we are doing
now.

Note that only the sparc solaris targets do this, and in fact I never
put that weird code there pertaining to this.

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: configure --disable-threads

[Jeffrey A Law]

  In message < 199811022302.PAA00767@monterey.sierravista.com >you write:
  > It does pass through those lines leaving target_thread_file as 'single'.
  > However, down in the configuration-specific area, under hppa1.1-*-hpux10*,
  > $enable_threads gets looked at again:
Ah.  You should have mentioned that the variable was looked at elsewhere
in the file.

I'll note that the sparc does something very similar.

I don't know what semantics the sparc port wants, but we ought to try and
make the sparc & PA do the same thing, whatever it is.

David -- the issue at hand is if --disable-threads or --enable-threads=no
is specified that the sparc & PA port will try to use pthreads if pthread.h
exists because enable_threads as an empty value in the configure cases for
the sparc & PA targets.

It sounds a little backwards to me, but I don't know if that was the behavior
you intended or not :-)

jeff