Proposal: Earlier 2.35 release

Proposal: Earlier 2.35 release

[Nick Clifton]

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

Re: Proposal: Earlier 2.35 release

[H.J. Lu]

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.

Re: Proposal: Earlier 2.35 release

[Michael Matz]

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.

Re: Proposal: Earlier 2.35 release

[Matthias Klose]

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

Re: Proposal: Earlier 2.35 release

[Jose E. Marchesi]

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! :)

Release 2.35 on Friday 24th ?

[Nick Clifton]

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

Re: Release 2.35 on Friday 24th ?

[H.J. Lu]

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.

Re: Release 2.35 on Friday 24th ?

[Maciej W. Rozycki]

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

Re: Release 2.35 on Friday 24th ?

[Alan Modra]

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

Re: Release 2.35 on Friday 24th ?

[H.J. Lu]

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.

Re: Release 2.35 on Friday 24th ?

[Alan Modra]

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

Re: Release 2.35 on Friday 24th ?

[Nick Clifton]

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

Re: Release 2.35 on Friday 24th ?

[H.J. Lu]

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.

Re: Release 2.35 on Friday 24th ?

[Maciej W. Rozycki]

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

Re: Release 2.35 on Friday 24th ?

[Fangrui Song]

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.

Re: Release 2.35 on Friday 24th ?

[Maciej W. Rozycki]

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