* configure --disable-threads
@ 1998-10-27 9:04 Steven Parkes
1998-10-30 7:31 ` Jeffrey A Law
0 siblings, 1 reply; 5+ messages in thread
From: Steven Parkes @ 1998-10-27 9:04 UTC (permalink / raw)
To: egcs
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=''
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: configure --disable-threads
1998-10-27 9:04 configure --disable-threads Steven Parkes
@ 1998-10-30 7:31 ` Jeffrey A Law
1998-11-02 19:39 ` Steven Parkes
0 siblings, 1 reply; 5+ messages in thread
From: Jeffrey A Law @ 1998-10-30 7:31 UTC (permalink / raw)
To: Steven Parkes; +Cc: egcs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: configure --disable-threads
1998-10-30 7:31 ` Jeffrey A Law
@ 1998-11-02 19:39 ` Steven Parkes
1998-11-03 23:34 ` Jeffrey A Law
0 siblings, 1 reply; 5+ messages in thread
From: Steven Parkes @ 1998-11-02 19:39 UTC (permalink / raw)
To: law; +Cc: egcs
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='')
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: configure --disable-threads
1998-11-02 19:39 ` Steven Parkes
@ 1998-11-03 23:34 ` Jeffrey A Law
1998-11-03 23:34 ` David S. Miller
0 siblings, 1 reply; 5+ messages in thread
From: Jeffrey A Law @ 1998-11-03 23:34 UTC (permalink / raw)
To: Steven Parkes; +Cc: egcs, David S. Miller
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: configure --disable-threads
1998-11-03 23:34 ` Jeffrey A Law
@ 1998-11-03 23:34 ` David S. Miller
0 siblings, 0 replies; 5+ messages in thread
From: David S. Miller @ 1998-11-03 23:34 UTC (permalink / raw)
To: law; +Cc: parkes, egcs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1998-11-03 23:34 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-10-27 9:04 configure --disable-threads Steven Parkes
1998-10-30 7:31 ` Jeffrey A Law
1998-11-02 19:39 ` Steven Parkes
1998-11-03 23:34 ` Jeffrey A Law
1998-11-03 23:34 ` David S. Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).