From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] systemd: Build with LTO
Date: Tue, 9 Oct 2018 21:49:12 +0200 [thread overview]
Message-ID: <20181009214912.72b43194@windsurf> (raw)
In-Reply-To: <20181009193340.26242-1-abrodkin@synopsys.com>
Hello,
On Tue, 9 Oct 2018 22:33:40 +0300, Alexey Brodkin wrote:
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 4813496670..ebd29c89b0 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -38,7 +38,8 @@ SYSTEMD_CONF_OPTS += \
> -Dsulogin-path=/usr/sbin/sulogin \
> -Dmount-path=/usr/bin/mount \
> -Dumount-path=/usr/bin/umount \
> - -Dnobody-group=nogroup
> + -Dnobody-group=nogroup \
> + -Db_lto=true
I don't think we can do this unconditionally. We have a bunch of
options such as BR2_BINUTILS_ENABLE_LTO and BR2_GCC_ENABLE_LTO to
enable LTO support in the internal toolchain, and we don't today have a
way to know if the external toolchain provided supports LTO or not.
So this needs a much more generic solution:
- A global Config.in option to enable/disable usage of LTO. It will
have to interact with the toolchain LTO support.
- An option that tells whether the toolchain supports LTO. For
internal toolchains, it's simply selected by BR2_GCC_ENABLE_LTO. For
external toolchains, we need a check to verify that the toolchain is
LTO + a visible option for custom external toolchains.
So: yes for using LTO, but we need something more generic.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2018-10-09 19:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-09 19:33 [Buildroot] [PATCH] systemd: Build with LTO Alexey Brodkin
2018-10-09 19:49 ` Thomas Petazzoni [this message]
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=20181009214912.72b43194@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.