This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] gold: Use autotools pthread macro
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Joshua Watt <jpewhacker at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, config-patches at gnu dot org, Binutils <binutils at sourceware dot org>, Ian Lance Taylor <iant at google dot com>
- Date: Mon, 19 Feb 2018 12:39:47 -0800
- Subject: Re: [PATCH] gold: Use autotools pthread macro
- Authentication-results: sourceware.org; auth=none
- References: <20180216033531.23726-1-JPEWhacker@gmail.com> <CAJimCsH5KDvkqRyp-Pa=cdaqR4mD9z2pd1GhLxmgPX0vh_0svQ@mail.gmail.com> <CAJdd5GZWiBgq9=eayxK11D1KvYtL=i5qa1NZADXBjZdQ7g+SQA@mail.gmail.com>
>> 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?
It will cover all FSF contributions.
If config/ax_pthread.m4 is accepted by the config maintainers, I doubt
you'd need an assignment for that, since it's already licensed and
it's not actually your contribution.
That leaves a fairly small change to gold sources (not counting
auto-regenerated files) -- small enough that I don't think you need to
complete an assignment.
If you do want to file a copyright assignment for future changes,
I'll forward you a copy of the form and instructions separately.
>> 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?
I've added config-patches to the conversation, so I'm hoping that was
sufficient to get that going. Once added in the GCC tree, I think one
can either wait for an automatic sync, or go ahead and submit a patch
to do the sync (but I'm not completely versed on how the shared
directories really operate).
> FWIW, it is the same license as the ax_check_define macro (also from
> the autotools macro archive) that is already in config/
That suggests to me that there shouldn't be a problem adding this new file.
>> 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).
Sounds good to me if others agree.
>> (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.
It's a convention that makes reviewing and applying patches easier for
us maintainers, but it's easy to forget to strip out those diffs.