From: Alexander Dahl <post@lespocky.de>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] fastd: add new package
Date: Thu, 05 Nov 2015 09:31:47 +0100 [thread overview]
Message-ID: <9074e4810a20f47dbda9b9d401a04bdf@localhost> (raw)
In-Reply-To: <20151104222134.792979c1@free-electrons.com>
Hei Thomas,
Am 2015-11-04 22:21, schrieb Thomas Petazzoni:
> This commit log again contained some "personal" messages, so I reworded
> it.
Okay, I understand. :-)
> I also did a few other changes:
>
> [Thomas:
> - Get rid of trailing spaces in Config.in
Sorry, I usually check this before committing. :-/
> - Remove the BR2_PACKAGE_FASTD_OPENSSL, and simply rely on
> BR2_PACKAGE_OPENSSL
I'm not sure if I like this, because it is less flexible, but if this is
common practice in buildroot, okay.
> - Remove -DWITH_CAPABILITIES=TRUE, since libcap support is anyway
> mandatory.
Buildroot builds only Linux based systems, right? Then fastd sets this
to ON by itself in cmake/config.cmake so it can be removed, okay.
> Could you submit your LTO related patch to the upstream project and
> get it merged, so that next time we update the fastd package we can
> get rid of the patch?
I suppose the upstream author will not apply it. I had a somewhat long
discussion in IRC with him. As stated in the patch his goal is to use
LTO to reduce binary size (binaries compiled with lto are actually
smaller and on a device with 4 MB flash this matters). However the cmake
approach (as I understood the cmake docs, which are very thin on this
topic) is like presented in my patch (which in fact does not work, but I
would just wait for an upcoming cmake version getting this right).
What I tried first was just setting -DENABLE_LTO=OFF which was not
enough, compiling failed, because of the cmake hacks included in fastd
choosing wrong binutils. This hack is removed by my patch. In OpenWRT
the fastd author got a patch upstream enabling the plugins option in the
toolchain. I assumed this would not work with buildroot where you have
fine grained options to configure the toolchain.
Another option would for the fastd buildroot package could be to require
a toolchain with LTO support and just enable the related cmake option.
Thanks for review. :-)
Alex
--
?With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.? (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 ***
next prev parent reply other threads:[~2015-11-05 8:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 7:13 [Buildroot] [PATCH 1/2] libuecc: add new package Alexander Dahl
2015-10-29 7:13 ` [Buildroot] [PATCH 2/2] fastd: " Alexander Dahl
2015-11-04 21:21 ` Thomas Petazzoni
2015-11-05 8:31 ` Alexander Dahl [this message]
2015-11-04 20:48 ` [Buildroot] [PATCH 1/2] libuecc: " Thomas Petazzoni
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=9074e4810a20f47dbda9b9d401a04bdf@localhost \
--to=post@lespocky.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox