On Thu, Sep 24, 2015 at 8:54 AM, Alan Modra <amo...@gmail.com> wrote:
> On Thu, Sep 24, 2015 at 02:24:25PM +1000, Michael Ellerman wrote:
>> On Wed, 2015-09-02 at 11:05 +0930, Alan Modra wrote:
>> > bugzilla.redhat.com/show_bug_cgi?id=1255946 shows that gcc built with
>> > both powerpc64-linux and powerpc64le-linux support passes wrong linker
>> > options when trying to link in the non-default endian.  A --oformat
>> > option coming from LINK_TARGET_SPEC is only correct for 32-bit.
>> >
>> > It turns out that GNU ld -m options select a particular ld emulation
>> > (e*.c file in ld build dir) which provides compiled-in scripts or
>> > selects a script from ldscripts/.  Each of these has an OUTPUT_FORMAT
>> > statement, which does the same thing as --oformat.  --oformat is
>> > therefore redundant when using GNU ld built this century, except
>> > possibly when a user overrides the default ld script with -Wl,-T and
>> > their script neglects OUTPUT_FORMAT, and it isn't the default output.
>> > I don't think it's worth fixing this possible use case.
>> >
>> > Bootstrap and testing in progress.  OK for mainline assuming all is
>> > OK?
>> >
>> >     * config/rs6000/sysv4le.h (LINK_TARGET_SPEC): Don't define.
>> >     * config/rs6000/sysv4.h (LINK_TARGET_SPEC): Likewise.
>> >     (LINK_SPEC, SUBTARGET_EXTRA_SPECS): Delete link_target.
>>
>> Hi Alan,
>>
>> If you could please backport this to the gcc-5-branch, that would helpful for
>> us (kernel folks).
>
> Bootstrapped and regression tested powerpc64le-linux.  Is this OK for
> the branch too, David?

Backporting this bug fix is fine with me.

Thanks!
David

Reply via email to