Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

2018-05-09 Thread Jason Merrill
Applied.

On Tue, May 8, 2018 at 7:47 PM, Joshua Watt  wrote:
> On Wed, Apr 18, 2018, 05:20 Pedro Alves  wrote:
>
>> On 04/17/2018 11:10 PM, Joshua Watt wrote:
>> > On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
>> >> On 04/17/2018 06:24 PM, Joshua Watt wrote:
>> >>> Ping? I'd really like to get this in binutils, which apparently
>> >>> requires getting it here first.
>> >>
>> >> I think it would help if you mentioned what this is and
>> >> what is the intended use case.
>> >
>> > Ah, that would probably be helpful! Yes, this was discussed on the
>> > binutils mailing list, see:
>> > https://sourceware.org/ml/binutils/2018-02/msg00260.html
>> >
>> > In short summary: the gold linker doesn't currently build for mingw,
>> > but only because it is attempting to link against libpthread
>> > incorrectly on that platform. Instead of bringing in more specialized
>> > logic to account for that, I opted to include the autotools
>> > ax_pthread.m4 macro (this patch) that automatically handles discovering
>> > pthreads on a wide variety of platforms and compilers, including mingw.
>> >
>> > binutils slaves its config/ directory to GCC, so the patch is required
>> > to be committed here first, and then it will be ported over there.
>>
>> Thanks, that helps indeed.
>>
>> I agree that the ax_pthread.m4 approach makes sense.  Better to use
>> a field-tested macro than reinvent the wheel.  We're using other
>> files from the autoconf-archive archive already, for similar reasons
>> (e.g., config/ax_check_define.m4, and gdb/ax_cxx_compile_stdcxx.m4).
>>
>> Since GCC won't be using it (yet at least, but it's conceivable it
>> could make use of it in future), there should be no harm in
>> installing it even if GCC is in stage 4, IMO.
>>
>> I don't have the authority to approve it, though.
>>
>> Thanks,
>> Pedro Alves
>>
>
> Ping (again)
>
>>


Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

2018-05-08 Thread Joshua Watt
On Wed, Apr 18, 2018, 05:20 Pedro Alves  wrote:

> On 04/17/2018 11:10 PM, Joshua Watt wrote:
> > On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
> >> On 04/17/2018 06:24 PM, Joshua Watt wrote:
> >>> Ping? I'd really like to get this in binutils, which apparently
> >>> requires getting it here first.
> >>
> >> I think it would help if you mentioned what this is and
> >> what is the intended use case.
> >
> > Ah, that would probably be helpful! Yes, this was discussed on the
> > binutils mailing list, see:
> > https://sourceware.org/ml/binutils/2018-02/msg00260.html
> >
> > In short summary: the gold linker doesn't currently build for mingw,
> > but only because it is attempting to link against libpthread
> > incorrectly on that platform. Instead of bringing in more specialized
> > logic to account for that, I opted to include the autotools
> > ax_pthread.m4 macro (this patch) that automatically handles discovering
> > pthreads on a wide variety of platforms and compilers, including mingw.
> >
> > binutils slaves its config/ directory to GCC, so the patch is required
> > to be committed here first, and then it will be ported over there.
>
> Thanks, that helps indeed.
>
> I agree that the ax_pthread.m4 approach makes sense.  Better to use
> a field-tested macro than reinvent the wheel.  We're using other
> files from the autoconf-archive archive already, for similar reasons
> (e.g., config/ax_check_define.m4, and gdb/ax_cxx_compile_stdcxx.m4).
>
> Since GCC won't be using it (yet at least, but it's conceivable it
> could make use of it in future), there should be no harm in
> installing it even if GCC is in stage 4, IMO.
>
> I don't have the authority to approve it, though.
>
> Thanks,
> Pedro Alves
>

Ping (again)

>


Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

2018-04-18 Thread Pedro Alves
On 04/17/2018 11:10 PM, Joshua Watt wrote:
> On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
>> On 04/17/2018 06:24 PM, Joshua Watt wrote:
>>> Ping? I'd really like to get this in binutils, which apparently
>>> requires getting it here first.
>>
>> I think it would help if you mentioned what this is and
>> what is the intended use case.
> 
> Ah, that would probably be helpful! Yes, this was discussed on the
> binutils mailing list, see:
> https://sourceware.org/ml/binutils/2018-02/msg00260.html
> 
> In short summary: the gold linker doesn't currently build for mingw,
> but only because it is attempting to link against libpthread
> incorrectly on that platform. Instead of bringing in more specialized
> logic to account for that, I opted to include the autotools
> ax_pthread.m4 macro (this patch) that automatically handles discovering
> pthreads on a wide variety of platforms and compilers, including mingw.
> 
> binutils slaves its config/ directory to GCC, so the patch is required
> to be committed here first, and then it will be ported over there.

Thanks, that helps indeed.

I agree that the ax_pthread.m4 approach makes sense.  Better to use
a field-tested macro than reinvent the wheel.  We're using other
files from the autoconf-archive archive already, for similar reasons
(e.g., config/ax_check_define.m4, and gdb/ax_cxx_compile_stdcxx.m4).

Since GCC won't be using it (yet at least, but it's conceivable it
could make use of it in future), there should be no harm in
installing it even if GCC is in stage 4, IMO.

I don't have the authority to approve it, though.

Thanks,
Pedro Alves


Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

2018-04-17 Thread Joshua Watt
On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
> On 04/17/2018 06:24 PM, Joshua Watt wrote:
> > Ping? I'd really like to get this in binutils, which apparently
> > requires getting it here first.
> 
> I think it would help if you mentioned what this is and
> what is the intended use case.

Ah, that would probably be helpful! Yes, this was discussed on the
binutils mailing list, see:
https://sourceware.org/ml/binutils/2018-02/msg00260.html

In short summary: the gold linker doesn't currently build for mingw,
but only because it is attempting to link against libpthread
incorrectly on that platform. Instead of bringing in more specialized
logic to account for that, I opted to include the autotools
ax_pthread.m4 macro (this patch) that automatically handles discovering
pthreads on a wide variety of platforms and compilers, including mingw.

binutils slaves its config/ directory to GCC, so the patch is required
to be committed here first, and then it will be ported over there.

Thanks,
Joshua Watt

> 
> Was this discussed on the binutils or gdb lists?
> 
> Thanks,
> Pedro Alves


Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

2018-04-17 Thread Pedro Alves
On 04/17/2018 06:24 PM, Joshua Watt wrote:
> Ping? I'd really like to get this in binutils, which apparently
> requires getting it here first.

I think it would help if you mentioned what this is and
what is the intended use case.

Was this discussed on the binutils or gdb lists?

Thanks,
Pedro Alves


Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

2018-04-17 Thread Joshua Watt
On Thu, 2018-03-22 at 21:45 -0500, Joshua Watt wrote:
> config/
>   * ax_pthread.m4: Add file
> ---
>  config/ax_pthread.m4 | 485
> +++
>  1 file changed, 485 insertions(+)
>  create mode 100644 config/ax_pthread.m4
> 
> diff --git a/config/ax_pthread.m4 b/config/ax_pthread.m4
> new file mode 100644
> index 000..5fbf9fe0d68
> --- /dev/null
> +++ b/config/ax_pthread.m4
> @@ -0,0 +1,485 @@
> +#
> =
> ==
> +#https://www.gnu.org/software/autoconf-archive/ax_pthread.ht
> ml
> +#
> =
> ==
> +#
> +# 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 to link with them as well. For example, you might link
> with
> +#   $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS
> $LIBS
> +#
> +#   If you are only building threaded 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, this macro 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 
> +#   Copyright (c) 2011 Daniel Richard G. 
> +#
> +#   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 .
> +#
> +#   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 24
> +
> +AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
> +AC_DEFUN([AX_PTHREAD], [
> +AC_REQUIRE([AC_CANONICAL_HOST])
> +AC_REQUIRE([AC_PROG_CC])

[PATCH] Add ax_pthread.m4 for use in binutils-gdb

2018-03-22 Thread Joshua Watt
config/
* ax_pthread.m4: Add file
---
 config/ax_pthread.m4 | 485 +++
 1 file changed, 485 insertions(+)
 create mode 100644 config/ax_pthread.m4

diff --git a/config/ax_pthread.m4 b/config/ax_pthread.m4
new file mode 100644
index 000..5fbf9fe0d68
--- /dev/null
+++ b/config/ax_pthread.m4
@@ -0,0 +1,485 @@
+# ===
+#https://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 to link with them as well. For example, you might link with
+#   $PTHREAD_CC $CFLAGS $PTHREAD_CFLAGS $LDFLAGS ... $PTHREAD_LIBS $LIBS
+#
+#   If you are only building threaded 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, this macro 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 
+#   Copyright (c) 2011 Daniel Richard G. 
+#
+#   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 .
+#
+#   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 24
+
+AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
+AC_DEFUN([AX_PTHREAD], [
+AC_REQUIRE([AC_CANONICAL_HOST])
+AC_REQUIRE([AC_PROG_CC])
+AC_REQUIRE([AC_PROG_SED])
+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 Tru64 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