Re: [PATCH] gold: Use autotools pthread macro

[Joshua Watt]

On Sat, Feb 17, 2018 at 4:42 PM, Cary Coutant  wrote:
>> The autotools library macro (AX_PTHREAD) is now used to detect if
>> pthreads is present and multi-threaded linking in gold is automatically
>> enabled if it is found. This enables multi-threaded gold on platforms
>> where pthreads is enabled via other methods than just -lpthread (e.g.
>> MinGW)
>>
>> Signed-off-by: Joshua Watt 
>> ---
>>  config/ax_pthread.m4   | 485 
>>  gold/Makefile.am   |  11 +-
>>  gold/Makefile.in   |  22 +-
>>  gold/aclocal.m4|   1 +
>>  gold/configure | 767 
>> +++--
>>  gold/configure.ac  |  23 +-
>>  gold/testsuite/Makefile.in |   8 +-
>>  7 files changed, 1254 insertions(+), 63 deletions(-)
>
> Thanks for the patch! I have a few preliminary questions and comments...
>
> First, do you or your company have a copyright assignment on file with FSF?

I do not. What is the process for that? I don't need a company
assignment, an individual contributor for me will be fine.

If I sign that for this project, would it also cover GCC, or do I need
one for each?

>
> I could be wrong, but I believe adding to config/ will require
> approval from a GCC config/ maintainer. The normal process, as I
> understand it, would be to add the file to the GCC tree, then sync it
> into the binutils tree. I'm not in a position to approve that, nor can
> I judge on the acceptability of the copyright notice in that file.

Ok. I didn't realize the config/ directory came from GCC. I'll look
into getting it submitted there How does that get "synced" to
binutils? Would I make a patch to add it here after it is added there?

FWIW, it is the same license as the ax_check_define macro (also from
the autotools macro archive) that is already in config/

>
> I'd like to retain the ability to use --disable-threads as a configure option.
>

I will add that back in.

> If this is just to get MinGW on board, is there a lighter-weight way
> of doing that? Could we just add a configure option that switches
> between -lpthread and -pthread (or whatever option is needed)? I like
> the idea of fully automating it, but that's a pretty big m4 file!

It is pretty large I pulled it straight from the autoconf macro
archive. IMHO, its much better quality than anything I would be able
to come up with otherwise, and pretty brain-dead easy for the end
user. It should "just work" without any special switches (although the
user *can* configure it with some env-vars I think).

>
> Anyway, I'd like to hear what the GCC folks think of adding
> ax_pthread.m4 to the config/ directory.
>
> (BTW, In the future, please omit diffs from generated files from your patch.)

Will do. I couldn't find a lot of examples of config changes in
binutils, but I thought the one that I did updated the generated files
also. I must have been mistaken.

>
> -cary

Thanks,
Joshua Watt

Re: [config patch] Fwd from binutils: add ax_pthread.m4 to config/ directory

[Joshua Watt]

On Mon, 2018-02-19 at 17:24 -0800, Cary Coutant wrote:
> Please see this patch posted to the binutils list:
> 
>https://sourceware.org/ml/binutils/2018-02/msg00260.html
> 
> where Joshua proposes to add the ax_pthread.m4 script, from the
> autoconf macro archive, to the config/ directory in order to improve
> gold's configure-time detection of thread support.
> 
> Is the config/ part of this patch OK?
> 
> config/
> * ax_pthread.m4: New file.
> 
> -cary

Ping? I can repost this as a patch here instead of linking to the
binutils thread if necessary.

Thanks,
Joshua Watt

Re: [config patch] Fwd from binutils: add ax_pthread.m4 to config/ directory

[Joshua Watt]

On Fri, 2018-02-23 at 08:54 -0600, Joshua Watt wrote:
> On Mon, 2018-02-19 at 17:24 -0800, Cary Coutant wrote:
> > Please see this patch posted to the binutils list:
> > 
> >https://sourceware.org/ml/binutils/2018-02/msg00260.html
> > 
> > where Joshua proposes to add the ax_pthread.m4 script, from the
> > autoconf macro archive, to the config/ directory in order to
> > improve
> > gold's configure-time detection of thread support.
> > 
> > Is the config/ part of this patch OK?
> > 
> > config/
> > * ax_pthread.m4: New file.
> > 
> > -cary
> 
> Ping? I can repost this as a patch here instead of linking to the
> binutils thread if necessary.

Ping?

> 
> Thanks,
> Joshua Watt

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

[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 variables, and if threads linking works using

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

[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 <https://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 t

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

[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

[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)

>