* Proposal: Earlier 2.35 release @ 2020-06-02 15:05 Nick Clifton 2020-06-02 15:16 ` H.J. Lu ` (4 more replies) 0 siblings, 5 replies; 16+ messages in thread From: Nick Clifton @ 2020-06-02 15:05 UTC (permalink / raw) To: binutils Hi Guys, How would you feel about having an earlier 2.35 release ? Specifically, branching on Saturday July 4 and releasing on Sunday July 19 ? This is purely self-serving for me - the goal being to get the 2.35 release into Fedora 33 - so if anyone has an objection I am willing to hear them out. Cheers Nick ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Proposal: Earlier 2.35 release 2020-06-02 15:05 Proposal: Earlier 2.35 release Nick Clifton @ 2020-06-02 15:16 ` H.J. Lu 2020-06-02 15:52 ` Michael Matz ` (3 subsequent siblings) 4 siblings, 0 replies; 16+ messages in thread From: H.J. Lu @ 2020-06-02 15:16 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils On Tue, Jun 2, 2020 at 8:05 AM Nick Clifton via Binutils <binutils@sourceware.org> wrote: > > Hi Guys, > > How would you feel about having an earlier 2.35 release ? > > Specifically, branching on Saturday July 4 and releasing on Sunday July 19 ? > > This is purely self-serving for me - the goal being to get the 2.35 release > into Fedora 33 - so if anyone has an objection I am willing to hear them out. > I think it is a good idea. I am working on ELF linker cleanup. It shouldn't be a problem. BTW, I'd like to add --export-dynamic-symbol and --export-dynamic-symbol-list to ld: https://sourceware.org/pipermail/binutils/2020-May/111302.html Can you take a look? Thanks. -- H.J. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Proposal: Earlier 2.35 release 2020-06-02 15:05 Proposal: Earlier 2.35 release Nick Clifton 2020-06-02 15:16 ` H.J. Lu @ 2020-06-02 15:52 ` Michael Matz 2020-06-02 16:07 ` Matthias Klose ` (2 subsequent siblings) 4 siblings, 0 replies; 16+ messages in thread From: Michael Matz @ 2020-06-02 15:52 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils Hello Nick, On Tue, 2 Jun 2020, Nick Clifton via Binutils wrote: > How would you feel about having an earlier 2.35 release ? > > Specifically, branching on Saturday July 4 and releasing on Sunday > July 19 ? > > This is purely self-serving for me - the goal being to get the 2.35 > release into Fedora 33 - so if anyone has an objection I am willing to > hear them out. Suits me very well as well :-) Ciao, Michael. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Proposal: Earlier 2.35 release 2020-06-02 15:05 Proposal: Earlier 2.35 release Nick Clifton 2020-06-02 15:16 ` H.J. Lu 2020-06-02 15:52 ` Michael Matz @ 2020-06-02 16:07 ` Matthias Klose 2020-06-02 16:11 ` Jose E. Marchesi [not found] ` <alpine.LFD.2.21.2007221518200.24175@redsun52.ssa.fujisawa.hgst.com> 4 siblings, 0 replies; 16+ messages in thread From: Matthias Klose @ 2020-06-02 16:07 UTC (permalink / raw) To: Nick Clifton, binutils On 6/2/20 5:05 PM, Nick Clifton via Binutils wrote: > Hi Guys, > > How would you feel about having an earlier 2.35 release ? > > Specifically, branching on Saturday July 4 and releasing on Sunday July 19 ? > > This is purely self-serving for me - the goal being to get the 2.35 release > into Fedora 33 - so if anyone has an objection I am willing to hear them out. sounds fine. I'll probably build the distro packages in the development series from a June snapshot anyway. Matthias ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Proposal: Earlier 2.35 release 2020-06-02 15:05 Proposal: Earlier 2.35 release Nick Clifton ` (2 preceding siblings ...) 2020-06-02 16:07 ` Matthias Klose @ 2020-06-02 16:11 ` Jose E. Marchesi [not found] ` <alpine.LFD.2.21.2007221518200.24175@redsun52.ssa.fujisawa.hgst.com> 4 siblings, 0 replies; 16+ messages in thread From: Jose E. Marchesi @ 2020-06-02 16:11 UTC (permalink / raw) To: Nick Clifton via Binutils Hi Nick. How would you feel about having an earlier 2.35 release ? Specifically, branching on Saturday July 4 and releasing on Sunday July 19 ? This is purely self-serving for me - the goal being to get the 2.35 release into Fedora 33 - so if anyone has an objection I am willing to hear them out. Sounds good to me! :) ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <alpine.LFD.2.21.2007221518200.24175@redsun52.ssa.fujisawa.hgst.com>]
[parent not found: <7d209c63-c3e8-c22b-ce90-0bdfca4aa3f0@redhat.com>]
[parent not found: <alpine.LFD.2.21.2007221712320.24175@redsun52.ssa.fujisawa.hgst.com>]
* Release 2.35 on Friday 24th ? [not found] ` <alpine.LFD.2.21.2007221712320.24175@redsun52.ssa.fujisawa.hgst.com> @ 2020-07-23 14:51 ` Nick Clifton 2020-07-23 15:24 ` H.J. Lu ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Nick Clifton @ 2020-07-23 14:51 UTC (permalink / raw) To: Maciej W. Rozycki, H.J. Lu, Alan Modra, binutils Hi Guys, I know that I proposed an earlier release date for 2.35, but there were some last minute issues that held things up and I have not actually created the tarballs yet. I think that these have all been resolved now, so does anyone have any objections to my making the release tomorrow - Friday Jul 24 ? Cheers Nick ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-23 14:51 ` Release 2.35 on Friday 24th ? Nick Clifton @ 2020-07-23 15:24 ` H.J. Lu 2020-07-23 19:31 ` Maciej W. Rozycki 2020-07-24 2:13 ` Alan Modra 2 siblings, 0 replies; 16+ messages in thread From: H.J. Lu @ 2020-07-23 15:24 UTC (permalink / raw) To: Nick Clifton; +Cc: Maciej W. Rozycki, Alan Modra, binutils On Thu, Jul 23, 2020 at 7:51 AM Nick Clifton <nickc@redhat.com> wrote: > > Hi Guys, > > I know that I proposed an earlier release date for 2.35, but > there were some last minute issues that held things up and I > have not actually created the tarballs yet. I think that these > have all been resolved now, so does anyone have any objections > to my making the release tomorrow - Friday Jul 24 ? > Sounds good to me. Thanks for your hard work. -- H.J. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-23 14:51 ` Release 2.35 on Friday 24th ? Nick Clifton 2020-07-23 15:24 ` H.J. Lu @ 2020-07-23 19:31 ` Maciej W. Rozycki 2020-07-24 2:13 ` Alan Modra 2 siblings, 0 replies; 16+ messages in thread From: Maciej W. Rozycki @ 2020-07-23 19:31 UTC (permalink / raw) To: Nick Clifton; +Cc: H.J. Lu, Alan Modra, binutils Hi Nick, > I know that I proposed an earlier release date for 2.35, but > there were some last minute issues that held things up and I > have not actually created the tarballs yet. I think that these > have all been resolved now, so does anyone have any objections > to my making the release tomorrow - Friday Jul 24 ? Not me, I have nothing urgent left. Thanks for your continuous support. Maciej ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-23 14:51 ` Release 2.35 on Friday 24th ? Nick Clifton 2020-07-23 15:24 ` H.J. Lu 2020-07-23 19:31 ` Maciej W. Rozycki @ 2020-07-24 2:13 ` Alan Modra 2020-07-24 3:09 ` H.J. Lu ` (2 more replies) 2 siblings, 3 replies; 16+ messages in thread From: Alan Modra @ 2020-07-24 2:13 UTC (permalink / raw) To: Nick Clifton; +Cc: Maciej W. Rozycki, H.J. Lu, binutils On Thu, Jul 23, 2020 at 03:51:29PM +0100, Nick Clifton wrote: > Hi Guys, > > I know that I proposed an earlier release date for 2.35, but > there were some last minute issues that held things up and I > have not actually created the tarballs yet. I think that these > have all been resolved now, so does anyone have any objections > to my making the release tomorrow - Friday Jul 24 ? I've been looking at gold a little, due to porting the --power10-stubs option across to gold. Gold isn't in good shape when using modern gcc and glibc. On x86_64-linux I see lots of "unknown program property type 0xc0010001 in .note.gnu.property section" when attempting to build the testsuite. On powerpc64le-linux, I see quite a few segfaults with compilers that default to PIE, one reason being that gold emits absolute symbols for addresses in the executable, eg. __ehdr_start, that are not relocated with a modern glibc. Other errors with PIEs appear to be due to bugs in powerpc.cc, eg. script_test_12 doesn't put a dynamic reloc on the address of test_array_start. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-24 2:13 ` Alan Modra @ 2020-07-24 3:09 ` H.J. Lu 2020-07-24 6:20 ` Alan Modra 2020-07-24 11:23 ` Nick Clifton 2 siblings, 0 replies; 16+ messages in thread From: H.J. Lu @ 2020-07-24 3:09 UTC (permalink / raw) To: Alan Modra; +Cc: Nick Clifton, Maciej W. Rozycki, binutils On Thu, Jul 23, 2020 at 7:13 PM Alan Modra <amodra@gmail.com> wrote: > > On Thu, Jul 23, 2020 at 03:51:29PM +0100, Nick Clifton wrote: > > Hi Guys, > > > > I know that I proposed an earlier release date for 2.35, but > > there were some last minute issues that held things up and I > > have not actually created the tarballs yet. I think that these > > have all been resolved now, so does anyone have any objections > > to my making the release tomorrow - Friday Jul 24 ? > > I've been looking at gold a little, due to porting the --power10-stubs > option across to gold. > > Gold isn't in good shape when using modern gcc and glibc. On > x86_64-linux I see lots of "unknown program property type 0xc0010001 > in .note.gnu.property section" when attempting to build the > testsuite. I have submitted: commit 31faf113b4a8187dc5900ec02d25b6f7f3f49394 Author: H.J. Lu <hjl.tools@gmail.com> Date: Thu Aug 16 10:40:26 2018 -0700 gold: Properly align the NT_GNU_PROPERTY_TYPE_0 note commit 567435b78e1b7a0198ac052ed72b2cb36e29d3ea Author: H.J. Lu <hjl.tools@gmail.com> Date: Thu Aug 9 17:02:42 2018 -0700 gold: Support GNU_PROPERTY_X86_FEATURE_2_[USED|NEEDED] > On powerpc64le-linux, I see quite a few segfaults with compilers that > default to PIE, one reason being that gold emits absolute symbols for > addresses in the executable, eg. __ehdr_start, that are not relocated > with a modern glibc. Other errors with PIEs appear to be due to bugs > in powerpc.cc, eg. script_test_12 doesn't put a dynamic reloc on the > address of test_array_start. > > -- > Alan Modra > Australia Development Lab, IBM -- H.J. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-24 2:13 ` Alan Modra 2020-07-24 3:09 ` H.J. Lu @ 2020-07-24 6:20 ` Alan Modra 2020-07-24 11:23 ` Nick Clifton 2 siblings, 0 replies; 16+ messages in thread From: Alan Modra @ 2020-07-24 6:20 UTC (permalink / raw) To: Nick Clifton; +Cc: Maciej W. Rozycki, H.J. Lu, binutils On Fri, Jul 24, 2020 at 11:43:41AM +0930, Alan Modra wrote: > Other errors with PIEs appear to be due to bugs > in powerpc.cc, eg. script_test_12 doesn't put a dynamic reloc on the > address of test_array_start. Actually, this one is a generic gold bug. (gdb) p *this $18 = {name_ = 0x9852f0 "test_array_start", version_ = 0x0, u1_ = {object = 0x988f50, output_data = 0x988f50, output_segment = 0x988f50}, u2_ = {shndx = 0, offset_is_from_end = false, offset_base = gold::Symbol::SEGMENT_START}, symtab_index_ = 0, dynsym_index_ = 0, plt_offset_ = 4294967295, got_offsets_ = {got_type_ = 4294967295, got_offset_ = 0, got_next_ = 0x0}, type_ = elfcpp::STT_NOTYPE, binding_ = elfcpp::STB_GLOBAL, visibility_ = elfcpp::STV_DEFAULT, nonvis_ = 0, source_ = gold::Symbol::IS_CONSTANT, is_def_ = false, is_forwarder_ = false, has_alias_ = false, needs_dynsym_entry_ = false, in_reg_ = true, in_dyn_ = false, needs_dynsym_value_ = false, has_warning_ = false, is_copied_from_dynobj_ = false, is_forced_local_ = false, is_ordinary_shndx_ = true, in_real_elf_ = true, is_defined_in_discarded_section_ = false, undef_binding_set_ = true, undef_binding_weak_ = false, is_predefined_ = false, is_protected_ = false, non_zero_localentry_ = false} The problem being source_ = gold::Symbol::IS_CONSTANT is taken to be absolute and thus not need a dynamic relocation. See symtab.h needs_dynamic_reloc. Symbols defined in scripts are IS_CONSTANT, see script.cc add_to_table. Which isn't correct when creating a PIE or shared library and defining script symbols relative to "dot". These script symbols are later set to section relative in Symbol_assignment::set_if_absolute but that's too late for Scan::global. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-24 2:13 ` Alan Modra 2020-07-24 3:09 ` H.J. Lu 2020-07-24 6:20 ` Alan Modra @ 2020-07-24 11:23 ` Nick Clifton 2020-07-24 11:29 ` H.J. Lu 2 siblings, 1 reply; 16+ messages in thread From: Nick Clifton @ 2020-07-24 11:23 UTC (permalink / raw) To: Alan Modra; +Cc: Maciej W. Rozycki, H.J. Lu, binutils Hi Guys, > On 2020-07-24 03:13, Alan Modra wrote: > Gold isn't in good shape when using modern gcc and glibc. I have been wondering if gold has started to bit-rot. I mean no insult to Cary or anyone else, but it seems to me that development work on gold has come to a halt, and bug fixes and new features are only being added when they are ported from the BFD linker. Is it time to deprecate gold ? Cheers Nick ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-24 11:23 ` Nick Clifton @ 2020-07-24 11:29 ` H.J. Lu 2020-07-24 11:42 ` Maciej W. Rozycki 0 siblings, 1 reply; 16+ messages in thread From: H.J. Lu @ 2020-07-24 11:29 UTC (permalink / raw) To: Nick Clifton; +Cc: Alan Modra, Maciej W. Rozycki, binutils On Fri, Jul 24, 2020 at 4:23 AM Nick Clifton <nickc@redhat.com> wrote: > > Hi Guys, > > > On 2020-07-24 03:13, Alan Modra wrote: > > > Gold isn't in good shape when using modern gcc and glibc. > > I have been wondering if gold has started to bit-rot. I mean no > insult to Cary or anyone else, but it seems to me that development > work on gold has come to a halt, and bug fixes and new features are > only being added when they are ported from the BFD linker. > > Is it time to deprecate gold ? Yes, we should. I think lld is a good replacement for gold. -- H.J. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-24 11:29 ` H.J. Lu @ 2020-07-24 11:42 ` Maciej W. Rozycki 2020-07-24 23:34 ` Fangrui Song 0 siblings, 1 reply; 16+ messages in thread From: Maciej W. Rozycki @ 2020-07-24 11:42 UTC (permalink / raw) To: H.J. Lu; +Cc: Nick Clifton, Alan Modra, binutils On Fri, 24 Jul 2020, H.J. Lu wrote: > > Is it time to deprecate gold ? > > Yes, we should. I think lld is a good replacement for gold. It is not free software however. Maciej ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-24 11:42 ` Maciej W. Rozycki @ 2020-07-24 23:34 ` Fangrui Song 2020-07-24 23:55 ` Maciej W. Rozycki 0 siblings, 1 reply; 16+ messages in thread From: Fangrui Song @ 2020-07-24 23:34 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: H.J. Lu, binutils On 2020-07-24, Maciej W. Rozycki via Binutils wrote: >On Fri, 24 Jul 2020, H.J. Lu wrote: > >> > Is it time to deprecate gold ? >> >> Yes, we should. I think lld is a good replacement for gold. > > It is not free software however. > > Maciej https://www.gnu.org/licenses/license-list.en.html#apache2 > This is a free software license, compatible with version 3 of the GNU GPL. http://www.apache.org/licenses/GPL-compatibility.html > Apache 2 software can therefore be included in GPLv3 projects, because > the GPLv3 license accepts our software into GPLv3 works. If an lld executable is 90MiB, 87MiB is due to LLVM LTO. If you drop those stuff, the executable is just 3MiB. If someone wants an LLVM-library free linker, grab https://github.com/MaskRay/picolld/ , reimplement some LLVM support libraries (llvm/ADT/ llvm/Support). The simplest is to use C++ std::, it is likely doable in a few thousand lines of code. You will get a linker with ARM/AArch64/PowerPC32/PowerPC64/RISC-V/x86 support with ~30000 lines of code. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Release 2.35 on Friday 24th ? 2020-07-24 23:34 ` Fangrui Song @ 2020-07-24 23:55 ` Maciej W. Rozycki 0 siblings, 0 replies; 16+ messages in thread From: Maciej W. Rozycki @ 2020-07-24 23:55 UTC (permalink / raw) To: Fangrui Song; +Cc: Maciej W. Rozycki, binutils On Fri, 24 Jul 2020, Fangrui Song wrote: > https://www.gnu.org/licenses/license-list.en.html#apache2 > > > This is a free software license, compatible with version 3 of the GNU GPL. > > http://www.apache.org/licenses/GPL-compatibility.html > > > Apache 2 software can therefore be included in GPLv3 projects, because > > the GPLv3 license accepts our software into GPLv3 works. It is as compatible as say the BSD licence is, but it does not prevent a licensee from closing down their sources and using them in proprietary software. IOW a licensee is allowed to benefit from other people's work without giving anything back. That's IMO not fair and does not guarantee freedom to the piece of software considered, and I think it is important to mention when considering an alternative to a piece of GNU software. Of course everyone is (hopefully) free to make their own choices. Maciej ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-07-24 23:55 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-02 15:05 Proposal: Earlier 2.35 release Nick Clifton 2020-06-02 15:16 ` H.J. Lu 2020-06-02 15:52 ` Michael Matz 2020-06-02 16:07 ` Matthias Klose 2020-06-02 16:11 ` Jose E. Marchesi [not found] ` <alpine.LFD.2.21.2007221518200.24175@redsun52.ssa.fujisawa.hgst.com> [not found] ` <7d209c63-c3e8-c22b-ce90-0bdfca4aa3f0@redhat.com> [not found] ` <alpine.LFD.2.21.2007221712320.24175@redsun52.ssa.fujisawa.hgst.com> 2020-07-23 14:51 ` Release 2.35 on Friday 24th ? Nick Clifton 2020-07-23 15:24 ` H.J. Lu 2020-07-23 19:31 ` Maciej W. Rozycki 2020-07-24 2:13 ` Alan Modra 2020-07-24 3:09 ` H.J. Lu 2020-07-24 6:20 ` Alan Modra 2020-07-24 11:23 ` Nick Clifton 2020-07-24 11:29 ` H.J. Lu 2020-07-24 11:42 ` Maciej W. Rozycki 2020-07-24 23:34 ` Fangrui Song 2020-07-24 23:55 ` Maciej W. Rozycki
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).