public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
To: openembedded-core@lists.openembedded.org
Subject: Changing between gold and bfd linker (was: [PATCH 1/4] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC)
Date: Thu, 24 Jan 2013 13:13:05 +0100	[thread overview]
Message-ID: <lyham6g4oe.fsf@ensc-virt.intern.sigma-chemnitz.de> (raw)
In-Reply-To: 50FEBF6A.40305@gmail.com

Khem Raj <raj.khem-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

>>> +KERNEL_LD = "${LD} ${HOST_LD_KERNEL_ARCH}"
>>> ...
>>> -KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
>>
>> that's bad... gold linker has serious problems to compile stuff like
>> kernel or bootloaders and setting 'KERNEL_LDSUFFIX = .bfd' was a good
>> way to workaround these problems.
>>
>
> This was not the intended use of KERNEL_LD IMO.

ok; then I abused it for this purpose and stuff failed more or less
silently with recent oe ;)

Me wonders whether we should implement a more generic way to select
between .bfd and .gold linker.  Overriding LD works well when LD is used
by the build system, but when it is called through gcc -> collect there
is no way to select the linker.

For grub2 I use

------
PATH_prepend = "${S}/.bin:"
CC_prepend = "env COMPILER_PATH=${S}/.bin/gcc "

do_configure_prepend() {
    mkdir -p .bin/gcc
    { echo "#!/bin/sh"
      echo 'exec ${TARGET_PREFIX}ld.bfd "$@"'
    } > .bin/${TARGET_PREFIX}ld
    chmod +x .bin/${TARGET_PREFIX}ld
    ln -s ../${TARGET_PREFIX}ld .bin/gcc/ld
}
------

which might go into a more general .bbclass.

Modifying binutils or gcc to select the wanted linker is probably the
2nd best solution (after fixing gold linker). E.g. for binutils, the
'arm-linux-gnueabi-ld' binary (or however it is called) which is a copy
of .bfd or .gold atm can be replaced by a oe specific program which
calls the corresponding linker depending on an environment variable.

Changing gcc seems to be more difficultly because name of ld is determined
at multiple locations.

So we have to following options:

1. keep things as is; when problems with gold arise[1], people have to turn
   it of globally

2. create a 'custom-ld.bbclass' which is inherited on demand

3. create custom 'ld' program evaluating '${OE_LDSUFFIX}' which is set
   on demand

4. patch gcc/collect to call a linker specified by environment


I favor 3; what do you think?



Enrico

Footnotes: 
[1]  I am aware of
     * kernel (--> '--march=all' object file mismatch)
     * barebox (--> optimizing away constructors with '--gc-shared')
     * grub2 (--> disfunctional with gold; no further details)

-- 
SIGMA Chemnitz GmbH       Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13           Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz



  reply	other threads:[~2013-01-24 12:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-19 22:39 [PATCH 0/4] boost, nfs-utils upgrade, drop KERNEL_CC Khem Raj
2013-01-19 22:40 ` [PATCH 1/4] kernel.bbclass, module-base.bbclass: Use CC to form KERNEL_CC Khem Raj
2013-01-22 15:41   ` Enrico Scholz
2013-01-22 16:33     ` Khem Raj
2013-01-24 12:13       ` Enrico Scholz [this message]
2013-01-22 17:34     ` Khem Raj
2013-01-22 20:44   ` Darren Hart
2013-01-22 21:44     ` Khem Raj
2013-01-22 21:50       ` Darren Hart
2013-01-22 22:12         ` Khem Raj
2013-01-22 22:19           ` Darren Hart
2013-01-23  8:46     ` Andrea Adami
2013-02-04 20:13   ` McClintock Matthew-B29882
2013-02-04 22:51     ` Khem Raj
2013-02-04 23:56       ` McClintock Matthew-B29882
2013-01-19 22:40 ` [PATCH 2/4] nfs-utils: Upgrade 1.2.3 -> 1.2.8-rc2 Khem Raj
2013-01-21  4:08   ` Saul Wold
2013-01-21 18:43     ` Khem Raj
2013-01-19 22:40 ` [PATCH 3/4] consolekit_0.4.5.bb: Package unpackaged systemd files Khem Raj
2013-01-19 22:40 ` [PATCH 4/4] boost: Upgrade 1.51 -> 1.52 Khem Raj
2013-01-19 23:05 ` [PATCH 0/4] boost, nfs-utils upgrade, drop KERNEL_CC Otavio Salvador
2013-01-20  3:38   ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=lyham6g4oe.fsf@ensc-virt.intern.sigma-chemnitz.de \
    --to=enrico.scholz@sigma-chemnitz.de \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox