* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-31 10:01 Sami Kerola
0 siblings, 0 replies; 16+ messages in thread
From: Sami Kerola @ 2014-10-31 10:01 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]
On 31 October 2014 03:35, Alexandra Yates
<alexandra.yates(a)linux.intel.com> wrote:
> What is the the return on investment for this feature in terms of
> performance?
Markus, fancy answering to why you proposed AX_PTHREAD to be added to project?
> At the moment PowerTOP builds with in 40 seconds from source and building
> the package takes ~15 seconds.
If you want performance making the build system to be none-recursive
could be a good improvement.
http://evbergen.home.xs4all.nl/nonrecursive-make.html
Notice that traceevent should still be built using separate Makefile
even if rest of the project would use single file. I can write change
making the none-recursive build to work, but be aware it will cause
built program binary to be wrote to project top-level directory, e.g.,
not in src/ where it ends up now.
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-11-01 8:15 SF Markus Elfring
0 siblings, 0 replies; 16+ messages in thread
From: SF Markus Elfring @ 2014-11-01 8:15 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
>> I proposed the reuse of the AX_PTHREAD configuration script as a general
>> approach if you are interested to improve software portability around
>> the POSIX threads programming interface.
> How is this different from what we currently have?
The AX_PTHREAD macro provides more configuration checks. How much will it matter
to reuse such safety checks in various software build systems?
Regards,
Markus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-31 18:01 Alexandra Yates
0 siblings, 0 replies; 16+ messages in thread
From: Alexandra Yates @ 2014-10-31 18:01 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
>> What is the the return on investment for this feature in terms of
>> performance?
>
> I did not suggest a change for this issue to increase the build speed
> here. I do
> not really know how often a different run time behaviour will be noticed
> on the
> build systems.
>
> I proposed the reuse of the AX_PTHREAD configuration script as a general
> approach if you are interested to improve software portability around the
> POSIX
> threads programming interface.
>
> Regards,
> Markus
>
How is this different from what we currently have?
Thank you,
Alexandra.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-31 10:20 SF Markus Elfring
0 siblings, 0 replies; 16+ messages in thread
From: SF Markus Elfring @ 2014-10-31 10:20 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
> What is the the return on investment for this feature in terms of performance?
I did not suggest a change for this issue to increase the build speed here. I do
not really know how often a different run time behaviour will be noticed on the
build systems.
I proposed the reuse of the AX_PTHREAD configuration script as a general
approach if you are interested to improve software portability around the POSIX
threads programming interface.
Regards,
Markus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-31 3:35 Alexandra Yates
0 siblings, 0 replies; 16+ messages in thread
From: Alexandra Yates @ 2014-10-31 3:35 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]
> On 25 October 2014 09:58, Sergey Senozhatsky
> <sergey.senozhatsky(a)gmail.com> wrote:
>> On (10/22/14 15:33), Sami Kerola wrote:
>>> On 22 October 2014 13:41, Sergey Senozhatsky
>>> <sergey.senozhatsky(a)gmail.com> wrote:
>>> > m4/* files are host-specific. they should never be part
>>> > of the source code or a package.
>>>
>>> I would not say it so strongly. There are plenty of projects that have
>>> files in m4 directory. Here's couple.
>>>
>>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=tree;f=m4
>>> https://github.com/karelzak/util-linux/tree/master/m4
>>
>> yes, but powertop does not use any optional m4 macros/libs that
>> are not basically available (afaik).
>
> Proposal to use AX_PTHREAD means that will change.
>
> Looking autoconf release notes
>
> http://lwn.net/Articles/531373/
>
> It might be possible to make m4 copies to go to AC_CONFIG_MACRO_DIR,
> while AC_CONFIG_MACRO_DIRS informs project specific m4 search patch.
> Assuming this sort of thing is tried it also looks like the autoconf
> version requirement will need to be pumped to 1.13 from 1.11.1. Please
> notice that I haven't ever tried to use multiple m4 directories, so
> this is reply is based on tons of assumptions without real experience
> or tests about topic. The minimum I need to make progress with
> separation is a decision what is the path for project local m4 files.
>
> That said autotools documentation
>
> http://www.gnu.org/software/automake/manual/html_node/Local-Macros.html
>
> is telling use of m4 directory is fine, and 'there is no consensus on
> the distribution of third-party macros'.
>
> Considering the above I'm 87.5% sure using m4/ directory initially to
> introduce AX_PTHREAD is OK. If needed/wanted/etc later changes can
> move the data around, set autoconf requirement higher, and so on what
> ever might come as aside effect.
>
>> https://lists.01.org/pipermail/powertop/2013-June/000855.html
>
> I do not understand how that message relates to m4 directories.
>
> --
> Sami Kerola
> http://www.iki.fi/kerolasa/
> _______________________________________________
> PowerTop mailing list
> PowerTop(a)lists.01.org
> https://lists.01.org/mailman/listinfo/powertop
>
What is the the return on investment for this feature in terms of
performance?
At the moment PowerTOP builds with in 40 seconds from source and building
the package takes ~15 seconds.
Thank you,
Alexandra.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-31 2:34 Alexandra Yates
0 siblings, 0 replies; 16+ messages in thread
From: Alexandra Yates @ 2014-10-31 2:34 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
All,
> On 22 October 2014 13:41, Sergey Senozhatsky
> <sergey.senozhatsky(a)gmail.com> wrote:
>> m4/* files are host-specific. they should never be part
>> of the source code or a package.
>
> I would not say it so strongly. There are plenty of projects that have
> files in m4 directory. Here's couple.
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=tree;f=m4
> https://github.com/karelzak/util-linux/tree/master/m4
>
> But if powertop does not want to mix files autotools generate with own
> files then an alternative path is needed. Perhaps powertop/m4/ could
> be used. That would leave door open to various other project local
> purposes as well files. What ever is done a maintainer decision is
> needed. In best case the decision should be documented to
> powertop/readmes/project_files.txt or something like that.
>
> --
> Sami Kerola
> http://www.iki.fi/kerolasa/
> _______________________________________________
> PowerTop mailing list
> PowerTop(a)lists.01.org
> https://lists.01.org/mailman/listinfo/powertop
>
I agree with Sergei, we use m4/* for generating our configuration files only.
Thank you,
Alexandra.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-25 10:18 Sami Kerola
0 siblings, 0 replies; 16+ messages in thread
From: Sami Kerola @ 2014-10-25 10:18 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]
On 25 October 2014 09:58, Sergey Senozhatsky
<sergey.senozhatsky(a)gmail.com> wrote:
> On (10/22/14 15:33), Sami Kerola wrote:
>> On 22 October 2014 13:41, Sergey Senozhatsky
>> <sergey.senozhatsky(a)gmail.com> wrote:
>> > m4/* files are host-specific. they should never be part
>> > of the source code or a package.
>>
>> I would not say it so strongly. There are plenty of projects that have
>> files in m4 directory. Here's couple.
>>
>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=tree;f=m4
>> https://github.com/karelzak/util-linux/tree/master/m4
>
> yes, but powertop does not use any optional m4 macros/libs that
> are not basically available (afaik).
Proposal to use AX_PTHREAD means that will change.
Looking autoconf release notes
http://lwn.net/Articles/531373/
It might be possible to make m4 copies to go to AC_CONFIG_MACRO_DIR,
while AC_CONFIG_MACRO_DIRS informs project specific m4 search patch.
Assuming this sort of thing is tried it also looks like the autoconf
version requirement will need to be pumped to 1.13 from 1.11.1. Please
notice that I haven't ever tried to use multiple m4 directories, so
this is reply is based on tons of assumptions without real experience
or tests about topic. The minimum I need to make progress with
separation is a decision what is the path for project local m4 files.
That said autotools documentation
http://www.gnu.org/software/automake/manual/html_node/Local-Macros.html
is telling use of m4 directory is fine, and 'there is no consensus on
the distribution of third-party macros'.
Considering the above I'm 87.5% sure using m4/ directory initially to
introduce AX_PTHREAD is OK. If needed/wanted/etc later changes can
move the data around, set autoconf requirement higher, and so on what
ever might come as aside effect.
> https://lists.01.org/pipermail/powertop/2013-June/000855.html
I do not understand how that message relates to m4 directories.
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-25 8:58 Sergey Senozhatsky
0 siblings, 0 replies; 16+ messages in thread
From: Sergey Senozhatsky @ 2014-10-25 8:58 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On (10/22/14 15:33), Sami Kerola wrote:
> On 22 October 2014 13:41, Sergey Senozhatsky
> <sergey.senozhatsky(a)gmail.com> wrote:
> > m4/* files are host-specific. they should never be part
> > of the source code or a package.
>
> I would not say it so strongly. There are plenty of projects that have
> files in m4 directory. Here's couple.
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=tree;f=m4
> https://github.com/karelzak/util-linux/tree/master/m4
yes, but powertop does not use any optional m4 macros/libs that
are not basically available (afaik).
https://lists.01.org/pipermail/powertop/2013-June/000855.html
-ss
> But if powertop does not want to mix files autotools generate with own
> files then an alternative path is needed. Perhaps powertop/m4/ could
> be used. That would leave door open to various other project local
> purposes as well files. What ever is done a maintainer decision is
> needed. In best case the decision should be documented to
> powertop/readmes/project_files.txt or something like that.
>
> --
> Sami Kerola
> http://www.iki.fi/kerolasa/
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-22 14:33 Sami Kerola
0 siblings, 0 replies; 16+ messages in thread
From: Sami Kerola @ 2014-10-22 14:33 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
On 22 October 2014 13:41, Sergey Senozhatsky
<sergey.senozhatsky(a)gmail.com> wrote:
> m4/* files are host-specific. they should never be part
> of the source code or a package.
I would not say it so strongly. There are plenty of projects that have
files in m4 directory. Here's couple.
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=tree;f=m4
https://github.com/karelzak/util-linux/tree/master/m4
But if powertop does not want to mix files autotools generate with own
files then an alternative path is needed. Perhaps powertop/m4/ could
be used. That would leave door open to various other project local
purposes as well files. What ever is done a maintainer decision is
needed. In best case the decision should be documented to
powertop/readmes/project_files.txt or something like that.
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-22 12:41 Sergey Senozhatsky
0 siblings, 0 replies; 16+ messages in thread
From: Sergey Senozhatsky @ 2014-10-22 12:41 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 17707 bytes --]
On (10/18/14 23:57), Sami Kerola wrote:
> Date: Sat, 18 Oct 2014 23:57:16 +0100 (BST)
> From: Sami Kerola <kerolasa(a)iki.fi>
> To: SF Markus Elfring <elfring(a)users.sourceforge.net>
> Cc: powertop(a)lists.01.org
> Subject: Re: [Powertop] Complete build options for Pthread API
> User-Agent: Alpine 2.03 (LNX 1266 2009-07-14)
>
> On Sat, 18 Oct 2014, SF Markus Elfring wrote:
>
> >Would you like to add the configuration script "AX_PTHREAD" to your build
> >specification?
> >http://www.gnu.org/software/autoconf-archive/ax_pthread.html
> >https://github.com/fenrus75/powertop/blob/86eda5c0851935d5315f604599a0e8f19febc82c/configure.ac#L131
>
> Hi Markus,
>
> I suppose you mean change about like this.
m4/* files are host-specific. they should never be part
of the source code or a package.
-ss
> --->8----
> From: Sami Kerola <kerolasa(a)iki.fi>
> Date: Sat, 18 Oct 2014 23:18:12 +0100
> Subject: [PATCH] configure: use autoconf-archive ax_pthread.m4
>
> The macro figures out how to build C programs using POSIX threads, and
> the PTHREAD_CFLAGS output variable to any special C compiler flags that
> are needed.
>
> Proposed-by: SF Markus Elfring <elfring(a)users.sourceforge.net>
> Signed-off-by: Sami Kerola <kerolasa(a)iki.fi>
> ---
> configure.ac | 8 +-
> m4/ax_pthread.m4 | 332 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 337 insertions(+), 3 deletions(-)
> create mode 100644 m4/ax_pthread.m4
>
> diff --git a/configure.ac b/configure.ac
> index c3f5666..910dbb8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -35,6 +35,11 @@ AC_PROG_INSTALL
> AM_PROG_CC_C_O
>
> # Checks for libraries.
> +AX_PTHREAD([], [AC_MSG_ERROR([Could not configure pthreads support])])
> +LIBS="$PTHREAD_LIBS $LIBS"
> +CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
> +CC="$PTHREAD_CC"
> +
> # Checks for header files.
> AC_CHECK_HEADERS([ \
> fcntl.h \
> @@ -132,9 +137,6 @@ AS_IF([test "$has_libpci" -eq 0], [
> ])
> ])
>
> -AC_SEARCH_LIBS([pthread_create], [pthread], [], [
> - AC_MSG_ERROR([libpthread is required but was not found])
> -], [])
> AC_SEARCH_LIBS([inet_aton], [resolv], [], [
> AC_MSG_ERROR([libresolv is required but was not found])
> ], [])
> diff --git a/m4/ax_pthread.m4 b/m4/ax_pthread.m4
> new file mode 100644
> index 0000000..d383ad5
> --- /dev/null
> +++ b/m4/ax_pthread.m4
> @@ -0,0 +1,332 @@
> +# ===========================================================================
> +# http://www.gnu.org/software/autoconf-archive/ax_pthread.html
> +# ===========================================================================
> +#
> +# SYNOPSIS
> +#
> +# AX_PTHREAD([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> +#
> +# DESCRIPTION
> +#
> +# This macro figures out how to build C programs using POSIX threads. It
> +# sets the PTHREAD_LIBS output variable to the threads library and linker
> +# flags, and the PTHREAD_CFLAGS output variable to any special C compiler
> +# flags that are needed. (The user can also force certain compiler
> +# flags/libs to be tested by setting these environment variables.)
> +#
> +# Also sets PTHREAD_CC to any special C compiler that is needed for
> +# multi-threaded programs (defaults to the value of CC otherwise). (This
> +# is necessary on AIX to use the special cc_r compiler alias.)
> +#
> +# NOTE: You are assumed to not only compile your program with these flags,
> +# but also link it with them as well. e.g. you should link with
> +# $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS $LIBS
> +#
> +# If you are only building threads programs, you may wish to use these
> +# variables in your default LIBS, CFLAGS, and CC:
> +#
> +# LIBS="$PTHREAD_LIBS $LIBS"
> +# CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
> +# CC="$PTHREAD_CC"
> +#
> +# In addition, if the PTHREAD_CREATE_JOINABLE thread-attribute constant
> +# has a nonstandard name, defines PTHREAD_CREATE_JOINABLE to that name
> +# (e.g. PTHREAD_CREATE_UNDETACHED on AIX).
> +#
> +# Also HAVE_PTHREAD_PRIO_INHERIT is defined if pthread is found and the
> +# PTHREAD_PRIO_INHERIT symbol is defined when compiling with
> +# PTHREAD_CFLAGS.
> +#
> +# ACTION-IF-FOUND is a list of shell commands to run if a threads library
> +# is found, and ACTION-IF-NOT-FOUND is a list of commands to run it if it
> +# is not found. If ACTION-IF-FOUND is not specified, the default action
> +# will define HAVE_PTHREAD.
> +#
> +# Please let the authors know if this macro fails on any platform, or if
> +# you have any other suggestions or comments. This macro was based on work
> +# by SGJ on autoconf scripts for FFTW (http://www.fftw.org/) (with help
> +# from M. Frigo), as well as ac_pthread and hb_pthread macros posted by
> +# Alejandro Forero Cuervo to the autoconf macro repository. We are also
> +# grateful for the helpful feedback of numerous users.
> +#
> +# Updated for Autoconf 2.68 by Daniel Richard G.
> +#
> +# LICENSE
> +#
> +# Copyright (c) 2008 Steven G. Johnson <stevenj(a)alum.mit.edu>
> +# Copyright (c) 2011 Daniel Richard G. <skunk(a)iSKUNK.ORG>
> +#
> +# This program is free software: you can redistribute it and/or modify it
> +# under the terms of the GNU General Public License as published by the
> +# Free Software Foundation, either version 3 of the License, or (at your
> +# option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful, but
> +# WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
> +# Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License along
> +# with this program. If not, see <http://www.gnu.org/licenses/>.
> +#
> +# As a special exception, the respective Autoconf Macro's copyright owner
> +# gives unlimited permission to copy, distribute and modify the configure
> +# scripts that are the output of Autoconf when processing the Macro. You
> +# need not follow the terms of the GNU General Public License when using
> +# or distributing such scripts, even though portions of the text of the
> +# Macro appear in them. The GNU General Public License (GPL) does govern
> +# all other use of the material that constitutes the Autoconf Macro.
> +#
> +# This special exception to the GPL applies to versions of the Autoconf
> +# Macro released by the Autoconf Archive. When you make and distribute a
> +# modified version of the Autoconf Macro, you may extend this special
> +# exception to the GPL to apply to your modified version as well.
> +
> +#serial 21
> +
> +AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
> +AC_DEFUN([AX_PTHREAD], [
> +AC_REQUIRE([AC_CANONICAL_HOST])
> +AC_LANG_PUSH([C])
> +ax_pthread_ok=no
> +
> +# We used to check for pthread.h first, but this fails if pthread.h
> +# requires special compiler flags (e.g. on True64 or Sequent).
> +# It gets checked for in the link test anyway.
> +
> +# First of all, check if the user has set any of the PTHREAD_LIBS,
> +# etcetera environment variables, and if threads linking works using
> +# them:
> +if test x"$PTHREAD_LIBS$PTHREAD_CFLAGS" != x; then
> + save_CFLAGS="$CFLAGS"
> + CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
> + save_LIBS="$LIBS"
> + LIBS="$PTHREAD_LIBS $LIBS"
> + AC_MSG_CHECKING([for pthread_join in LIBS=$PTHREAD_LIBS with CFLAGS=$PTHREAD_CFLAGS])
> + AC_TRY_LINK_FUNC([pthread_join], [ax_pthread_ok=yes])
> + AC_MSG_RESULT([$ax_pthread_ok])
> + if test x"$ax_pthread_ok" = xno; then
> + PTHREAD_LIBS=""
> + PTHREAD_CFLAGS=""
> + fi
> + LIBS="$save_LIBS"
> + CFLAGS="$save_CFLAGS"
> +fi
> +
> +# We must check for the threads library under a number of different
> +# names; the ordering is very important because some systems
> +# (e.g. DEC) have both -lpthread and -lpthreads, where one of the
> +# libraries is broken (non-POSIX).
> +
> +# Create a list of thread flags to try. Items starting with a "-" are
> +# C compiler flags, and other items are library names, except for "none"
> +# which indicates that we try without any flags at all, and "pthread-config"
> +# which is a program returning the flags for the Pth emulation library.
> +
> +ax_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config"
> +
> +# The ordering *is* (sometimes) important. Some notes on the
> +# individual items follow:
> +
> +# pthreads: AIX (must check this before -lpthread)
> +# none: in case threads are in libc; should be tried before -Kthread and
> +# other compiler flags to prevent continual compiler warnings
> +# -Kthread: Sequent (threads in libc, but -Kthread needed for pthread.h)
> +# -kthread: FreeBSD kernel threads (preferred to -pthread since SMP-able)
> +# lthread: LinuxThreads port on FreeBSD (also preferred to -pthread)
> +# -pthread: Linux/gcc (kernel threads), BSD/gcc (userland threads)
> +# -pthreads: Solaris/gcc
> +# -mthreads: Mingw32/gcc, Lynx/gcc
> +# -mt: Sun Workshop C (may only link SunOS threads [-lthread], but it
> +# doesn't hurt to check since this sometimes defines pthreads too;
> +# also defines -D_REENTRANT)
> +# ... -mt is also the pthreads flag for HP/aCC
> +# pthread: Linux, etcetera
> +# --thread-safe: KAI C++
> +# pthread-config: use pthread-config program (for GNU Pth library)
> +
> +case ${host_os} in
> + solaris*)
> +
> + # On Solaris (at least, for some versions), libc contains stubbed
> + # (non-functional) versions of the pthreads routines, so link-based
> + # tests will erroneously succeed. (We need to link with -pthreads/-mt/
> + # -lpthread.) (The stubs are missing pthread_cleanup_push, or rather
> + # a function called by this macro, so we could check for that, but
> + # who knows whether they'll stub that too in a future libc.) So,
> + # we'll just look for -pthreads and -lpthread first:
> +
> + ax_pthread_flags="-pthreads pthread -mt -pthread $ax_pthread_flags"
> + ;;
> +
> + darwin*)
> + ax_pthread_flags="-pthread $ax_pthread_flags"
> + ;;
> +esac
> +
> +# Clang doesn't consider unrecognized options an error unless we specify
> +# -Werror. We throw in some extra Clang-specific options to ensure that
> +# this doesn't happen for GCC, which also accepts -Werror.
> +
> +AC_MSG_CHECKING([if compiler needs -Werror to reject unknown flags])
> +save_CFLAGS="$CFLAGS"
> +ax_pthread_extra_flags="-Werror"
> +CFLAGS="$CFLAGS $ax_pthread_extra_flags -Wunknown-warning-option -Wsizeof-array-argument"
> +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([int foo(void);],[foo()])],
> + [AC_MSG_RESULT([yes])],
> + [ax_pthread_extra_flags=
> + AC_MSG_RESULT([no])])
> +CFLAGS="$save_CFLAGS"
> +
> +if test x"$ax_pthread_ok" = xno; then
> +for flag in $ax_pthread_flags; do
> +
> + case $flag in
> + none)
> + AC_MSG_CHECKING([whether pthreads work without any flags])
> + ;;
> +
> + -*)
> + AC_MSG_CHECKING([whether pthreads work with $flag])
> + PTHREAD_CFLAGS="$flag"
> + ;;
> +
> + pthread-config)
> + AC_CHECK_PROG([ax_pthread_config], [pthread-config], [yes], [no])
> + if test x"$ax_pthread_config" = xno; then continue; fi
> + PTHREAD_CFLAGS="`pthread-config --cflags`"
> + PTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
> + ;;
> +
> + *)
> + AC_MSG_CHECKING([for the pthreads library -l$flag])
> + PTHREAD_LIBS="-l$flag"
> + ;;
> + esac
> +
> + save_LIBS="$LIBS"
> + save_CFLAGS="$CFLAGS"
> + LIBS="$PTHREAD_LIBS $LIBS"
> + CFLAGS="$CFLAGS $PTHREAD_CFLAGS $ax_pthread_extra_flags"
> +
> + # Check for various functions. We must include pthread.h,
> + # since some functions may be macros. (On the Sequent, we
> + # need a special flag -Kthread to make this header compile.)
> + # We check for pthread_join because it is in -lpthread on IRIX
> + # while pthread_create is in libc. We check for pthread_attr_init
> + # due to DEC craziness with -lpthreads. We check for
> + # pthread_cleanup_push because it is one of the few pthread
> + # functions on Solaris that doesn't have a non-functional libc stub.
> + # We try pthread_create on general principles.
> + AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>
> + static void routine(void *a) { a = 0; }
> + static void *start_routine(void *a) { return a; }],
> + [pthread_t th; pthread_attr_t attr;
> + pthread_create(&th, 0, start_routine, 0);
> + pthread_join(th, 0);
> + pthread_attr_init(&attr);
> + pthread_cleanup_push(routine, 0);
> + pthread_cleanup_pop(0) /* ; */])],
> + [ax_pthread_ok=yes],
> + [])
> +
> + LIBS="$save_LIBS"
> + CFLAGS="$save_CFLAGS"
> +
> + AC_MSG_RESULT([$ax_pthread_ok])
> + if test "x$ax_pthread_ok" = xyes; then
> + break;
> + fi
> +
> + PTHREAD_LIBS=""
> + PTHREAD_CFLAGS=""
> +done
> +fi
> +
> +# Various other checks:
> +if test "x$ax_pthread_ok" = xyes; then
> + save_LIBS="$LIBS"
> + LIBS="$PTHREAD_LIBS $LIBS"
> + save_CFLAGS="$CFLAGS"
> + CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
> +
> + # Detect AIX lossage: JOINABLE attribute is called UNDETACHED.
> + AC_MSG_CHECKING([for joinable pthread attribute])
> + attr_name=unknown
> + for attr in PTHREAD_CREATE_JOINABLE PTHREAD_CREATE_UNDETACHED; do
> + AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>],
> + [int attr = $attr; return attr /* ; */])],
> + [attr_name=$attr; break],
> + [])
> + done
> + AC_MSG_RESULT([$attr_name])
> + if test "$attr_name" != PTHREAD_CREATE_JOINABLE; then
> + AC_DEFINE_UNQUOTED([PTHREAD_CREATE_JOINABLE], [$attr_name],
> + [Define to necessary symbol if this constant
> + uses a non-standard name on your system.])
> + fi
> +
> + AC_MSG_CHECKING([if more special flags are required for pthreads])
> + flag=no
> + case ${host_os} in
> + aix* | freebsd* | darwin*) flag="-D_THREAD_SAFE";;
> + osf* | hpux*) flag="-D_REENTRANT";;
> + solaris*)
> + if test "$GCC" = "yes"; then
> + flag="-D_REENTRANT"
> + else
> + # TODO: What about Clang on Solaris?
> + flag="-mt -D_REENTRANT"
> + fi
> + ;;
> + esac
> + AC_MSG_RESULT([$flag])
> + if test "x$flag" != xno; then
> + PTHREAD_CFLAGS="$flag $PTHREAD_CFLAGS"
> + fi
> +
> + AC_CACHE_CHECK([for PTHREAD_PRIO_INHERIT],
> + [ax_cv_PTHREAD_PRIO_INHERIT], [
> + AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <pthread.h>]],
> + [[int i = PTHREAD_PRIO_INHERIT;]])],
> + [ax_cv_PTHREAD_PRIO_INHERIT=yes],
> + [ax_cv_PTHREAD_PRIO_INHERIT=no])
> + ])
> + AS_IF([test "x$ax_cv_PTHREAD_PRIO_INHERIT" = "xyes"],
> + [AC_DEFINE([HAVE_PTHREAD_PRIO_INHERIT], [1], [Have PTHREAD_PRIO_INHERIT.])])
> +
> + LIBS="$save_LIBS"
> + CFLAGS="$save_CFLAGS"
> +
> + # More AIX lossage: compile with *_r variant
> + if test "x$GCC" != xyes; then
> + case $host_os in
> + aix*)
> + AS_CASE(["x/$CC"],
> + [x*/c89|x*/c89_128|x*/c99|x*/c99_128|x*/cc|x*/cc128|x*/xlc|x*/xlc_v6|x*/xlc128|x*/xlc128_v6],
> + [#handle absolute path differently from PATH based program lookup
> + AS_CASE(["x$CC"],
> + [x/*],
> + [AS_IF([AS_EXECUTABLE_P([${CC}_r])],[PTHREAD_CC="${CC}_r"])],
> + [AC_CHECK_PROGS([PTHREAD_CC],[${CC}_r],[$CC])])])
> + ;;
> + esac
> + fi
> +fi
> +
> +test -n "$PTHREAD_CC" || PTHREAD_CC="$CC"
> +
> +AC_SUBST([PTHREAD_LIBS])
> +AC_SUBST([PTHREAD_CFLAGS])
> +AC_SUBST([PTHREAD_CC])
> +
> +# Finally, execute ACTION-IF-FOUND/ACTION-IF-NOT-FOUND:
> +if test x"$ax_pthread_ok" = xyes; then
> + ifelse([$1],,[AC_DEFINE([HAVE_PTHREAD],[1],[Define if you have POSIX threads libraries and header files.])],[$1])
> + :
> +else
> + ax_pthread_ok=no
> + $2
> +fi
> +AC_LANG_POP
> +])dnl AX_PTHREAD
> --
> 2.1.2
>
> _______________________________________________
> PowerTop mailing list
> PowerTop(a)lists.01.org
> https://lists.01.org/mailman/listinfo/powertop
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-22 9:41 Sami Kerola
0 siblings, 0 replies; 16+ messages in thread
From: Sami Kerola @ 2014-10-22 9:41 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]
On 20 October 2014 05:44, SF Markus Elfring
<elfring(a)users.sourceforge.net> wrote:
>> I don't know what sort of adjustments you have in mind.
>
> I suggest a bit more fine-tuning for the explanation.
>
>
>> The variables are in commit body, so I am assuming people who read code
>> can see them without explicit note about them.
>
> I would prefer a commit message that will also be useful to some degree without
> reading the affected source code.
>
>
>> But if you insist improvement with the message could you write what you
>> would like to see so that I can include it without confusions.
>
> You can see from a few contributions for other software that I used a wording
> like the following:
>
> The configuration script "AX_PTHREAD" was added to the build specification
> so that corresponding special parameters will be taken into account.
> http://www.gnu.org/software/autoconf-archive/ax_pthread.html
>
>
>
> You might be still interested to stress other details for your PowerTop testers
> and reviewers.
Thanks Markus. I will add your text to commit message & Reviewed-by
line.
>>>> +AX_PTHREAD([], [AC_MSG_ERROR([Could not configure pthreads support])])
>>>
>>> 2. You chose to pass an empty "ACTION-IF-FOUND". Would it make sense to
>>> restructure this place a bit in the configuration script so that the
>>> following statements will be directly used by the first macro parameter?
>>
>> That would make powertop m4 code copy to drift from version provided by
>> autotools-archive, making the upstream fixes to incompatible. I strongly
>> recommend against adding additional maintenance cost to this sort of stuff.
>
> I do not really understand the intention in this feedback.
And when I see your message below I understand why. We were talking
about totally different things. Please ignore my previous message.
> How do you think about the following statement layout at the discussed script place?
>
> diff --git a/configure.ac b/configure.ac
> index 4991d97..0ebe69d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -128,11 +128,12 @@ AS_IF([test "$has_libpci" -eq 0], [
> ])
> ])
>
> -AC_SEARCH_LIBS([pthread_create], [pthread], [], [
> - AC_MSG_ERROR([libpthread is required but was not found])
> -], [])
> -AC_SEARCH_LIBS([inet_aton], [resolv], [], [
> - AC_MSG_ERROR([libresolv is required but was not found])
> -], [])
> -
> -AC_OUTPUT
> +AX_PTHREAD([LIBS="$PTHREAD_LIBS $LIBS"
> +CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
> +CC="$PTHREAD_CC"
> +AC_SEARCH_LIBS([inet_aton],
> + [resolv],
> + [AC_OUTPUT],
> + [AC_MSG_ERROR([libresolv is required but was not found])],
> + [])],
> + [AC_MSG_ERROR([Could not configure pthreads support])])
Indentation seems a bit funky in the proposed change, but that could be
fixed. The bigger problem I have with nesting AC_SEARCH_LIBS to
AX_PTHREAD is that it does not seem to add clarity. Secondly the
threading seems to be used in calibrate & measure/extech code. If I am
not wrong that code do not require resolv library.
Perhaps the LIBS etc variable assignments should be in true case of
AX_PTHREAD, but surely not the resolv library search. I'll run
./autogen.sh to that variation to see how the Makefile will look with
this variant to see it has change working as one might expect.
This and few other patches will be resubmitted about at the end of the
Sunday (I'm just hobbyist, so I can use only my free time to things
like powertop hacking).
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-20 4:44 SF Markus Elfring
0 siblings, 0 replies; 16+ messages in thread
From: SF Markus Elfring @ 2014-10-20 4:44 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]
> I don't know what sort of adjustments you have in mind.
I suggest a bit more fine-tuning for the explanation.
> The variables are in commit body, so I am assuming people who read code
> can see them without explicit note about them.
I would prefer a commit message that will also be useful to some degree without
reading the affected source code.
> But if you insist improvement with the message could you write what you
> would like to see so that I can include it without confusions.
You can see from a few contributions for other software that I used a wording
like the following:
The configuration script "AX_PTHREAD" was added to the build specification
so that corresponding special parameters will be taken into account.
http://www.gnu.org/software/autoconf-archive/ax_pthread.html
You might be still interested to stress other details for your PowerTop testers
and reviewers.
>>> +AX_PTHREAD([], [AC_MSG_ERROR([Could not configure pthreads support])])
>>
>> 2. You chose to pass an empty "ACTION-IF-FOUND". Would it make sense to
>> restructure this place a bit in the configuration script so that the
>> following statements will be directly used by the first macro parameter?
>
> That would make powertop m4 code copy to drift from version provided by
> autotools-archive, making the upstream fixes to incompatible. I strongly
> recommend against adding additional maintenance cost to this sort of stuff.
I do not really understand the intention in this feedback.
How do you think about the following statement layout at the discussed script place?
diff --git a/configure.ac b/configure.ac
index 4991d97..0ebe69d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -128,11 +128,12 @@ AS_IF([test "$has_libpci" -eq 0], [
])
])
-AC_SEARCH_LIBS([pthread_create], [pthread], [], [
- AC_MSG_ERROR([libpthread is required but was not found])
-], [])
-AC_SEARCH_LIBS([inet_aton], [resolv], [], [
- AC_MSG_ERROR([libresolv is required but was not found])
-], [])
-
-AC_OUTPUT
+AX_PTHREAD([LIBS="$PTHREAD_LIBS $LIBS"
+CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+CC="$PTHREAD_CC"
+AC_SEARCH_LIBS([inet_aton],
+ [resolv],
+ [AC_OUTPUT],
+ [AC_MSG_ERROR([libresolv is required but was not found])],
+ [])],
+ [AC_MSG_ERROR([Could not configure pthreads support])])
Regards,
Markus
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-19 18:18 Sami Kerola
0 siblings, 0 replies; 16+ messages in thread
From: Sami Kerola @ 2014-10-19 18:18 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On 19 October 2014 12:30, SF Markus Elfring
<elfring(a)users.sourceforge.net> wrote:
>> I suppose you mean change about like this.
>
> Yes. - Your approach comes very close to my imaginations.
>
> I suggest to reconsider a few implementation details there.
>
>
>> The macro figures out how to build C programs using POSIX threads, and
>> the PTHREAD_CFLAGS output variable to any special C compiler flags that
>> are needed.
>
> 1. How do you think about to mention in your commit message that three
> variables (including "LIBS") will be adjusted eventually?
I don't know what sort of adjustments you have in mind. The variables are
in commit body, so I am assuming people who read code can see them without
explicit note about them. But if you insist improvement with the message could
you write what you would like to see so that I can include it without
confusions.
>> +AX_PTHREAD([], [AC_MSG_ERROR([Could not configure pthreads support])])
>
> 2. You chose to pass an empty "ACTION-IF-FOUND". Would it make sense to
> restructure this place a bit in the configuration script so that the
> following statements will be directly used by the first macro parameter?
That would make powertop m4 code copy to drift from version provided by
autotools-archive, making the upstream fixes to incompatible. I strongly
recommend against adding additional maintenance cost to this sort of stuff.
--
Sami Kerola
http://www.iki.fi/kerolasa/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-19 11:30 SF Markus Elfring
0 siblings, 0 replies; 16+ messages in thread
From: SF Markus Elfring @ 2014-10-19 11:30 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
> I suppose you mean change about like this.
Yes. - Your approach comes very close to my imaginations.
I suggest to reconsider a few implementation details there.
> The macro figures out how to build C programs using POSIX threads, and
> the PTHREAD_CFLAGS output variable to any special C compiler flags that
> are needed.
1. How do you think about to mention in your commit message that three
variables (including "LIBS") will be adjusted eventually?
> +AX_PTHREAD([], [AC_MSG_ERROR([Could not configure pthreads support])])
2. You chose to pass an empty "ACTION-IF-FOUND". Would it make sense to
restructure this place a bit in the configuration script so that the
following statements will be directly used by the first macro parameter?
Regards,
Markus
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Powertop] Complete build options for Pthread API
@ 2014-10-18 22:57 Sami Kerola
0 siblings, 0 replies; 16+ messages in thread
From: Sami Kerola @ 2014-10-18 22:57 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 16341 bytes --]
On Sat, 18 Oct 2014, SF Markus Elfring wrote:
> Would you like to add the configuration script "AX_PTHREAD" to your build
> specification?
> http://www.gnu.org/software/autoconf-archive/ax_pthread.html
> https://github.com/fenrus75/powertop/blob/86eda5c0851935d5315f604599a0e8f19febc82c/configure.ac#L131
Hi Markus,
I suppose you mean change about like this.
--->8----
From: Sami Kerola <kerolasa(a)iki.fi>
Date: Sat, 18 Oct 2014 23:18:12 +0100
Subject: [PATCH] configure: use autoconf-archive ax_pthread.m4
The macro figures out how to build C programs using POSIX threads, and
the PTHREAD_CFLAGS output variable to any special C compiler flags that
are needed.
Proposed-by: SF Markus Elfring <elfring(a)users.sourceforge.net>
Signed-off-by: Sami Kerola <kerolasa(a)iki.fi>
---
configure.ac | 8 +-
m4/ax_pthread.m4 | 332 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 337 insertions(+), 3 deletions(-)
create mode 100644 m4/ax_pthread.m4
diff --git a/configure.ac b/configure.ac
index c3f5666..910dbb8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,6 +35,11 @@ AC_PROG_INSTALL
AM_PROG_CC_C_O
# Checks for libraries.
+AX_PTHREAD([], [AC_MSG_ERROR([Could not configure pthreads support])])
+LIBS="$PTHREAD_LIBS $LIBS"
+CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+CC="$PTHREAD_CC"
+
# Checks for header files.
AC_CHECK_HEADERS([ \
fcntl.h \
@@ -132,9 +137,6 @@ AS_IF([test "$has_libpci" -eq 0], [
])
])
-AC_SEARCH_LIBS([pthread_create], [pthread], [], [
- AC_MSG_ERROR([libpthread is required but was not found])
-], [])
AC_SEARCH_LIBS([inet_aton], [resolv], [], [
AC_MSG_ERROR([libresolv is required but was not found])
], [])
diff --git a/m4/ax_pthread.m4 b/m4/ax_pthread.m4
new file mode 100644
index 0000000..d383ad5
--- /dev/null
+++ b/m4/ax_pthread.m4
@@ -0,0 +1,332 @@
+# ===========================================================================
+# http://www.gnu.org/software/autoconf-archive/ax_pthread.html
+# ===========================================================================
+#
+# SYNOPSIS
+#
+# AX_PTHREAD([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
+#
+# DESCRIPTION
+#
+# This macro figures out how to build C programs using POSIX threads. It
+# sets the PTHREAD_LIBS output variable to the threads library and linker
+# flags, and the PTHREAD_CFLAGS output variable to any special C compiler
+# flags that are needed. (The user can also force certain compiler
+# flags/libs to be tested by setting these environment variables.)
+#
+# Also sets PTHREAD_CC to any special C compiler that is needed for
+# multi-threaded programs (defaults to the value of CC otherwise). (This
+# is necessary on AIX to use the special cc_r compiler alias.)
+#
+# NOTE: You are assumed to not only compile your program with these flags,
+# but also link it with them as well. e.g. you should link with
+# $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS $LIBS
+#
+# If you are only building threads programs, you may wish to use these
+# variables in your default LIBS, CFLAGS, and CC:
+#
+# LIBS="$PTHREAD_LIBS $LIBS"
+# CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+# CC="$PTHREAD_CC"
+#
+# In addition, if the PTHREAD_CREATE_JOINABLE thread-attribute constant
+# has a nonstandard name, defines PTHREAD_CREATE_JOINABLE to that name
+# (e.g. PTHREAD_CREATE_UNDETACHED on AIX).
+#
+# Also HAVE_PTHREAD_PRIO_INHERIT is defined if pthread is found and the
+# PTHREAD_PRIO_INHERIT symbol is defined when compiling with
+# PTHREAD_CFLAGS.
+#
+# ACTION-IF-FOUND is a list of shell commands to run if a threads library
+# is found, and ACTION-IF-NOT-FOUND is a list of commands to run it if it
+# is not found. If ACTION-IF-FOUND is not specified, the default action
+# will define HAVE_PTHREAD.
+#
+# Please let the authors know if this macro fails on any platform, or if
+# you have any other suggestions or comments. This macro was based on work
+# by SGJ on autoconf scripts for FFTW (http://www.fftw.org/) (with help
+# from M. Frigo), as well as ac_pthread and hb_pthread macros posted by
+# Alejandro Forero Cuervo to the autoconf macro repository. We are also
+# grateful for the helpful feedback of numerous users.
+#
+# Updated for Autoconf 2.68 by Daniel Richard G.
+#
+# LICENSE
+#
+# Copyright (c) 2008 Steven G. Johnson <stevenj(a)alum.mit.edu>
+# Copyright (c) 2011 Daniel Richard G. <skunk(a)iSKUNK.ORG>
+#
+# This program is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation, either version 3 of the License, or (at your
+# option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
+# Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# As a special exception, the respective Autoconf Macro's copyright owner
+# gives unlimited permission to copy, distribute and modify the configure
+# scripts that are the output of Autoconf when processing the Macro. You
+# need not follow the terms of the GNU General Public License when using
+# or distributing such scripts, even though portions of the text of the
+# Macro appear in them. The GNU General Public License (GPL) does govern
+# all other use of the material that constitutes the Autoconf Macro.
+#
+# This special exception to the GPL applies to versions of the Autoconf
+# Macro released by the Autoconf Archive. When you make and distribute a
+# modified version of the Autoconf Macro, you may extend this special
+# exception to the GPL to apply to your modified version as well.
+
+#serial 21
+
+AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
+AC_DEFUN([AX_PTHREAD], [
+AC_REQUIRE([AC_CANONICAL_HOST])
+AC_LANG_PUSH([C])
+ax_pthread_ok=no
+
+# We used to check for pthread.h first, but this fails if pthread.h
+# requires special compiler flags (e.g. on True64 or Sequent).
+# It gets checked for in the link test anyway.
+
+# First of all, check if the user has set any of the PTHREAD_LIBS,
+# etcetera environment variables, and if threads linking works using
+# them:
+if test x"$PTHREAD_LIBS$PTHREAD_CFLAGS" != x; then
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+ save_LIBS="$LIBS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ AC_MSG_CHECKING([for pthread_join in LIBS=$PTHREAD_LIBS with CFLAGS=$PTHREAD_CFLAGS])
+ AC_TRY_LINK_FUNC([pthread_join], [ax_pthread_ok=yes])
+ AC_MSG_RESULT([$ax_pthread_ok])
+ if test x"$ax_pthread_ok" = xno; then
+ PTHREAD_LIBS=""
+ PTHREAD_CFLAGS=""
+ fi
+ LIBS="$save_LIBS"
+ CFLAGS="$save_CFLAGS"
+fi
+
+# We must check for the threads library under a number of different
+# names; the ordering is very important because some systems
+# (e.g. DEC) have both -lpthread and -lpthreads, where one of the
+# libraries is broken (non-POSIX).
+
+# Create a list of thread flags to try. Items starting with a "-" are
+# C compiler flags, and other items are library names, except for "none"
+# which indicates that we try without any flags at all, and "pthread-config"
+# which is a program returning the flags for the Pth emulation library.
+
+ax_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config"
+
+# The ordering *is* (sometimes) important. Some notes on the
+# individual items follow:
+
+# pthreads: AIX (must check this before -lpthread)
+# none: in case threads are in libc; should be tried before -Kthread and
+# other compiler flags to prevent continual compiler warnings
+# -Kthread: Sequent (threads in libc, but -Kthread needed for pthread.h)
+# -kthread: FreeBSD kernel threads (preferred to -pthread since SMP-able)
+# lthread: LinuxThreads port on FreeBSD (also preferred to -pthread)
+# -pthread: Linux/gcc (kernel threads), BSD/gcc (userland threads)
+# -pthreads: Solaris/gcc
+# -mthreads: Mingw32/gcc, Lynx/gcc
+# -mt: Sun Workshop C (may only link SunOS threads [-lthread], but it
+# doesn't hurt to check since this sometimes defines pthreads too;
+# also defines -D_REENTRANT)
+# ... -mt is also the pthreads flag for HP/aCC
+# pthread: Linux, etcetera
+# --thread-safe: KAI C++
+# pthread-config: use pthread-config program (for GNU Pth library)
+
+case ${host_os} in
+ solaris*)
+
+ # On Solaris (at least, for some versions), libc contains stubbed
+ # (non-functional) versions of the pthreads routines, so link-based
+ # tests will erroneously succeed. (We need to link with -pthreads/-mt/
+ # -lpthread.) (The stubs are missing pthread_cleanup_push, or rather
+ # a function called by this macro, so we could check for that, but
+ # who knows whether they'll stub that too in a future libc.) So,
+ # we'll just look for -pthreads and -lpthread first:
+
+ ax_pthread_flags="-pthreads pthread -mt -pthread $ax_pthread_flags"
+ ;;
+
+ darwin*)
+ ax_pthread_flags="-pthread $ax_pthread_flags"
+ ;;
+esac
+
+# Clang doesn't consider unrecognized options an error unless we specify
+# -Werror. We throw in some extra Clang-specific options to ensure that
+# this doesn't happen for GCC, which also accepts -Werror.
+
+AC_MSG_CHECKING([if compiler needs -Werror to reject unknown flags])
+save_CFLAGS="$CFLAGS"
+ax_pthread_extra_flags="-Werror"
+CFLAGS="$CFLAGS $ax_pthread_extra_flags -Wunknown-warning-option -Wsizeof-array-argument"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([int foo(void);],[foo()])],
+ [AC_MSG_RESULT([yes])],
+ [ax_pthread_extra_flags=
+ AC_MSG_RESULT([no])])
+CFLAGS="$save_CFLAGS"
+
+if test x"$ax_pthread_ok" = xno; then
+for flag in $ax_pthread_flags; do
+
+ case $flag in
+ none)
+ AC_MSG_CHECKING([whether pthreads work without any flags])
+ ;;
+
+ -*)
+ AC_MSG_CHECKING([whether pthreads work with $flag])
+ PTHREAD_CFLAGS="$flag"
+ ;;
+
+ pthread-config)
+ AC_CHECK_PROG([ax_pthread_config], [pthread-config], [yes], [no])
+ if test x"$ax_pthread_config" = xno; then continue; fi
+ PTHREAD_CFLAGS="`pthread-config --cflags`"
+ PTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
+ ;;
+
+ *)
+ AC_MSG_CHECKING([for the pthreads library -l$flag])
+ PTHREAD_LIBS="-l$flag"
+ ;;
+ esac
+
+ save_LIBS="$LIBS"
+ save_CFLAGS="$CFLAGS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS $ax_pthread_extra_flags"
+
+ # Check for various functions. We must include pthread.h,
+ # since some functions may be macros. (On the Sequent, we
+ # need a special flag -Kthread to make this header compile.)
+ # We check for pthread_join because it is in -lpthread on IRIX
+ # while pthread_create is in libc. We check for pthread_attr_init
+ # due to DEC craziness with -lpthreads. We check for
+ # pthread_cleanup_push because it is one of the few pthread
+ # functions on Solaris that doesn't have a non-functional libc stub.
+ # We try pthread_create on general principles.
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>
+ static void routine(void *a) { a = 0; }
+ static void *start_routine(void *a) { return a; }],
+ [pthread_t th; pthread_attr_t attr;
+ pthread_create(&th, 0, start_routine, 0);
+ pthread_join(th, 0);
+ pthread_attr_init(&attr);
+ pthread_cleanup_push(routine, 0);
+ pthread_cleanup_pop(0) /* ; */])],
+ [ax_pthread_ok=yes],
+ [])
+
+ LIBS="$save_LIBS"
+ CFLAGS="$save_CFLAGS"
+
+ AC_MSG_RESULT([$ax_pthread_ok])
+ if test "x$ax_pthread_ok" = xyes; then
+ break;
+ fi
+
+ PTHREAD_LIBS=""
+ PTHREAD_CFLAGS=""
+done
+fi
+
+# Various other checks:
+if test "x$ax_pthread_ok" = xyes; then
+ save_LIBS="$LIBS"
+ LIBS="$PTHREAD_LIBS $LIBS"
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
+
+ # Detect AIX lossage: JOINABLE attribute is called UNDETACHED.
+ AC_MSG_CHECKING([for joinable pthread attribute])
+ attr_name=unknown
+ for attr in PTHREAD_CREATE_JOINABLE PTHREAD_CREATE_UNDETACHED; do
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <pthread.h>],
+ [int attr = $attr; return attr /* ; */])],
+ [attr_name=$attr; break],
+ [])
+ done
+ AC_MSG_RESULT([$attr_name])
+ if test "$attr_name" != PTHREAD_CREATE_JOINABLE; then
+ AC_DEFINE_UNQUOTED([PTHREAD_CREATE_JOINABLE], [$attr_name],
+ [Define to necessary symbol if this constant
+ uses a non-standard name on your system.])
+ fi
+
+ AC_MSG_CHECKING([if more special flags are required for pthreads])
+ flag=no
+ case ${host_os} in
+ aix* | freebsd* | darwin*) flag="-D_THREAD_SAFE";;
+ osf* | hpux*) flag="-D_REENTRANT";;
+ solaris*)
+ if test "$GCC" = "yes"; then
+ flag="-D_REENTRANT"
+ else
+ # TODO: What about Clang on Solaris?
+ flag="-mt -D_REENTRANT"
+ fi
+ ;;
+ esac
+ AC_MSG_RESULT([$flag])
+ if test "x$flag" != xno; then
+ PTHREAD_CFLAGS="$flag $PTHREAD_CFLAGS"
+ fi
+
+ AC_CACHE_CHECK([for PTHREAD_PRIO_INHERIT],
+ [ax_cv_PTHREAD_PRIO_INHERIT], [
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <pthread.h>]],
+ [[int i = PTHREAD_PRIO_INHERIT;]])],
+ [ax_cv_PTHREAD_PRIO_INHERIT=yes],
+ [ax_cv_PTHREAD_PRIO_INHERIT=no])
+ ])
+ AS_IF([test "x$ax_cv_PTHREAD_PRIO_INHERIT" = "xyes"],
+ [AC_DEFINE([HAVE_PTHREAD_PRIO_INHERIT], [1], [Have PTHREAD_PRIO_INHERIT.])])
+
+ LIBS="$save_LIBS"
+ CFLAGS="$save_CFLAGS"
+
+ # More AIX lossage: compile with *_r variant
+ if test "x$GCC" != xyes; then
+ case $host_os in
+ aix*)
+ AS_CASE(["x/$CC"],
+ [x*/c89|x*/c89_128|x*/c99|x*/c99_128|x*/cc|x*/cc128|x*/xlc|x*/xlc_v6|x*/xlc128|x*/xlc128_v6],
+ [#handle absolute path differently from PATH based program lookup
+ AS_CASE(["x$CC"],
+ [x/*],
+ [AS_IF([AS_EXECUTABLE_P([${CC}_r])],[PTHREAD_CC="${CC}_r"])],
+ [AC_CHECK_PROGS([PTHREAD_CC],[${CC}_r],[$CC])])])
+ ;;
+ esac
+ fi
+fi
+
+test -n "$PTHREAD_CC" || PTHREAD_CC="$CC"
+
+AC_SUBST([PTHREAD_LIBS])
+AC_SUBST([PTHREAD_CFLAGS])
+AC_SUBST([PTHREAD_CC])
+
+# Finally, execute ACTION-IF-FOUND/ACTION-IF-NOT-FOUND:
+if test x"$ax_pthread_ok" = xyes; then
+ ifelse([$1],,[AC_DEFINE([HAVE_PTHREAD],[1],[Define if you have POSIX threads libraries and header files.])],[$1])
+ :
+else
+ ax_pthread_ok=no
+ $2
+fi
+AC_LANG_POP
+])dnl AX_PTHREAD
--
2.1.2
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Powertop] Complete build options for Pthread API
@ 2014-10-18 19:20 SF Markus Elfring
0 siblings, 0 replies; 16+ messages in thread
From: SF Markus Elfring @ 2014-10-18 19:20 UTC (permalink / raw)
To: powertop
[-- Attachment #1: Type: text/plain, Size: 285 bytes --]
Hello,
Would you like to add the configuration script "AX_PTHREAD" to your build
specification?
http://www.gnu.org/software/autoconf-archive/ax_pthread.html
https://github.com/fenrus75/powertop/blob/86eda5c0851935d5315f604599a0e8f19febc82c/configure.ac#L131
Regards,
Markus
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-11-01 8:15 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-31 10:01 [Powertop] Complete build options for Pthread API Sami Kerola
-- strict thread matches above, loose matches on Subject: below --
2014-11-01 8:15 SF Markus Elfring
2014-10-31 18:01 Alexandra Yates
2014-10-31 10:20 SF Markus Elfring
2014-10-31 3:35 Alexandra Yates
2014-10-31 2:34 Alexandra Yates
2014-10-25 10:18 Sami Kerola
2014-10-25 8:58 Sergey Senozhatsky
2014-10-22 14:33 Sami Kerola
2014-10-22 12:41 Sergey Senozhatsky
2014-10-22 9:41 Sami Kerola
2014-10-20 4:44 SF Markus Elfring
2014-10-19 18:18 Sami Kerola
2014-10-19 11:30 SF Markus Elfring
2014-10-18 22:57 Sami Kerola
2014-10-18 19:20 SF Markus Elfring
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.