Release 2.26 - Next week ?

[H.J. Lu]

On Tue, Jan 12, 2016 at 5:58 PM, Alan Modra <amodra@gmail.com> wrote:
> On Tue, Jan 12, 2016 at 05:11:53PM -0800, H.J. Lu wrote:
>> On Tue, Jan 12, 2016 at 5:04 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Mon, Jan 11, 2016 at 10:21:08AM +0100, Tristan Gingold wrote:
>> >>
>> >> > On 08 Jan 2016, at 18:26, Matthias Klose <doko@ubuntu.com> wrote:
>> >> > - PR 19421, but currently only a bug report
>> >
>> > Now analysed.  The ppc64le kernel problem is due to needing to keep
>> > undefined symbols.  I'd say it is also a kernel bug that the symbol in
>> > question isn't defined, but that's really another issue.  The point is
>> > that we have a GNU ld use case where removing undefined symbols breaks
>> > an existing program.

Is this problem specific to ppc64le? Do we have a small testcase?

>> >> Let’s exclude it.
>> >
>> > I'm of two minds about this.  PR3417 wants undefined symbols to be
>> > removed:  "When the reference to __tls_get_addr is removed, it leaves
>> > undefined symbol in symtab.  It is confusing."  H.J. what exactly was
>> > confusing?  When I made the PR3417 patch, I thought PR3417 was mostly
>> > about cosmetics and figured that removing undefined symbols was
>> > reasonably safe.  If it is true that PR3417 was only cosmetic, I think
>> > my patch ought to be reverted.
>> >
>>
>> Is PR3417 the right PR?
>
> No, sorry.  https://sourceware.org/bugzilla/show_bug.cgi?id=4317
>

My PR is with executable.  But

https://sourceware.org/bugzilla/show_bug.cgi?id=19421

is for relocatable objects.  I am OK to keep undefined symbols
in .o files.



-- 
H.J.